LUKS 暗号化ボリューム (のみ) を含むディスクがあります。これは、cryptsetup v.1.6.1 を使用して、パーティション テーブルのないベア ドライブに作成されました。ロックを解除すると、復号化されたボリュームのサイズを確認し、ディスク全体と比較すると、その差がちょうど 2MB であることがわかります。一方、ヘッダーをバックアップする場合は、次のようにします。
cryptsetup luksHeaderBackup /dev/sda --header-backup-file <filename>
2MBより30KB少ないファイルがあります。ddを使用してディスクの最初の2MBをダンプし、バックアップされたヘッダーと比較すると、末尾の30KBが欠落しており、すべて0であることがわかります。奇妙なことに、cryptsetup 1.4.1と1.4.3を使用してさまざまな（他の）LUKSヘッダーのバックアップがあり、それらはすべてちょうど2MBです。これは、cryptsetup FAQ のセクション 6.2ヘッダー サイズは 2MB にする必要があると書かれています。
この 30KB が何なのか理解するのを手伝ってくれる人はいませんか? (別のデバイスに置いたので、ヘッダーをランダム データで上書きしたいのですが、何をしているのか確実に知りたいです。)
また、より一般的な問題として、luksDump の出力などを使用して、ヘッダーがディスク上のどこにあるのかを正確に知るための、より簡単で自動化された方法はありますか? (オフセットとサイズの両方)。cryptsetup の FAQ を読みましたが、結果は確かに単純には表示されません。
また、dd を使用するよりもヘッダーを上書きするより良い方法はありますか?
cryptsetup luksHeaderRestore <file_with_random_data>
動作しません。cryptsetup は、既存のヘッダーがマスター キーのサイズとオフセットと一致するかどうかを確認するために、何らかの愚かなチェックを実行するためです。
答え1
30k は未使用の領域であることがわかりましたが、ヘッダー データは 1MB に揃えられています。以前のバージョンの cryptsetup でバックアップしたときには 2MB 全体が含まれていましたが、それ以降のバージョンでは省略されています。
payloadOffset 出力cryptsetup luksDump(512B セクターの数) を使用すると、暗号化されたボリュームが始まるオフセットを確認できるため、そこまで手動で消去できます。または、cryptsetup 1.6.4 以降では、 を使用してcryptsetup luksEraseすべてのアクティブなキースロットを上書きできます。メタデータを含む残りの表示ヘッダーはディスクの最初の 4KB であるため、手動で消去する必要があります。
[cryptlab の cryptsetup 開発者の一人、Milan に感謝します!]