アカウント名:
パスワード:
動画見た感じだとブラウザで暗号化するのかな。リンクもブラウザで生成してサーバ経由しないなら安心。でも復号キーもリンクに含まれるんだから、結局ダウンロードすればMozilla側に漏洩するってことだよね。
ソース [github.com]を読んでみた。
という仕組みで、サーバーに暗号鍵が送られることがないので、サーバーはファイルの(平文の)内容を知り得ない。
モダンブラウザーが必要な理由は、暗号化・復号にWebCrypto APIを使っているから。あと暗号化を全部メモリ上でやっているので、(1GB制限しなくても)あまり大きすぎるファイルはメモリ不足で扱えない。
もちろんサーバーに悪意があれば(真正の運営者に悪意がなくてもクラックされるとか)、暗号化・復号を行うスクリプト(サーバーから送られる)が鍵を盗み取るよう改変することは容易なので、サーバーの信頼性は重要。本来なら暗号化・復号を行うスクリプトは信頼できる場所からインストールするのがよさそうだがWebアプリでそれは無理だわな。
Windowsなら「仮想メモリ」設定で「ページング ファイルなし」にしていない限り、大きいファイルでも仮想メモリが使われるだけなので、メモリ不足で扱えないなんてことは起こりません。
暗号鍵とかそういう機密データがHDDやSSDにスワップするのはセキュリティ上好ましくないからといってもWindowsは欠陥OSなのでアプリ側からスワップを回避するのは困難(というかOSのカーネルレベルを書き換えないと無理)ですだから、WebCrypto APIもスワップを完全に回避する仕様にはできていないはず
TrueCryptのような暗号化ツールも開発者がなるべくメモリ上の暗号鍵がスワップしないように頑張ったけど完全な回避は無理なのでドキュメントでユーザー側に「ページング ファイルなし」に設定するように求めてました
Windowsを使っている場合、メモリを大量に積んで「ページング ファイルなし」に設定するか、HDD全体をBitLockerとかで暗号化しない限り、HDDを専門業者で解析するとメモリからスワップした暗号鍵かなんかが取り出されちゃうことがあるので注意してください
あー、「メモリ上で暗号化している」ってのをセキュリティ上の理由と解釈されちゃったのか。単なる手抜きと言ったつもりだったんだけど。そもそもPC上にあるファイルをアップロードしている以上そこで頑張ってもあまり意味がないし、BitLockerはページファイルも暗号化するし。
じゃあ、手抜きしないやり方って何だよ。
そもそもPC上にあるファイルをアップロードしている以上そこで頑張ってもあまり意味がないし
いや、パスワードとかパスフレーズって使いまわされるものなだから、スワップアウト回避は重要でしょう。
ファイル自体はどうでもいいファイルだったとしても、それを暗号化するのに使っているパスフレーズは株取引の決済パスワードと共通かもしれない。
実装みりゃわかるんだけど、このサービスのパスワードに該当する部分はランダムだから、まあ、ワンタイムパスワードってやつだ。実際、一回ダウンロードすると期限切れになるわけだし。
なるほど。ユーザー設定のパスワードではなく、ワンタイムパスワードだったんですね。
なら問題ないですね。
いやいくらページファイルがあっても(とくにブラウザーが32bitの場合)2GBとか4GBとかが仮想アドレス空間の上限だしFirefoxはなんかメモリ管理がまずくて上限がもっと低いという噂だし暗号化だけにメモリをすべて使えるわけじゃないし。
Win32APIのVirtualLock()が機能しないケースがあるってこと? 初めて聞いたしググっても出てこないな。ソースあります?
自己レス。適切な解説 [microsoft.com]を見つけた。
というわけで、WindowsではAWE関数を使えばできるが、セキュリティの目的ならばメモリ上に維持することに血道を上げるのではなく、CryptProtectData()/CryptUnProtectData()を使うのが正しい。これによって、秘密データを生のまま保持する時間を極めて短時間にできる。これによってスワップファイルへのオフラインクラックのリスクも極小になるが、さらにそれも防止したいなら、これにBitLockerを組み合せろということなんだろう。
VirtualAlloc()の動作は、これのAPIが専らパフォーマンス向上目的であることを考えればそんなに不思議でもない。スレッドが停止しているときにメモリだけ確保する意味はないので。停止しない処理に対して使う限りは、意図通りに作用してくれるだろう。
全体として、合理的でセキュアな設計だと思う。TrueCryptの作者がAWE関数群を知らなかったのは、不勉強だったというしかないな。
非常に参考になった。参考になるとか、素晴らしい洞察のモデをあげたいところだが、ACなのでモデ権がないのが残念でならない。
そもそもVirtualLock()の仕様読めよ
元コメだけど、読んだ上で書いたのよ? あなたこそ読んだの?
以下のように、「ページファイルに書かれないことが保障される」とはっきり書いてある(要するにドキュメントの誤り)。
Pages that a process has locked remain in physical memory until the process unlocks them or terminates. These pages are guaranteed not to be written to the pagefile while they are locked.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa366895(v=vs... [microsoft.com]
このドキュメントが誤りであることは、#325824
A.8.4 Pageant は VirtualLock() を使って秘密鍵がディスクに書き込まれないようにできませんか [ranvis.com]
残念ながらできません。 Windows API の VirtualLock() は適切に動作しません。プロセスの動作中にプロセスメモリの一部がディスクにページアウトしないようにできますが、プロセスが長期間非アクティブなときにプロセスメモリ全体をディスクにスワップアウトしないようにはできないのです。
ほかにも罠があって、この関数は成功すると0以外の値が返る仕様なのに、Windows 9x だと常に失敗するのに成功扱いの「0以外」が返っ [microsoft.com]
ページファイルから生データ読み出せる状況で何をイキがってんだか
うまいこと考えるよなぁ。フラグメントIDをこういった目的で利用できることは広く知られてるんだろうか?
#自分は今回初めて知った(目からウロコ)
自分もサーバーに鍵が送られるのをどうやって防いでいるのか興味があって調べて感心した。と同時に、Mega.co.nzのWeb UIがフラグメントIDを使っている理由も理解できた。エンドツーエンド暗号化をうたうファイル共有サービスでは必然なわけだ。
というより、暗号化してないと、違法なファイルのやり取りでの免責がややこしくなるからな。
クライアントを自分で実装すれば、サービス側のクラックで起こる事態は暗号データの横流しとブルートフォースによる解読だけでしょ。
クライアントを自分で実装するなら暗号化の方法も同じにする必要なかったはずなので、暗号化の方法も変えてたらもっと安全。
megaの時とよく似ていますね。クライアントアプリを自前で用意しれば、問題解決ですね。
アップロードもダウンロードもメモリ上に展開するのはWebアプリだとファイルの読み書きが自由でないからかも・・・
> アップロードしたファイルはファイルがダウンロードされるか24時間経過後に無効になり、ファイルも自動的に削除される。
ダウンロードされた時点で,元のファイルは削除されるから漏洩しないってことでしょう.
削除しないでダウンロードする口を用意すれば良いだけの話。Mozillaで作ってるんだから、そういう口を用意しようと思えば用意できてしまう。
実際には、そのな口を用意してて発覚したら、信用がなくなってMozilla自体が終わりかねないからやらないと思うけど。
> 実際には、そのな口を用意してて発覚したら、信用がなくなってMozilla自体が終わりかねないからやらないと思うけど。
これに勝る信用はない、のかもしれない。いやホント。
最近はそれがアテにならない場合があるのが怖い。キュレーションメディア問題とかまさにそれ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
暗号化 (スコア:0)
動画見た感じだとブラウザで暗号化するのかな。
リンクもブラウザで生成してサーバ経由しないなら安心。
でも復号キーもリンクに含まれるんだから、結局ダウンロードすればMozilla側に漏洩するってことだよね。
Re:暗号化 (スコア:2, 参考になる)
ソース [github.com]を読んでみた。
という仕組みで、サーバーに暗号鍵が送られることがないので、サーバーはファイルの(平文の)内容を知り得ない。
モダンブラウザーが必要な理由は、暗号化・復号にWebCrypto APIを使っているから。あと暗号化を全部メモリ上でやっているので、(1GB制限しなくても)あまり大きすぎるファイルはメモリ不足で扱えない。
もちろんサーバーに悪意があれば(真正の運営者に悪意がなくてもクラックされるとか)、暗号化・復号を行うスクリプト(サーバーから送られる)が鍵を盗み取るよう改変することは容易なので、サーバーの信頼性は重要。本来なら暗号化・復号を行うスクリプトは信頼できる場所からインストールするのがよさそうだがWebアプリでそれは無理だわな。
メモリ不足でも「仮想メモリ」が使われるだけ (スコア:1)
モダンブラウザーが必要な理由は、暗号化・復号にWebCrypto APIを使っているから。
あと暗号化を全部メモリ上でやっているので、(1GB制限しなくても)あまり大きすぎるファイルはメモリ不足で扱えない。
Windowsなら「仮想メモリ」設定で「ページング ファイルなし」にしていない限り、
大きいファイルでも仮想メモリが使われるだけなので、メモリ不足で扱えないなんてことは起こりません。
暗号鍵とかそういう機密データがHDDやSSDにスワップするのはセキュリティ上好ましくないからといっても
Windowsは欠陥OSなのでアプリ側からスワップを回避するのは困難(というかOSのカーネルレベルを書き換えないと無理)です
だから、WebCrypto APIもスワップを完全に回避する仕様にはできていないはず
TrueCryptのような暗号化ツールも開発者がなるべくメモリ上の暗号鍵がスワップしないように頑張ったけど完全な回避は無理なので
ドキュメントでユーザー側に「ページング ファイルなし」に設定するように求めてました
Windowsを使っている場合、メモリを大量に積んで「ページング ファイルなし」に設定するか、HDD全体をBitLockerとかで暗号化しない限り、HDDを専門業者で解析するとメモリからスワップした暗号鍵かなんかが取り出されちゃうことがあるので注意してください
Re:メモリ不足でも「仮想メモリ」が使われるだけ (スコア:1)
あー、「メモリ上で暗号化している」ってのをセキュリティ上の理由と解釈されちゃったのか。単なる手抜きと言ったつもりだったんだけど。そもそもPC上にあるファイルをアップロードしている以上そこで頑張ってもあまり意味がないし、BitLockerはページファイルも暗号化するし。
Re: (スコア:0)
じゃあ、手抜きしないやり方って何だよ。
Re: (スコア:0)
そもそもPC上にあるファイルをアップロードしている以上そこで頑張ってもあまり意味がないし
いや、パスワードとかパスフレーズって使いまわされるものなだから、スワップアウト回避は重要でしょう。
ファイル自体はどうでもいいファイルだったとしても、それを暗号化するのに使っているパスフレーズは株取引の決済パスワードと共通かもしれない。
Re: (スコア:0)
実装みりゃわかるんだけど、このサービスのパスワードに該当する部分はランダムだから、まあ、ワンタイムパスワードってやつだ。実際、一回ダウンロードすると期限切れになるわけだし。
Re: (スコア:0)
実装みりゃわかるんだけど、このサービスのパスワードに該当する部分はランダムだから、まあ、ワンタイムパスワードってやつだ。実際、一回ダウンロードすると期限切れになるわけだし。
なるほど。ユーザー設定のパスワードではなく、ワンタイムパスワードだったんですね。
なら問題ないですね。
Re: (スコア:0)
いやいくらページファイルがあっても(とくにブラウザーが32bitの場合)2GBとか4GBとかが仮想アドレス空間の上限だしFirefoxはなんかメモリ管理がまずくて上限がもっと低いという噂だし暗号化だけにメモリをすべて使えるわけじゃないし。
Re: (スコア:0)
Win32APIのVirtualLock()が機能しないケースがあるってこと? 初めて聞いたしググっても出てこないな。
ソースあります?
Re:メモリ不足でも「仮想メモリ」が使われるだけ (スコア:1)
自己レス。適切な解説 [microsoft.com]を見つけた。
というわけで、WindowsではAWE関数を使えばできるが、セキュリティの目的ならば
メモリ上に維持することに血道を上げるのではなく、CryptProtectData()/CryptUnProtectData()を使うのが正しい。
これによって、秘密データを生のまま保持する時間を極めて短時間にできる。
これによってスワップファイルへのオフラインクラックのリスクも極小になるが、さらにそれも防止したいなら、これにBitLockerを組み合せろということなんだろう。
VirtualAlloc()の動作は、これのAPIが専らパフォーマンス向上目的であることを考えればそんなに不思議でもない。
スレッドが停止しているときにメモリだけ確保する意味はないので。
停止しない処理に対して使う限りは、意図通りに作用してくれるだろう。
全体として、合理的でセキュアな設計だと思う。
TrueCryptの作者がAWE関数群を知らなかったのは、不勉強だったというしかないな。
Re: (スコア:0)
非常に参考になった。
参考になるとか、素晴らしい洞察のモデをあげたいところだが、ACなのでモデ権がないのが残念でならない。
Re: (スコア:0)
そもそもVirtualLock()の仕様読めよ
Re: (スコア:0)
元コメだけど、読んだ上で書いたのよ? あなたこそ読んだの?
以下のように、「ページファイルに書かれないことが保障される」とはっきり書いてある(要するにドキュメントの誤り)。
Pages that a process has locked remain in physical memory until the process unlocks them or terminates. These pages are guaranteed not to be written to the pagefile while they are locked.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa366895(v=vs... [microsoft.com]
このドキュメントが誤りであることは、#325824
Re: (スコア:0)
Win32APIのVirtualLock()が機能しないケースがあるってこと? 初めて聞いたしググっても出てこないな。
ソースあります?
A.8.4 Pageant は VirtualLock() を使って秘密鍵がディスクに書き込まれないようにできませんか [ranvis.com]
ほかにも罠があって、この関数は成功すると0以外の値が返る仕様なのに、Windows 9x だと常に失敗するのに成功扱いの「0以外」が返っ [microsoft.com]
Re: (スコア:0)
ページファイルから生データ読み出せる状況で何をイキがってんだか
Re: (スコア:0)
うまいこと考えるよなぁ。
フラグメントIDをこういった目的で利用できることは広く知られてるんだろうか?
#自分は今回初めて知った(目からウロコ)
Re: (スコア:0)
自分もサーバーに鍵が送られるのをどうやって防いでいるのか興味があって調べて感心した。と同時に、Mega.co.nzのWeb UIがフラグメントIDを使っている理由も理解できた。エンドツーエンド暗号化をうたうファイル共有サービスでは必然なわけだ。
Re:暗号化 (スコア:1)
というより、暗号化してないと、違法なファイルのやり取りでの免責がややこしくなるからな。
Re: (スコア:0)
クライアントを自分で実装すれば、サービス側のクラックで起こる事態は暗号データの横流しとブルートフォースによる解読だけでしょ。
Re: (スコア:0)
クライアントを自分で実装するなら暗号化の方法も同じにする必要なかったはずなので、暗号化の方法も変えてたらもっと安全。
Re: (スコア:0)
megaの時とよく似ていますね。クライアントアプリを自前で用意しれば、問題解決ですね。
アップロードもダウンロードもメモリ上に展開するのはWebアプリだとファイルの読み書きが自由でないからかも・・・
Re: (スコア:0)
> アップロードしたファイルはファイルがダウンロードされるか24時間経過後に無効になり、ファイルも自動的に削除される。
ダウンロードされた時点で,元のファイルは削除されるから漏洩しないってことでしょう.
Re: (スコア:0)
削除しないでダウンロードする口を用意すれば良いだけの話。
Mozillaで作ってるんだから、そういう口を用意しようと思えば用意できてしまう。
実際には、そのな口を用意してて発覚したら、信用がなくなってMozilla自体が終わりかねないからやらないと思うけど。
Re: (スコア:0)
> 実際には、そのな口を用意してて発覚したら、信用がなくなってMozilla自体が終わりかねないからやらないと思うけど。
これに勝る信用はない、のかもしれない。いやホント。
Re: (スコア:0)
> 実際には、そのな口を用意してて発覚したら、信用がなくなってMozilla自体が終わりかねないからやらないと思うけど。
これに勝る信用はない、のかもしれない。いやホント。
最近はそれがアテにならない場合があるのが怖い。
キュレーションメディア問題とかまさにそれ。