オンラインバックアップ：暗号化と重複除外はどのように互換性があるのでしょうか？
「間もなくベータ版」のオンラインバックアップサービスであるBitcasaは、重複排除（クラウドにすでに何かをバックアップしていない）とクライアント側の暗号化の両方を備えていると主張しています。
特許検索では、会社名は何も得られませんが、特許はパイプラインにあり、まだ許可されていない可能性があります。
私が現在持っている情報のレベルにかなり疑わしい主張を見つけました、それを達成するために主張する方法について誰もが知っていますか？会社の創設者に深刻なビジネス背景がなかった場合（Verisign、Mastercard ...）私はすぐに製品をヘビ油に分類したでしょうが、それ以上のものがあるかもしれません。
編集：心配なツイートを見つけました： https://Twitter.com/#!/csoghoian/status/113753932400041984 、ファイルごとの暗号化キーはそのハッシュから導出されるため、間違いなく次の場所ではないように見えますあなたの急流の映画コレクションを保管してください。
Edit2：私たちは実際にそれを正しく推測しました、彼らはいわゆる収束暗号化を使用しました。したがって、あなたが同じファイルを所有している人は、あなたがあなたと同じファイルであるかどうかを知ることができます。これにより、機密にしたいファイルがオリジナルでない場合、Bitcasaは非常に悪い選択になります。 http://techcrunch.com/2011/09/18/bitcasa-explains-encryption/
Edit3： https://crypto.stackexchange.com/questions/729/is-convergent-encryption-really-secure 同じ質問と異なる回答があります
詳細については考えていませんが、ファイルコンテンツの安全なハッシュをキーとして使用すると、「ハッシュを知っている」すべての（そして唯一の）クライアントがコンテンツにアクセスできます。
基本的に、クラウドストレージは、ハッシュ関数の集合部分（実際には非常にまばらな）Rainbowテーブルとして機能し、「逆転」できるようにします。
記事から：「RIAAとMPAAがBitcasaのドア、召喚状をノックしてきたとしても、Bitcasaが持つことになるのは、暗号化されたビットのコレクションだけで、それらを復号化する手段はありません。」 -bitcasaは、objectid/filename-to-hash/keyマッピングを保持しないため、trueです。クライアントのみが実行します（クライアント側）。 RIAA/MPAAが問題のファイルのハッシュを知っている場合（特定の曲のMP3などでよく知られています）、解読してコピーがあることを証明できますが、最初にどのクラウドストレージオブジェクトを知っている必要があります/ファイルはどの曲を保持しました。
もちろん、クライアントは、クラウドに保存された各オブジェクトのハッシュと、そのローカル名を保持して、オブジェクトにアクセスして暗号化を解除できるようにする必要があります。
記事で主張されている他の機能のいくつかについて：
- 「圧縮」-サーバー側では機能しません（暗号化されたコンテンツはうまく圧縮されません）が、暗号化する前にクライアント側で適用できます
- 「どこからでもアクセス可能」-objid-to-filename-and-hash/keyマッピングがクライアント上にある場合、ファイルは他のデバイスからは無用であり、クラウドストレージの有用性が制限されます。例えばによって解決することができますパスフレーズで暗号化されたクライアント側のobjid-to-filename-and-hash/keyタプルのコレクションも格納します。
- 「特許取得済みの重複除外アルゴリズム」-特許を正当化するためには、上記以外にもさまざまなことが必要です-ファイルレベルではなく、ブロック単位での重複除外が考えられますか？
- rIAA/MPAAには、召喚状と、人々がコピーを持っていると思われる曲/映画のハッシュ化されたコピーが付属しています。 Bitcasaは、そのファイルが保存されているかどうかを確認できます。彼らはそれを解読できません（RIAA/MPAAがハッシュ/キーを与えない限り）、そして（特に、ユーザーが「無限のストレージ」を提供するためにユーザーごとのクォータを実施していない場合）それらのログを保持していない可能性があります。ユーザーがアップロード/ダウンロードしたユーザー。ただし、ファイルの削除（DMCAセーフハーバールールに基づく）またはコンテンツの保持が必要になる可能性があるが、将来的にアップロード/ダウンロードするアカウントはすべてログに記録する必要があると思います。
あなたがリンクするコマーシャル広告と会社のウェブサイトは本当に情報が不足しています。能力の証明として「20件の特許」を振るのは奇妙です。特許は技術が良いであることを証明していません。テクノロジーが売れるという考えに数千ドル。
これらの約束を実現する方法があるかどうか見てみましょう。
データがクライアント側で暗号化されている場合、秘密鍵が必要ですKfそのファイル用。事の要点は、BitcasaはKを知らないということですf。重複除外とキャッシング、さらに重要なことには共有を実装するには、特定のファイルを暗号化するeveryユーザーが必要ですfは最終的に同じKを使用しますf。 Kのように、適切なハッシュ関数（SHA-256など）を使用して、ファイル自体のハッシュを使用することで構成される気の利いたトリックがありますf。このトリックにより、同じファイルは常に同じ暗号化形式になり、自由にアップロードして重複排除できます。
次に、ユーザーはすべてのKのlocalストア（自分のコンピュータ上）を持ちますf彼のすべてのファイルとファイルID。ユーザーAがファイルをユーザーBと共有する場合、ユーザーAは「右クリックして共有URLを取得」し、それをBに送信します。おそらく、URLにはファイルIDとKが含まれています。f。テキストは、ユーザーAとBの両方が共有を機能させるために登録ユーザーでなければならないことを示しているため、IDを抽出するいくつかのソフトウェアによってBのマシンで「URL」が傍受され、Kfその「URL」から、サーバーからファイルをダウンロードし、新しく取得したKの知識を使用してローカルでファイルを復号化しますf。
回復力と使いやすさを高めるために、既知のキーのセットKf一部のユーザーもサーバーに保存できます-したがって、単一のKを「記憶」するだけで済みますfキー。あるコンピューターから別のコンピューターに転送できます。
だから私はBitcasaが約束することは可能だと言います-私はそれを行う方法を知っているので、ここには本当に新しいものや技術的に進歩したものはありません。これがBitcasaが行うことだと主張することはできません。 「難しい」部分は、既存のオペレーティングシステムにそれを統合することです（「ファイルを保存する」と、暗号化/アップロードプロセスがトリガーされるようになります）。
Kを使用することに注意してくださいf = h（f）は、ファイルの内容を徹底的に検索できることを意味します。これは、重複排除を使用するサービスではとにかく避けられません。新しいファイルを「アップロード」して操作のタイミングをとるだけで、ファイルがサーバー側で既知であるかどうかを確認できます。
Bruce Schneierは5月にこの件について触れました http://www.schneier.com/blog/archives/2011/05/dropbox_securit.html その週のDropbox問題に関連しています。 TechRepublicは、電子メールのサインアップの価格について、この件に関する素晴らしい7ページのホワイトペーパーを提供しています http://www.techrepublic.com/whitepapers/side-channels-in-cloud-services-the- case-of-deduplication-in-cloud-storage/3333347 。
このホワイトペーパーでは、クラウドの重複排除で利用できるサイドチャネルと秘密チャネルの攻撃に焦点を当てています。攻撃は、クロスユーザー重複排除を利用します。たとえば、ボブがサービスを使用していて、テンプレートで作成された給与契約がそこにあることがわかっていれば、彼の給与に達するまで同じバージョンを作成できます。ファイルのアップロードにかかった時間で成功を示します。
もちろん、あなたの保護は、サービスを使用する前に暗号化することです。ただし、サービスのコスト削減が妨げられ、ほとんどすべての重複排除の機会がなくなるため、経済的に実行可能になります。したがって、サービスは選択を奨励しません。
ここでの他の良い答えに加えて、最近発行された次の2つの学術論文を紹介したいと思います。
Martin Mulazzani、Sebastian Schrittwieser、Manuel Leithner、Markus Huber、およびEdgar Weippl、 地平線上の暗い雲：攻撃ベクトルおよびオンラインスラックスペースとしてのクラウドストレージの使用 、Usenix Security 2011。
このペーパーでは、Dropboxがどのようにして重複排除を行い、メカニズムへの攻撃を識別するかについて説明します。クライアントは、ファイルへのアクセスが許可される前に、ファイルの内容（ハッシュだけではない）を知っていることをクライアントに要求することに基づいて、これらの攻撃のすべてではありませんが、一部を防御する新しい方法を提案します。
Danny Harnik、Benny Pinkas、Alexandra Shulman-Peleg。 クラウドサービスのサイドチャネル、クラウドストレージでの重複排除の場合 、IEEE Security＆Privacy Magazine。
このホワイトペーパーでは、重複除外を実行する3つのクラウドストレージサービス（Dropbox、Mozy、Memopal）を分析し、結果として生じるセキュリティとプライバシーのリスクを指摘します。彼らは、ファイルのコピーが多数ある場合にのみファイルが重複排除されることを保証することに基づいて、これらのリスクに対する新しい防御を提案し、それにより情報漏えいを減らします。
これらの論文はあなたの質問に直接関連しているようです。彼らはまた、素朴な重複除外のリスクに対する自明ではない緩和策にイノベーションの余地があることを示しています。
暗号化と重複排除任意のユーザー間は、特定の平文の区別が心配な場合は互換性がありません。これらのタイプの攻撃を心配していない場合は、安全です。
データが特定のユーザーに対してのみ重複排除されている場合、サーバーは平文の同等性について何も知らず、残っている攻撃は本当に軽微です。
サービスプロバイダーに知られていない何かを共有する友人の輪の間でデータが重複排除される場合（自動的に実行可能）、その友人の輪の人々だけが（タイミングなどを介して）平文を区別できます。
ただし、データがすべてのユーザー間で重複排除される場合、アクセスされるプレーンテキストを知りたいと考えているすべての仮想攻撃者は、ファイルをクラウドに保存し、どのユーザーアカウントが同じデータにアクセスしているかを監視する必要があります。確かに、サービスはデータにアクセスするユーザーアカウント/ IPアドレスを「ログに記録」することはできません。ただし、暗号化とは関係がなく、ファイルがプレーンテキストであっても同じ「保護」が維持されます。
ここに記載されている他の回答はどれも、this攻撃を阻止するものは何も提案していないようで、Bitcasaもそうではないと思います。私は間違っていると証明されて嬉しいです。
（注：あるこれに近いものを達成するためのいくつかの方法-あらゆる種類の革新的な技術を使用した安全なクラウドストレージについて発表されたかなりの数の論文があります-これらは新しい研究であり、それらのほとんどはおそらく壊れているか、実行可能ではなくかなり速く表示されます。それらのデータはまだ信頼できません。）
暗号スタック交換でも同じ質問がされました。見落としがちで、Tahoe-LAFSオープンソースプロジェクトによって慎重に分析されている微妙な点があるため、そこで私の回答をご覧ください。 https://crypto.stackexchange.com/questions/729/is -convergent-encryption-really-secure/758＃758
@Mishaが「既知のハッシュ」に投稿したばかりのすばらしい回答は別として、クライアント側の暗号化は、エスクローキーがない限り重複排除を実行する他の方法を効果的に削除します。