LUKS2 と LUKS1 の違い:確認方法と変換方法

結論:LUKS2 は Linux のディスク暗号化における現行のディスク上フォーマットで、cryptsetup 2.1 以降のデフォルトです。LUKS1 と比べて、チェックサム付きで冗長化された JSON メタデータヘッダー、PBKDF2 に代わるメモリハードな鍵導出関数 Argon2id、8個ではなく32個のキースロット、TPM2 や FIDO2 での解錠に使うトークン、オプションの認証付き暗号化が追加されています。古い GRUB が単独で `/boot` を復号する必要がない限り、LUKS2 を使いましょう。

どちらのフォーマットもデータの暗号化方法は同じで、一般的には AES-XTS です。違うのはヘッダー、つまり鍵の保存方法、パスフレーズの総当たりの難しさ、そしてどのツールで読めるかです。このガイドでは、違い、どちらを使っているかの確認方法、ディスクを失わずに `cryptsetup convert` で変換する方法を解説します。小型 VPS 上のセルフホスティングスタックのために新しいサーバーを暗号化するなら、選ぶべきは LUKS2 です。

LUKS2 と LUKS1 の比較一覧

ヘッダーフォーマットとキースロット

LUKS1 のヘッダーは固定のバイナリ構造で、その後に8つのキースロット領域が続きます。誤った `mkfs` やパーティショニングツールなどでデバイスの先頭セクターが上書きされると、すべてのキースロットが失われ、ヘッダーのバックアップがない限りデータは失われます。

LUKS2 はバイナリヘッダーと JSON メタデータ領域を保存し、両方の2つ目のコピーを保持します。各コピーにはチェックサムがあるため、`cryptsetup` は破損を検出してもう一方のコピーに切り替えられます。JSON 領域にはキースロット、セグメント、ダイジェスト、トークンが記述されており、これによってフォーマットを再度変更せずに新機能を追加できます。それでも冗長化はヘッダーのバックアップの代わりにはなりません。先頭数メガバイトが完全に上書きされると、両方のコピーが破壊されます。

Argon2id と PBKDF2

パスフレーズがそのまま鍵として使われることはありません。鍵導出関数でパスフレーズを引き伸ばし、1回ごとの推測を高コストにします。LUKS1 で使えるのは PBKDF2 だけで、これは GPU や ASIC で安価に実行できるため、ヘッダーのコピーを持つ攻撃者はパスフレーズを高速に並列テストできます。

LUKS2 のデフォルトは Argon2id で、推測1回ごとに設定可能な量のメモリ(デフォルトで最大 1 GiB、フォーマット時の利用可能 RAM が上限)を必要とし、並列化のコストがはるかに高くなります。主な防御は依然として強力なパスフレーズですが、Argon2id は推測1回あたりのコストを大幅に引き上げます。

小型サーバーではメモリコストに注意しましょう。RAM の多いマシンで作成したキースロットは、NoctisNode のWisp プランのような 1 GB の VPS が initramfs 内で割けるより多くのメモリを解錠に必要とすることがあります。大きなマシンで小さなマシン用にフォーマットや鍵の追加を行う場合は、`--pbkdf-memory`(KiB 単位)で明示的に設定してください。

# Inspect PBKDF parameters of each keyslot
cryptsetup luksDump /dev/vda3 | grep -A6 '^  [0-9]*: luks2'

# Re-derive keyslot 0 with Argon2id and 512 MiB memory cost
cryptsetup luksConvertKey /dev/vda3 --key-slot 0 \
  --pbkdf argon2id --pbkdf-memory 524288

トークン、整合性保護、GRUB の注意点

トークンは LUKS2 ヘッダー内の JSON オブジェクトで、鍵を自動的に取得する方法をツールに伝えます。`systemd-cryptenroll` はこれを使ってキースロットを TPM2 チップ、FIDO2 セキュリティキー、PKCS#11 スマートカードに紐づけ、Clevis は Tang サーバーによるネットワークバウンドの解錠に使います。LUKS1 にはこれらは一切ありません。

