Recovery methodsTechnical

LUKS Headers, Keyslots and Volume-Key Recovery

LUKS stores the volume key behind one or more keyslots. LUKS2 duplicates its own metadata but not all keyslot material, which makes header and keyslot preservation — a header backup especially — critical to recovery.

dm-crypt data, protected by a separate volume key

LUKS is a key-management format layered above dm-crypt. The user's passphrase or key material is not normally the direct sector-encryption key: it is processed through a key-derivation function, the result unlocks one keyslot, that keyslot yields the volume key, and the volume key unlocks the dm-crypt data area. Changing a LUKS passphrase usually changes a keyslot, not the encrypted data area itself.

Multiple keyslots are alternate unlock paths

LUKS supports several keyslots at once, which can hold multiple passphrases, key files, or token-driven unlock mechanisms, and which support migrating from one credential to another over time. As long as one valid keyslot remains usable, the same underlying volume key can still be recovered — losing one LUKS password does not by itself mean losing the volume if another enrolled slot or token still exists. Recovery intake should always ask whether unlock was ever TPM-, FIDO2-, smartcard- or keyring-based rather than assuming password was the only path.

LUKS2 metadata is explicitly redundant — but not the keyslot data

Cryptsetup documentation states that LUKS2 stores its metadata area twice, with a binary header carrying fields such as version, metadata-area size, sequence ID, checksum algorithm, UUID and header offset, alongside JSON metadata describing keyslots, segments, tokens, digests and configuration. Cryptsetup states that on-disk metadata is redundant, that corruption can be detected, and that recovery can occur from the metadata copy — but it also specifically notes that keyslot binary data does not have equivalent automatic redundancy. One metadata copy surviving does not guarantee the keyslot area needed to actually unlock the volume has survived with it.

Sequence IDs identify which metadata generation is current

The LUKS2 binary header's sequence ID increases with updates, and because two metadata copies can exist, this generation information helps determine which copy is actually current. This is the same cross-cluster theme that appears in APFS transaction IDs, RAID member generations and filesystem journals: valid cryptographic metadata can exist in more than one generation, and recovery needs the correct, coherent one rather than merely the first readable header.

Header backups can outlive a changed passphrase

cryptsetup luksHeaderBackup stores the LUKS header and keyslot area. Cryptsetup documents that a header backup, combined with a passphrase that was valid at the time the backup was taken, can still decrypt the LUKS data area even after that passphrase has since been changed or removed from the live device. A header backup is therefore not merely geometry metadata — it can preserve exactly the keyslot state needed to recover the volume key, and it deserves to be stored and protected separately from the encrypted data itself.

A header backup is itself sensitive key material

Because an old header backup preserves the keyslot state needed to attempt unlocks against the volume key, holding onto one can undermine an attempt to “remove” an old credential by deleting its live keyslot — the backup can still be used against the same volume key. Cryptsetup explicitly warns that header backups should be securely destroyed once no longer wanted. In a recovery context, preserve header backups as evidence, but treat them like credentials rather than ordinary diagnostic files.

Tokens add another, sometimes overlooked, unlock layer

LUKS2 metadata can describe tokens integrating with TPM2, FIDO2, smartcards, keyrings or systemd enrollment workflows, depending on the deployment. “I never typed a LUKS password” does not mean no recovery protector exists — it may mean the enrolled protector was never password-based in the first place.

Decrypt what survives, then recover the filesystem

When the encrypted data area itself is partially damaged, decrypt whatever sectors survive first, then attempt filesystem-level reconstruction of ext4, XFS or whatever sits above the dm-crypt layer — not the reverse. As elsewhere in this cluster, unlocking successfully says nothing about the health of the filesystem underneath.

Practical rule

A LUKS header backup should be treated as sensitive key material, not just filesystem metadata — preserve it during recovery, and protect or destroy it deliberately afterward.