パスワードを忘れた? アカウント作成
326965 story
セキュリティ

Dropbox、データの暗号化に関する説明が正しくなかったとして告発される 44

ストーリー by hylom
「データが見える」のと「見ない」のは違う 部門より

あるAnonymous Coward 曰く、

人気のオンライン・ストレージサービスDropboxが、プライバシーやデータの暗号化に関して、暗号化キーの扱いにおいてユーザーを騙していたとして米連邦取引委員会(FTC)に告発されたそうだ(electronistaPC Online本家/.記事)。

セキュリティ専門家のChristopher Soghoian氏がFTCに提出した告発状によると、Dropboxがユーザのファイルを暗号化しており、同社の社員はそのファイルを見る事が出来ないというのは誤りであるという。告発状によると、確かにデータは暗号化されて保管されているが、その暗号キーはユーザ側ではなくDropbox側にあるためDropbox側からユーザのファイルにアクセスすることは可能であるというのだ。

Dropboxの場合、ハッシュを利用してファイルの重複をチェックする方式をとっている。このような方法は保管スペースを効率よく管理することができるとのことだが、サービス側が鍵を保管する必要がある。同様のストレージサービスでも、たとえばSpiderOakやWualaなどはサービス側が暗号キーを保管することは無いといい、サービス側のサーバ容量の負担は大きいがユーザのプライバシーは守られているという。

