☰

LUKS暗号化のビット回転

tag-icon • tag-icon filesystems luks disk-encryption corruption
LUKS暗号化のビット回転

ビット腐敗はLUKSコンテナと内部ファイルシステムにどのような影響を与えますか？

ビット破損を処理するのに適したファイルシステムがあるとしましょう。今LUKSコンテナに入れてください。ビット破損が原因でコンテナが破損した場合、復号化されたファイルシステムが破損した生のバイト/ブロックを大量に受ける可能性があるとします。

LUKSはこれをどのように防止しますか？

答え1

LUKSヘッダーのBitrot（キーおよびその他のキーデータ）：*パフ*すべて書いた。

（LUKS2ヘッダにはいくつかの冗長性とチェックサムがありますが、多くの部分は含まれていないため、おそらくまだなくなっているようです。）

暗号化されたデータのBitrot：暗号化モードによって異なりますが、通常1ビットの切り替えにより16個の誤ったバイトが生成されます。

暗号化設定：

# truncate -s 32M bitrottest.img
# cryptsetup luksFormat bitrottest.img
# cryptsetup luksOpen bitrottest.img bitrottest

すべて0にする：

# shred -n 0 -z /dev/mapper/bitrottest 
# hexdump -C /dev/mapper/bitrottest 
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
01000000

少し反転してください。

# losetup
NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE           DIO LOG-SEC
/dev/loop0         0      0         1  0 bitrottest.img        0    4096
# dd bs=1 count=1 skip=30M if=/dev/loop0 | hexdump -C
00000000  a2                                                |.|
00000001
# printf "\xa3" | dd bs=1 count=1 seek=30M of=/dev/loop0
# dd bs=1 count=1 skip=30M if=/dev/loop0 | hexdump -C
00000000  a3                                                |.|
00000001

結果：

# hexdump -C /dev/mapper/bitrottest 
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00e00000  eb d1 bd b0 2a f5 77 73  35 df 82 40 1e a7 27 11  |....*.ws5..@..'.|
00e00010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
01000000

1つのフリップビット、16の奇妙なバイト。

守る？まったく。これを行うには完全性を追加する必要があります（単にバグレポートの場合、冗長性はまだ別の問題です）。

破損したデータを意図的にストレージに書き込まないでください。

ストレージは誤ったデータを返すのではなく、読み取りエラーを報告する必要があります。この場合、データはまだ消えていますが、少なくとも消えませんでした。静かなビット回転。

答え2

LUKS自体はビットの腐敗を防ぎません。ブロックデバイスレベルでのビット腐敗を防ぐには、次のものが必要です。DMの整合性。 LUKS 2はIntegrityと組み合わせて次のようになります。認証された暗号化（cryptsetup luksFormat使用済み--integrity）これを使用すると、システムはデータが変更されたことを検出できますが、これは実際にビット破損を防ぐのに役立ちません。セクタを読み取ろうとすると、どうすればいいかわからない場合は、セクタでIOエラーが発生します。それを修正しようとしています。 （AEADの目的は、誰かが暗号化されたデータを変更した場合を検出することです。）

実際にデータを回復するには、RAID 1が必要であり、自己修復を可能にするためにRAID脚の下に別々の整合性デバイスが必要です（これは自動的に機能し、RAIDは片足からIOエラーを取得し、もう一方の脚からデータを読み取って修復します。 （試してみてください）。新しいシステム250起動中に/etc/integritytab（ルートではないファイルシステムの場合）、整合性デバイスの組み立てのサポートが追加されたため、試してみることができます。ただし、暗号化されたデータでエラーを修正する必要があるため、@frostschutzが彼の答えで示したように機能するには、これらの操作をすべてLUKSレベルの「下」で実行する必要があります。

関連情報