☰

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の奇妙なバイト。

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

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

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

おすすめ記事