Linux、TRESOR、XTS
フルディスク暗号化にLUKSを使用することから [〜＃〜] tresor [〜＃〜] に切り替えたい。 TRESORは、暗号化キーをCPUのレジスタに格納することにより、コールドブート攻撃を防止しようとします。 IVの取得やXTSのようなモードの使用などにカーネルの暗号APIを使用します。ただし、実際のキーはカーネルの起動後に要求され、その後暗号APIを介して暗号に渡されたキーは無視されます。
XTSモードを使用する場合、キーは通常2つに分割され、1つは実際のキーとして使用され、もう1つはIVを生成するために使用されます。しかし、TRESORはすべてのキーを無視するため、カーネルは2つの同一のAESキーを使用することになります。私が収集できるもの この質問 とそこにリンクされている論文から、XTSは、そのように使用されると、選択された暗号テキスト攻撃に対して脆弱です。
これは実際に問題になる可能性がありますか？代わりにどの操作モードを使用できますか？コードを見ると、cbc-essivも独自のキーを提供する必要があるようです。
これは、単にtresor-xts-plainまたはtresor-xts-plain64を使用しようとした場合に問題になる可能性があります。広範囲にわたるテストは行っていませんが、cbc-essivを使用してTRESORを試した場合でも、システムが機能しなくなりました。単一のキーを使用するcbc-plainのみが機能しました。私が個人的にTRESORを使用する方法は、serpent-xts-plain64とチェーンされたtresor-cbc-plainを使用することです。誰かがコールドブート攻撃を実行して蛇の鍵を取得できた場合、コールドブート攻撃は特にステルスではないため、cbc-plainに対して柔軟性攻撃を実行できないと思います。 cbcには他にもいくつかの弱点がありますが、通常、機密性は引き続き維持されます。
ただし、回避策がある場合があります。 TreVisor と呼ばれるハイパーバイザーBitVisorへのパッチがあり、XTSキーでTRESORを使用できます。パッチをよく読んでいません。おそらくtresor_xts_crypt()関数を見ると、何らかの洞察が得られるでしょう。そのメインページは真ん中の here です。
RamCrypt もあり、TRESORを使用して個々のプロセスのメモリページを暗号化します。 XTSに似たXEXモードの操作を使用します（これもTweakキーを使用しますが、Tweakキーはデータキーと同じです）。 ramcrypt_page_crypt()関数は、出発点として適しています。そのメインページは here です。
少なくとも、TreVisorにはこの問題に対する賢い回避策があります。 XTSモードでは追加のキーであるTweakキーが必要になるため、TreVisorは単純に暗号化に半分のサイズのキー（256ではなく128ビット）を使用し、空きの128ビットを使用してTweakキーを格納します。 RamCryptも同様のことをしていると思います。 read_key_0およびread_key_1マクロ、およびTreVisorパッチのencrypt_blockおよびdecrypt_blockマクロのup引数を参照してください。