web-dev-qa-db-ja.com

暗号化の前にランダムデータでディスクを埋めますか?

暗号化する前にランダムなデータでディスクを埋めると、攻撃者が暗号解読を実行することが困難になると考えられます。これは、攻撃者が実際に暗号化されているデータを特定するのが難しいためであると述べられているようです(これはランダムなゴミです)。

しかし、これは厳密に必要ですか?大きなディスクの場合、ランダムデータでディスク全体を埋めるには、法外に長い時間がかかる場合があります。データが何らかの形で攻撃され、解読される可能性がある場合、この余分なハードルはどれだけ価値がありますか?この種の防止手法が実際に役立つ実際の懸念事項と攻撃シナリオは何ですか?

所有者が暗号化する前にランダムなデータでディスクを埋めることができなかったため、暗号化されたデータが復号化されたことはありますか?または、この実践は、実際には追加のセキュリティを提供しない、過度に偏執的な余分な手段ですか?

特定の回答を提供する必要がある場合は、システムがLUKS、AES 256ビットを備えたGNU/Linuxであり、通常のHDDにデータを暗号化していると想定します。 2つのパーティション:ブートにのみ使用される暗号化なしの/ bootパーティションと、上記の暗号化付きの1つのルートパーティション。

攻撃シナリオ:攻撃者は、電源をオフにした状態でコンピューターを入手します。コールドブート攻撃や邪悪なメイド攻撃が不可能であると仮定します。

10
ioctlvoid

これが必要な理由はいくつかあります。最初に、あなたが述べたように、それは暗号文と背景雑音の間の境界を識別することができないためにデータの解読を難しくします。これは、ボリュームの2つのスナップショットをキャプチャし、変化する場所を特定することで無効にできるため、この意味での具体的なセキュリティ対策とは言えません。この問題により、実際にはより重要な問題が発生します。ファイルシステムはデータをディスク上に均等に分散させず、多くの場合、残りのデータが滞留します。

ここで、背景のランダム性が重要になります。攻撃者が暗号文の古いブロックを識別できる場合。最近データが更新されたファイルから、2つの異なる平文に対して同じ鍵(おそらく同じIVも)を使用して、2つのバージョンの暗号文にアクセスできるようになりました。これにより、特定の攻撃シナリオがより現実的になる可能性があります。 差分暗号解読 。背景のランダム性により、暗号文の潜在ブロックを特定することは非常に困難になります。

バックグラウンドのランダムデータが必須であるもう1つのケースは、TrueCryptの隠しボリューム機能など、拒否が必要な場合です。攻撃者は、ボリュームが10GBを超えていることを確認できても、マウントされたときにボリュームが4GBとしてしか表示されない場合、6GBの隠しボリュームもあることがわかります。ディスク全体のデータを完全にランダムにすることにより、暗号文はそのバックグラウンドデータと区別できなくなり、隠されたボリュームの識別は不可能ではないにしても困難になります。

12
Polynomial

ここで言及する価値のあるいくつかのこと。まず、これはフルディスク暗号化の場合にのみ違いを生じます。ファイルアロケーションテーブル(または他のインデックス)が暗号化されていない場合、攻撃者がファイルの境界がどこにあるかを検出することは簡単です。

2番目の問題は、非常に敏感なドライブの静的分析です。特定の情報は、a)ドライブにあるデータの量、b)ドライブへの情報の割り当てによって、使用レベルやファイルサイズに関する情報が提供される可能性があることにより漏えいします。

3つ目は、Polynomialがファイルの残りがドライブに残されると述べた状況であり、差分分析や、最近変更された内容に関する情報を単にリークするのに役立つ可能性があります。

実際には、この情報は、最初の2つの場合、おそらくほとんどの場合は有用ではないでしょうか。しかし、差異分析は、データ回復につながる可能性のあるより実際的な脅威です。エントロピーを削減するものはすべて暗号化を弱めますが、ランダムな背景を持つ方が全体的に安全です。

1
AJ Henderson