Recovery methodsTechnical

Encryption Key Hierarchies and Recovery Metadata

Strong storage encryption normally separates the data-encryption key from the password or recovery credential a person actually holds — recovery depends on preserving the metadata and protectors that connect those layers, not on breaking the cipher itself.

The password is not usually the sector key

BitLocker, FileVault/APFS encryption and LUKS all separate a password or recovery credential from the key that actually transforms data on disk. A person's credential typically unlocks or derives access to an intermediate key, which in turn protects the real data-encryption key. This is deliberate: it lets a password change without re-encrypting an entire volume, and it means “the password is correct but the drive will not unlock” is not automatically proof that the password is wrong — the layer that connects password to data key can fail on its own.

Data key vs. key-encryption key

Across BitLocker's FVEK/VMK pair, FileVault's volume encryption key wrapped by a KEK, and LUKS's volume key behind one or more keyslots, the same basic shape recurs: one key actually encrypts the data, and a separate wrapping layer controls who can reach that key. Changing an unlock credential normally changes how the data-encryption key is wrapped, not the encryption applied to every data block already on disk.

Key protectors are alternate paths to the same key

A single data-encryption key is commonly reachable through more than one protector at once — a TPM, a PIN, a recovery password, a key file, an enterprise recovery agent. Losing or failing one protector does not necessarily mean the underlying key is gone; another valid protector already attached to the same volume may still reach it. Recovery intake should enumerate every protector that might exist, not stop at the one that just failed.

Key rotation without re-encrypting the volume

Because the wrapping layer is separate from the data-encryption key, a user can typically change a password, rotate a keyslot or issue a new recovery credential without the system re-encrypting every sector on the volume. This is a general principle across BitLocker, FileVault and LUKS, and it is also why an old, no-longer-active credential can sometimes still unlock a preserved header or key backup taken before it was rotated out.

Encryption metadata is recovery evidence, not overhead

The structures that connect a protector to the data-encryption key — key packages, header areas, keyslot data, escrow records — are themselves a recovery-critical asset, separate from both the ciphertext and the credential. Metadata damage can make an otherwise-correct credential functionally useless, because the system no longer has the information needed to apply it. Preserving the encrypted volume without preserving this metadata is an incomplete preservation.

Hardware-bound protectors change what “offline” means

Some protectors are bound to specific hardware — a TPM's measured boot state, a Secure Enclave's hardware UID. Where that applies, an imaged or removed storage device alone may not carry everything needed to unlock it independently of the original system. This should be assessed per platform and per generation of hardware rather than assumed universally, since older and newer implementations of the same technology can differ substantially.

Header and key-metadata backups can outlive their live counterpart

A preserved backup of header or keyslot metadata, taken while a since-changed credential was still valid, can sometimes still unlock a data-encryption key even after that credential is no longer active on the live volume. Such a backup is not routine diagnostic material — it is sensitive key-adjacent data and should be preserved and protected accordingly.

Decrypt before filesystem recovery, not instead of it

An encrypted volume adds a layer between the raw device and its filesystem: device → encryption metadata → key hierarchy/unlock → decrypted logical volume → filesystem → files. A filesystem tool has no reason to recognize ciphertext as a valid NTFS, APFS or ext4 structure, so on unstable media the safe order is to image the encrypted source first, recover enough encrypted sectors to work with, unlock/decrypt, and only then attempt filesystem reconstruction.

Practical rule

Preserve both the ciphertext and the metadata that explains how the encryption key is wrapped. Either one alone can leave a technically correct credential with nothing left to apply it to.