Dropbox、データの暗号化に関する説明が正しくなかったとして告発される 44
ストーリー by hylom
「データが見える」のと「見ない」のは違う 部門より
「データが見える」のと「見ない」のは違う 部門より
あるAnonymous Coward 曰く、
人気のオンライン・ストレージサービスDropboxが、プライバシーやデータの暗号化に関して、暗号化キーの扱いにおいてユーザーを騙していたとして米連邦取引委員会（FTC）に告発されたそうだ（electronista、PC Online、本家/.記事）。
セキュリティ専門家のChristopher Soghoian氏がFTCに提出した告発状によると、Dropboxがユーザのファイルを暗号化しており、同社の社員はそのファイルを見る事が出来ないというのは誤りであるという。告発状によると、確かにデータは暗号化されて保管されているが、その暗号キーはユーザ側ではなくDropbox側にあるためDropbox側からユーザのファイルにアクセスすることは可能であるというのだ。
Dropboxの場合、ハッシュを利用してファイルの重複をチェックする方式をとっている。このような方法は保管スペースを効率よく管理することができるとのことだが、サービス側が鍵を保管する必要がある。同様のストレージサービスでも、たとえばSpiderOakやWualaなどはサービス側が暗号キーを保管することは無いといい、サービス側のサーバ容量の負担は大きいがユーザのプライバシーは守られているという。
なお、Dropbox社のサイトでは以前は「Dropboxのサーバに保存されるファイルは全てAES-256で暗号化されており、ユーザのアカウントパスワード無しにはアクセスできない」と説明されていたが、現在では「Dropboxのサーバに保存されているファイルは全てAES-256で暗号化されている」という文言に変更されているとのことだ。
無料ユーザーは文句言えないんじゃ (スコア:3, 興味深い)
Re:無料ユーザーは文句言えないんじゃ (スコア:1, すばらしい洞察)
Re: (スコア:0)
ちょっとコンプレックスがあったんですぅ
Re: (スコア:0, 既出)
一瞬何かと思ったけど、復号ね。
Re: (スコア:0)
こら、横着しないでちゃんと叩け
# 様式美を大切に！
Re: (スコア:0)
複合
復号
全然違うよね
Re: (スコア:0)
Re:無料ユーザーは文句言えないんじゃ (スコア:1)
Aさんが大きなファイルをアップロードしようとすると、DropBoxクライアントはそのファイルのハッシュを計算してDropBoxサーバに送る。サーバでは、同一ハッシュのファイルを他の人がDropBox上に持ってないかをチェックする。Aさんがアップロードしようとしたファイルがたまたまよく知られた動画ファイルなんかであれば、Bさんが既にアップロードしていたりする。その場合は、AさんのDropBoxクライアントはファイルをアップロードしない。その代わりサーバ側でAさんのアカウントからBさんのファイルへの紐付けが行われる(ハードリンクな感じ)。
と言う実装になってるんじゃ? という疑念が、「みんなが持ってそうなファイルをアップロードしようとした時に限って凄いスピードで同期される」という体験から推測される、と。
そうだとすると、Aさんがビジネス文書をアップロードしたら、たまたまBさんの自作ポエムとハッシュが一致、Aさんが別の端末から自分のビジネス文書を開こうとしたら謎のポエムが出てきてBさん涙目、みたいなセキュリティホールがあり得るので結構言語道断な気もします。
でもまあ、そんな器用なハッシュ衝突が起こる確率は、「適当に入力したパスワードが一致した」「ランダムにでっち上げたセッションキーが偶然当たった」レベルなので、それをセキュリティホールと言っちゃうとどんなシステムにもセキュリティホールがあることになっちゃうか。
Re: (スコア:0)
> そうだとすると、Aさんがビジネス文書をアップロードしたら、たまたまBさんの自作ポエムとハッシュが一致、Aさんが別の端末から自分のビジネス文書を開こうとしたら謎のポエムが出てきてBさん涙目、みたいなセキュリティホールがあり得るので結構言語道断な気もします。
たまたまハッシュが一致する可能性ならユーザー別に暗号化したってあると思いますが
Re:無料ユーザーは文句言えないんじゃ (スコア:2)
・AさんがファイルXをAさんのパスワードで暗号化したビット列x
・BさんがファイルYをBさんのパスワードで暗号化したビット列y
があって、xのハッシュとyのハッシュが偶然一致したので、サーバが勘違いしてビット列yはアップロードされずじまい。Bさんのファイル取得リクエストに対しては、間違ってビット列xが返される。xをBさんのパスワードで復号しても元のファイルYにはならないので、結果、Bさんからするとファイルの内容がランダム文字列に変化してしまったように見える。最初のコメントは、そのような不幸な例に遭遇しただけかもしれないじゃないか、という考察ですね。
ストレージを節約すべく、xとyが偶然一致する事に期待する、というのはちょっと考えにくい戦略じゃないかと。 ランダムなビット列同士が偶然一致する幸運に掛けることになるので、ユーザ毎のパスワードで暗号化したファイルをアップロードする仕様の場合は、そのストレージ節約戦略は採用されないように思います。
それを言い出すと、そもそもの「複数のユーザが同じ内容のファイルをアップロードするかも」と期待するという発想もかなり奇異に思えますが。
# ユーザがアップロードしたファイルを精査しているうちに同じ内容が多数有ることに気付いて
# そんな機能が実装されたんじゃ、みたいなもっとひどい邪推も出来ますが、ここまでくると言いがかり未満
そういうわけで、「他の人も置いていそうなファイルに限って高速に同期が出来る」という現象が本当に見られたなら、 それは、個々人のパスワードで暗号化されて送信されているわけではない、という事の強い傍証になるかと。
Re:無料ユーザーは文句言えないんじゃ (スコア:1, 参考になる)
また複数のユーザが同じものをおく可能性は低いという予想のほうがむしろ理解できないです． 自分の原稿，ホームビデオをおくというシチュエーションでは確かにあり得ないです． しかし，「面白いのみつけたよ」ってメール等で送られてきた画像・動画・文書をとっておいたりとか， もっと業務用のイメージで言えば，大きい「お知らせ文書」を添付で送られたりとか，重複が発生する場合もあるでしょう． で，多くのファイルは重複していないとしても，極一部の大きいファイルが数千人・数万人で重複していたら それを削ることの効果は無視できないものになるわけです．
Re:無料ユーザーは文句言えないんじゃ (スコア:1)
ZFSの場合は、Solarisで複数コンテナを使うとほぼ同じ構成のOS一式のディレクトリ構造が複数作られることになる、とかいう仕組みだった気がするので、コストを掛けて実装する理由が想像できるんですが。
DropBoxの場合は、いろいろ考えても1%も削減できないんじゃないか?とか、でも貸しストレージ企業がストレージを1%削減できたとしたらそれは結構なコストダウンになるのか?とか、ついでに、元々更新チェックのためにハッシュを計算してサーバに投げてという仕組みは必須だから、そこに多少の機能を上乗せするだけで実装出来る重複排除機能はそんなに高コストではないのか?とか、でも中身はお客様ご自身以外には絶対見えませんと言う外部仕様にある意味反する機能だし・・・とか。
Re: (スコア:0)
Re:無料ユーザーは文句言えないんじゃ (スコア:1)
Re: (スコア:0)
Re: (スコア:0)
Dropship騒動 (スコア:3, 興味深い)
データを分割したピースのハッシュ値なんかそうそう分かりっこないはずだから、いちユーザとしてはぼーと観てたんですけど、そんなにヤバい脆弱性なのかな。
関係ないけど、今月初頭LastPassにもセキュリティ騒動 [lastpass.com]がありまして。こちらもちょっと焦った。
Re: (スコア:0)
> どうやらハッシュ指定でデータにアクセスするときは認証などすっ飛ばしてしまうようで。
本当にユーザー別にデータを暗号化しているならユーザーごとにハッシュ値が異なるので、そういうことは起こりえないんですよ。同じハッシュ値で異なるユーザーのデータにアクセスできること自体がDropBoxの説明に嘘があったことの証明になっているわけです。
話は飛びますけど、初期のWinnyには放流者別にデータを暗号化する機能があったのですが、キャッシュの共有が事実上できないのが不評だったのかすぐに廃止されてしまいましたね。
暗号化されてないならすれば良いじゃない (スコア:1)
DropBoxのシステムにどれぐらい余分な負荷をかけちゃうのか知らないけど。
Re: (スコア:0)
>TrueCryptのボリュームファイルをDropBoxに置けばOK、と。
ボリュームの一部（たとえば数KB）が書き換わっても、ボリューム全体送信しちゃうんじゃ
dropboxの負担よりユーザーの方がやきもきしそう。
Re:暗号化されてないならすれば良いじゃない (スコア:1)
Re:暗号化されてないならすれば良いじゃない (スコア:2)
DropBox & TrueCrypt を実際にやっておりますが、
どうもアップロード速度から判断する限りは差分のみ送っているようなので
数GBもあるTrueCryptファイルをストレス無く共有できてます。
ただ、同期のタイミングによって、昨晩自宅で編集したものを
翌朝会社で編集しているとかで、コンフリクトが発生することは時折起こります。
ですので最低限、２倍の空きの確保が必要なのは何ともしがたいですね。
Re:暗号化されてないならすれば良いじゃない (スコア:1)
> DropBox & TrueCrypt を実際にやっておりますが、
> どうもアップロード速度から判断する限りは差分のみ送っているようなので
差分を作るには、比較対象の元ファイルと現在のファイルの二つが必要です。
そして、誰が差分を作るかですが、クライアントとサーバーのどちらかになりますが、
サーバーだとしたら、現在のファイルはクライアントにアップロードしなければ、
差分を作ることが出来ません。
もし、クライアントだとしたら、元ファイルが必要です。元ファイルがクライアントにあるのでしょうか？
Re:暗号化されてないならすれば良いじゃない (スコア:3, すばらしい洞察)
確かに。
一応クライアント側にキャッシュフォルダはあるようですが、.svn みたいにオリジナルを保持しているようには見えませんね。
私が想像したのは、
例えば大きいファイルを分割してクライアント側でブロック別にハッシュ値を計算するなどすれば、
差分を取るのに必ずしもsrc-dest両方の全バイトが必要ではないですよね。
もともとDropBoxは差分を記憶するVC機能も有しているので、こういった仕組みを用いている可能性はあるか、
といったところです。
が、今回の騒動を見るとあんまり凝ったことはしてない可能性の方が高いかなとも思います。
Re:暗号化されてないならすれば良いじゃない (スコア:1)
クライアントにある最新のファイルを適当なサイズのブロックに分割、各ブロックのハッシュをサーバに送る、サーバ側でブロック毎のハッシュと元ファイルの対応部分のハッシュを比較、変更のあったブロック番号をクライアントに通知、その部分だけアップロード、みたいな戦略もあり得るかと。
Re: (スコア:0)
DropBoxに何突っ込んでる？ (スコア:1, 興味深い)
１．エロ動画
２．エロ画像
自分が不慮の事故で死んでもDropBoxに入れとけば安心だわな。
きっと米連邦取引委員会の中の人たちも自身のエロファイルのセキュリティが心配だったんですよ。
Re: (スコア:0)
既に水葬された，かの人もそうしておけば
隠しておいたのを見つからずに済んだのにね。
Re: (スコア:0)
重複除外システムとか胸熱の親切機能だな
Re: (スコア:0)
あなたはもうこのファイルをファイル名 xxx_yyy_xxx.mp4 でアップロード済です。
とかって表示されまくるのか。
便利だ。
Re: (スコア:0)
これでオケ (スコア:0)
「Dropboxのサーバに保存されるファイルは全てAES-256で暗号化されており、ユーザのアカウントパスワード無しにはアクセスできない(※)」
※アカウントパスワードもDropboxで管理していますので、当社はパスワードを知りえます
当たり前だろうに (スコア:0)
暗号化キーがクライアントにあったら
何で二つ目のクライアントは
ユーザー認証だけでファイルがアクセスできるのか
まぁ、Webでファイルが見えてる段階で
何を言っているんだ状態だろうけど
Re: (スコア:0)
いやいや、ユーザー認証時にパスワード入力してるでしょ？
クライアント毎にパス入力をさせてるのだから、そのパスをローカルで覚えておけば
復号は個別に(他のクライアントに関係なく)できますよね。
なんでそれをサーバ側に保存してるの！って話だと思います。
この間不正アクセスされたLastPassはそうなっているので被害が最小になりました。
もちろんすぐ解析可能な簡単なパスワードだったら意味ないですけどね。
Re: (スコア:0)
Dropboxと同じストレージ系ではSugarSyncが通信の暗号化とファイルの暗号化の両方を行うよう明記 [sugarsync.jp]されていますね。
ただ、詳細が解らないので、Dropboxと同じ仕組みで暗号化してるのかもしれませんが。
重複除外と暗号化の相性の悪さ (スコア:0)
ストレージのシステム作った所は多分判ってたと思うけど
暗号化すると重複除外はやり辛くなるんだよね
Re: (スコア:0)
そんなに同じファイルをDropBoxに置くユーザって多いのでしょうか。ニコ動のmp4の例が挙がっているけど、そういうのを置く人がそんなに多いかというと、やや自分の直感に反しますがどうなんでしょうか？
ネットで拾ったおもしろ画像とか置いている人が多いのかな。
そもそも (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
みたいなもんだと思って諦めてます。
Re: (スコア:0)
世の中には、IDManager や KeePass のデータファイルを Dropbox に入れておくとどこからでも共有できて便利！
みたいなことをやってる人がいましてね。
先日の LastPass 騒動のときに、そういった手法が Twitter とかで紹介されてました。
LastPass 騒動のあとでそういうことを始めた人は、今頃gkbrしてるかもしれません。
Re: (スコア:0)
かつてメールに添付できないサイズのファイルを受け渡しする無料サービスがありましたが、ダウンロードにはメールで相手に送ったパスワードが必要なので第三者には漏洩しませんっていう説明だったけど、運営側はノゾキ放題だったろうね。