なお、Dropbox社のサイトでは以前は「Dropboxのサーバに保存されるファイルは全てAES-256で暗号化されており、ユーザのアカウントパスワード無しにはアクセスできない」と説明されていたが、現在では「Dropboxのサーバに保存されているファイルは全てAES-256で暗号化されている」という文言に変更されているとのことだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by shesee (27226) on 2011年05月18日 18時59分 (#1954617) 日記
    Flashがキャッシュの暗号化かけてないころ、ニコニコ動画のmp4をDropboxに上げると一瞬でアップロードされるのでハッシュとって重複を除いていると気づいてはいたけど、みんな後ろ暗いのであえて指摘していないんだと思い込んでいた。
    • by Anonymous Coward on 2011年05月18日 19時45分 (#1954637)
      無料ユーザーだろうと「暗号化しててスタッフにも複合化できません!」って嘘ついちゃ駄目でしょ。
      親コメント
      • by Anonymous Coward

        ちょっとコンプレックスがあったんですぅ

      • Re: (スコア:0, 既出)

        by Anonymous Coward

        一瞬何かと思ったけど、復号ね。

    • by Anonymous Coward
      ハッシュ計算する暇があるならディスクに保存する時間なんて大したこと無いだろ。
      • 元のコメント [srad.jp]は、DropBoxは複数人が同一内容のファイルをアップロードした場合、それらを別々に保持するのではなく、1個だけ保持してそれを複数人が共有するような形でストレージを節約する実装になっている疑いが強い、という事じゃないかと。

        Aさんが大きなファイルをアップロードしようとすると、DropBoxクライアントはそのファイルのハッシュを計算してDropBoxサーバに送る。サーバでは、同一ハッシュのファイルを他の人がDropBox上に持ってないかをチェックする。Aさんがアップロードしようとしたファイルがたまたまよく知られた動画ファイルなんかであれば、Bさんが既にアップロードしていたりする。その場合は、AさんのDropBoxクライアントはファイルをアップロードしない。その代わりサーバ側でAさんのアカウントからBさんのファイルへの紐付けが行われる(ハードリンクな感じ)。

        と言う実装になってるんじゃ? という疑念が、「みんなが持ってそうなファイルをアップロードしようとした時に限って凄いスピードで同期される」という体験から推測される、と。

        そうだとすると、Aさんがビジネス文書をアップロードしたら、たまたまBさんの自作ポエムとハッシュが一致、Aさんが別の端末から自分のビジネス文書を開こうとしたら謎のポエムが出てきてBさん涙目、みたいなセキュリティホールがあり得るので結構言語道断な気もします。

        でもまあ、そんな器用なハッシュ衝突が起こる確率は、「適当に入力したパスワードが一致した」「ランダムにでっち上げたセッションキーが偶然当たった」レベルなので、それをセキュリティホールと言っちゃうとどんなシステムにもセキュリティホールがあることになっちゃうか。
        親コメント
        • by Anonymous Coward

          > そうだとすると、Aさんがビジネス文書をアップロードしたら、たまたまBさんの自作ポエムとハッシュが一致、Aさんが別の端末から自分のビジネス文書を開こうとしたら謎のポエムが出てきてBさん涙目、みたいなセキュリティホールがあり得るので結構言語道断な気もします。
          たまたまハッシュが一致する可能性ならユーザー別に暗号化したってあると思いますが

          • >たまたまハッシュが一致する可能性ならユーザー別に暗号化したってあると思いますが

            ・AさんがファイルXをAさんのパスワードで暗号化したビット列x
            ・BさんがファイルYをBさんのパスワードで暗号化したビット列y

            があって、xのハッシュとyのハッシュが偶然一致したので、サーバが勘違いしてビット列yはアップロードされずじまい。Bさんのファイル取得リクエストに対しては、間違ってビット列xが返される。xをBさんのパスワードで復号しても元のファイルYにはならないので、結果、Bさんからするとファイルの内容がランダム文字列に変化してしまったように見える。最初のコメントは、そのような不幸な例に遭遇しただけかもしれないじゃないか、という考察ですね。

            ストレージを節約すべく、xとyが偶然一致する事に期待する、というのはちょっと考えにくい戦略じゃないかと。 ランダムなビット列同士が偶然一致する幸運に掛けることになるので、ユーザ毎のパスワードで暗号化したファイルをアップロードする仕様の場合は、そのストレージ節約戦略は採用されないように思います。

            それを言い出すと、そもそもの「複数のユーザが同じ内容のファイルをアップロードするかも」と期待するという発想もかなり奇異に思えますが。

            # ユーザがアップロードしたファイルを精査しているうちに同じ内容が多数有ることに気付いて
            # そんな機能が実装されたんじゃ、みたいなもっとひどい邪推も出来ますが、ここまでくると言いがかり未満

            そういうわけで、「他の人も置いていそうなファイルに限って高速に同期が出来る」という現象が本当に見られたなら、 それは、個々人のパスワードで暗号化されて送信されているわけではない、という事の強い傍証になるかと。
            親コメント
            • by Anonymous Coward on 2011年05月20日 8時48分 (#1955482)
              重複排除機能は,WindowsでもSolaris ZFSでも最近のファイルシステムによく搭載されている機能ですよ.

              また複数のユーザが同じものをおく可能性は低いという予想のほうがむしろ理解できないです. 自分の原稿,ホームビデオをおくというシチュエーションでは確かにあり得ないです. しかし,「面白いのみつけたよ」ってメール等で送られてきた画像・動画・文書をとっておいたりとか, もっと業務用のイメージで言えば,大きい「お知らせ文書」を添付で送られたりとか,重複が発生する場合もあるでしょう. で,多くのファイルは重複していないとしても,極一部の大きいファイルが数千人・数万人で重複していたら それを削ることの効果は無視できないものになるわけです.
              親コメント
              • まあ、その辺は、具体的な見積もりが無いのでイメージでの話に終始してしまいますね。

                ZFSの場合は、Solarisで複数コンテナを使うとほぼ同じ構成のOS一式のディレクトリ構造が複数作られることになる、とかいう仕組みだった気がするので、コストを掛けて実装する理由が想像できるんですが。

                DropBoxの場合は、いろいろ考えても1%も削減できないんじゃないか?とか、でも貸しストレージ企業がストレージを1%削減できたとしたらそれは結構なコストダウンになるのか?とか、ついでに、元々更新チェックのためにハッシュを計算してサーバに投げてという仕組みは必須だから、そこに多少の機能を上乗せするだけで実装出来る重複排除機能はそんなに高コストではないのか?とか、でも中身はお客様ご自身以外には絶対見えませんと言う外部仕様にある意味反する機能だし・・・とか。
                親コメント
        • by Anonymous Coward
          ハッシュを計算するには1度ファイルを全部読む必要がある。 なので「一瞬でアップロードされる」ってことは無いでしょうという指摘。 ハッシュの比較だけではないので、クライアント側で処理しても一瞬ではできないでしょう。
      • by Anonymous Coward
        え、ちょっと意味わからないですね
      • by Anonymous Coward
        時間が問題ではなく、ディスクの保存領域を減らすためにやっているのでは?
  • Dropship騒動 (スコア:3, 興味深い)

    by Anonymous Coward on 2011年05月18日 19時35分 (#1954630)
    先月ですが米Dropboxが自社サービスの脆弱性を利用するコードに対しDMCAによる削除を要請、問題に [osdn.jp]という話題があって、ちょっと調べてみたんですが、どうやらハッシュ指定でデータにアクセスするときは認証などすっ飛ばしてしまうようで。たぶんこの騒動が尾を引いてここに至ったのかなと。
    データを分割したピースのハッシュ値なんかそうそう分かりっこないはずだから、いちユーザとしてはぼーと観てたんですけど、そんなにヤバい脆弱性なのかな。
    関係ないけど、今月初頭LastPassにもセキュリティ騒動 [lastpass.com]がありまして。こちらもちょっと焦った。
    • by Anonymous Coward

      > どうやらハッシュ指定でデータにアクセスするときは認証などすっ飛ばしてしまうようで。
      本当にユーザー別にデータを暗号化しているならユーザーごとにハッシュ値が異なるので、そういうことは起こりえないんですよ。同じハッシュ値で異なるユーザーのデータにアクセスできること自体がDropBoxの説明に嘘があったことの証明になっているわけです。
      話は飛びますけど、初期のWinnyには放流者別にデータを暗号化する機能があったのですが、キャッシュの共有が事実上できないのが不評だったのかすぐに廃止されてしまいましたね。

  • TrueCryptのボリュームファイルをDropBoxに置けばOK、と。

    DropBoxのシステムにどれぐらい余分な負荷をかけちゃうのか知らないけど。
    • by Anonymous Coward

      >TrueCryptのボリュームファイルをDropBoxに置けばOK、と。

      ボリュームの一部(たとえば数KB)が書き換わっても、ボリューム全体送信しちゃうんじゃ
      dropboxの負担よりユーザーの方がやきもきしそう。

      • ついうっかり、2カ所で編集してコンクリフト処理されると倍の容量を消費してしまいますね。ファイル単位で暗号化できるような何かを探さないとダメか。
        親コメント
        • DropBox & TrueCrypt を実際にやっておりますが、
          どうもアップロード速度から判断する限りは差分のみ送っているようなので
          数GBもあるTrueCryptファイルをストレス無く共有できてます。

          ただ、同期のタイミングによって、昨晩自宅で編集したものを
          翌朝会社で編集しているとかで、コンフリクトが発生することは時折起こります。
          ですので最低限、2倍の空きの確保が必要なのは何ともしがたいですね。

          親コメント
          • > DropBox & TrueCrypt を実際にやっておりますが、
            > どうもアップロード速度から判断する限りは差分のみ送っているようなので

            差分を作るには、比較対象の元ファイルと現在のファイルの二つが必要です。

            そして、誰が差分を作るかですが、クライアントとサーバーのどちらかになりますが、
            サーバーだとしたら、現在のファイルはクライアントにアップロードしなければ、
            差分を作ることが出来ません。
            もし、クライアントだとしたら、元ファイルが必要です。元ファイルがクライアントにあるのでしょうか?

            親コメント
            • by ikotom (20155) on 2011年05月19日 11時30分 (#1954968)

              差分を作るには、比較対象の元ファイルと現在のファイルの二つが必要です。

              確かに。
              一応クライアント側にキャッシュフォルダはあるようですが、.svn みたいにオリジナルを保持しているようには見えませんね。

              私が想像したのは、
              例えば大きいファイルを分割してクライアント側でブロック別にハッシュ値を計算するなどすれば、
              差分を取るのに必ずしもsrc-dest両方の全バイトが必要ではないですよね。
              もともとDropBoxは差分を記憶するVC機能も有しているので、こういった仕組みを用いている可能性はあるか、
              といったところです。
              が、今回の騒動を見るとあんまり凝ったことはしてない可能性の方が高いかなとも思います。

              親コメント
            • >差分を作るには、比較対象の元ファイルと現在のファイルの二つが必要です。

              クライアントにある最新のファイルを適当なサイズのブロックに分割、各ブロックのハッシュをサーバに送る、サーバ側でブロック毎のハッシュと元ファイルの対応部分のハッシュを比較、変更のあったブロック番号をクライアントに通知、その部分だけアップロード、みたいな戦略もあり得るかと。
              親コメント
              • by Anonymous Coward
                暗号化ドライブ内のファイルを1ビットでも変更すると、TrueCryptのイメージファイル全体が変更されると思ってるんじゃないですか? いくらなんでもそこまで局所性のない設計にはなっていないと思っているんですが(安全性は高いかもしれませんが書き込みが遅すぎて使いものになりませんよね)。
  • by Anonymous Coward on 2011年05月19日 0時55分 (#1954820)

    1.エロ動画
    2.エロ画像
    自分が不慮の事故で死んでもDropBoxに入れとけば安心だわな。
    きっと米連邦取引委員会の中の人たちも自身のエロファイルのセキュリティが心配だったんですよ。

    • by Anonymous Coward

      既に水葬された,かの人もそうしておけば
      隠しておいたのを見つからずに済んだのにね。

    • by Anonymous Coward

      重複除外システムとか胸熱の親切機能だな

      • by Anonymous Coward

        あなたはもうこのファイルをファイル名 xxx_yyy_xxx.mp4 でアップロード済です。

        とかって表示されまくるのか。
        便利だ。

    • by Anonymous Coward
      どうせ重複排除しているんなら, 「あなたのお気に入りのこのエロ画像は,現在n人が同じものを利用しているようです!」 とか表示されると,誰だかわからないけど同好の士をネットの向こうに感じることができていい感じじゃない?
  • by Anonymous Coward on 2011年05月18日 18時53分 (#1954614)

    「Dropboxのサーバに保存されるファイルは全てAES-256で暗号化されており、ユーザのアカウントパスワード無しにはアクセスできない(※)」
    ※アカウントパスワードもDropboxで管理していますので、当社はパスワードを知りえます

  • by Anonymous Coward on 2011年05月18日 19時28分 (#1954628)

    暗号化キーがクライアントにあったら
    何で二つ目のクライアントは
    ユーザー認証だけでファイルがアクセスできるのか

    まぁ、Webでファイルが見えてる段階で
    何を言っているんだ状態だろうけど

    • by Anonymous Coward

      いやいや、ユーザー認証時にパスワード入力してるでしょ?

      クライアント毎にパス入力をさせてるのだから、そのパスをローカルで覚えておけば
      復号は個別に(他のクライアントに関係なく)できますよね。
      なんでそれをサーバ側に保存してるの!って話だと思います。

      この間不正アクセスされたLastPassはそうなっているので被害が最小になりました。
      もちろんすぐ解析可能な簡単なパスワードだったら意味ないですけどね。

  • by Anonymous Coward on 2011年05月18日 19時57分 (#1954643)

    ストレージのシステム作った所は多分判ってたと思うけど
    暗号化すると重複除外はやり辛くなるんだよね

    • by Anonymous Coward

      そんなに同じファイルをDropBoxに置くユーザって多いのでしょうか。ニコ動のmp4の例が挙がっているけど、そういうのを置く人がそんなに多いかというと、やや自分の直感に反しますがどうなんでしょうか?

      ネットで拾ったおもしろ画像とか置いている人が多いのかな。

  • by Anonymous Coward on 2011年05月19日 5時41分 (#1954849)
    クラウドサービスに見られては困るデータをアップロードするのが理解できない。
    • by Anonymous Coward
      まあ、聞かれたらまずい話を電話でするのと同じで、信用(法令違反ということで、相手が悪いということに出来る)の問題かと。
    • by Anonymous Coward
      パスワードをメールで送信しました。
      みたいなもんだと思って諦めてます。
    • by Anonymous Coward

      世の中には、IDManager や KeePass のデータファイルを Dropbox に入れておくとどこからでも共有できて便利!
      みたいなことをやってる人がいましてね。
      先日の LastPass 騒動のときに、そういった手法が Twitter とかで紹介されてました。
      LastPass 騒動のあとでそういうことを始めた人は、今頃gkbrしてるかもしれません。

    • by Anonymous Coward
      あなたの大切なファイルをオンラインでバックアップしてあげます、しかも無料です・・・これを不審に思わない人が多いんだなぁ。

      かつてメールに添付できないサイズのファイルを受け渡しする無料サービスがありましたが、ダウンロードにはメールで相手に送ったパスワードが必要なので第三者には漏洩しませんっていう説明だったけど、運営側はノゾキ放題だったろうね。
typodupeerror

「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常

読み込み中...