整合性モード(`cryptsetup luksFormat --integrity hmac-sha256`)は暗号化と dm-integrity を組み合わせ、改ざんされたセクターが黙って書き換わったデータではなく読み取りエラーになるようにします。ディスク容量と書き込み速度を犠牲にし、フォーマット時に全体の消去が必要で、まだ実験的とされています。ほとんどのサーバーでは使われていません。

今でも LUKS1 に出会う主な理由は GRUB です。上流の GRUB 2.06 以降は LUKS2 を開けますが、Argon2 のサポートが上流の GRUB に含まれていないため、PBKDF2 を使うキースロットに限られます。GRUB 自体が暗号化された `/boot` を復号する必要がある場合は、LUKS1 か `--pbkdf pbkdf2` の LUKS2 キースロットを使ってください。Debian と Ubuntu のインストーラーは `/boot` を暗号化しないため、解錠はカーネルと initramfs が行い、SSH によるリモート解錠を含め Argon2id が動作します。

ボリュームが LUKS1 か LUKS2 かを確認する方法

稼働中のシステムで root として実行すれば、以下のどれでも確認できます。`cryptsetup luksDump` の `Version:` 行が確実な答えで、ダンプにはキースロット、PBKDF の種類、トークンも表示されます。

# Find encrypted partitions (FSVER column shows 1 or 2)
lsblk -f

# Authoritative: header version
cryptsetup luksDump /dev/vda3 | grep -E '^Version'
# Version:        2

# Exit code 0 only if the device is LUKS2
cryptsetup isLuks --type luks2 /dev/vda3 && echo LUKS2

cryptsetup convert で変換する

`cryptsetup convert` はヘッダーをその場で書き換え、暗号化されたデータには触れません。デバイスは閉じている必要があるため、ルートファイルシステムの場合はレスキューシステムやライブシステムから実行します。変換中の失敗や停電でヘッダーが使えなくなる可能性があるため、バックアップの手順は省略できません。

1. 01.レスキューまたはライブシステムを起動し、LUKS デバイスが開かれていないことを確認します(必要なら `cryptsetup close`)。
2. 02.`cryptsetup luksHeaderBackup` でヘッダーをバックアップし、ファイルをサーバー外にコピーします。このファイルと古いパスフレーズがあれば誰でもディスクを解錠できるので、暗号化して保管してください。
3. 03.`cryptsetup convert --type luks2` で LUKS1 を LUKS2 に変換します。既存のキースロットは PBKDF2 のままです。
4. 04.GRUB が読む必要がない限り、`cryptsetup luksConvertKey --pbkdf argon2id` で各キースロットを Argon2id にアップグレードします。
5. 05.デバイスが開けることをテストしたら、`update-initramfs -u` で initramfs を再構築して再起動します。
6. 06.LUKS2 から LUKS1 に戻すには、まずすべてのキースロットを PBKDF2 に変換し、トークンと LUKS2 専用機能を削除します。そうしないと `cryptsetup convert --type luks1` は拒否されます。

# From a rescue system, device closed
cryptsetup luksHeaderBackup /dev/vda3 --header-backup-file /root/vda3-luks-header.img

cryptsetup convert --type luks2 /dev/vda3
cryptsetup luksConvertKey /dev/vda3 --key-slot 0 --pbkdf argon2id

cryptsetup open /dev/vda3 cryptroot && cryptsetup close cryptroot

# Emergency restore (overwrites the current header!)
# cryptsetup luksHeaderRestore /dev/vda3 --header-backup-file /root/vda3-luks-header.img

Note · ヘッダーを復元すると、バックアップ時点で有効だったパスフレーズが再び使えるようになります。後から削除したものも含みます。パスフレーズをローテーションしたら古いヘッダーのバックアップは削除してください。現在のバックアップは、restic バックアップガイドで説明しているリポジトリなど、別の場所に保管しましょう。

よくある質問