ファイルベースのファイルシステム暗号化のためのESSIVを使用したXTSとAES-CBC
私が最近読んだ「 You Do n't Want XTS 」というブログ投稿で、著者はファイルシステムを暗号化するためにXTSを使用する際のいくつかの落とし穴について説明しています。具体的には、XTSでファイルベースのディスクが暗号化されている場合、Dropboxなどのサービスを介して暗号化されたファイルベースのファイルシステムを共有しないことをお勧めします。
TrueCryptは暗号化されたファイルベースのファイルシステムを作成するためのかなり簡単な方法を提供するので、サムドライブまたはインターネットを介してファイルシステムを移動する必要があるときに物事を安全に保つためにこれを以前使用しました。
Dm-cryptはデフォルトでXTSの代わりにESSIVを備えたAES-CBCを使用しているように見えますが、XTSでのTrueCryptと同じ脆弱性の犠牲になりますか？
XTSに関する批判は、攻撃者が暗号化されたディスクの連続するバージョンを観察できる状況で意味があります（つまり、攻撃者はラップトップを盗み、ディスク全体のイメージを作成し、ラップトップをバッグに戻し、何も気づきませんでした。 ;そして、彼は明日、明日の翌日などにそれを繰り返します...）。 XTSを使用すると、16バイトのブロックごとに暗号化されるため、攻撃者は同じ暗号化されたブロックの連続する2つのバージョン（ハードディスクの同じセクター内の同じ16バイトのブロック）に同じデータが含まれていることに気付く場合があります。これにより、潜在的に トラフィック分析 が可能になります。攻撃者がアクティブになると、任意のブロックの古いバージョンを元に戻すことができ、すべてのブロックに対して個別に元に戻すことができます。
CBC + ESSIVを使用すると、各セクターに独自のIVがあるため、繰り返し発生する攻撃者は、以前のバージョンと同じブロックのシーケンスでセクターの新しいバージョンが始まるときに気付くことができます。 CBCは、セクター内のある時点で2つの平文ブロックが異なる場合、そのセクター内の残りのブロックが分岐するようになっています。その意味では、XTSと比較して、CBC + ESSIVのトラフィック分析に対する攻撃者の能力は低下します。たとえば、特定のセクターの2つのバージョンが13番目のブロックに同じ平文値を使用する場合、これはXTSで明らかになり、CBCではそうなりません（以前の12セクターのバージョンも変更されていない場合を除く）。
一方、アクティブな攻撃者は、ブロック内でビットを自由に変更できるので、CBCに満足していることがよくあります（ただし、前のブロックを制御できないランダムなジャンクで置き換えてもかまわない場合）。
そのため、dm-cryptにはTrueCryptと同じexact脆弱性はありません。想定されるシナリオ（同じディスクの盗聴の繰り返し、敵意のある変更...）は、フルディスク暗号化の主な目的ではありません。本当に、FDEは「盗まれたラップトップ」の状況を想定して作られたもので、あなたはそれを取り戻すことはできません。どちらのソリューションも、より勤勉な攻撃者に対してうまく機能しませんが、まったく同じように失敗するわけではありません。