Lion Cipher Lab

Seal a LUKS disk-encryption key to the TPM's measured boot (auto-unlock only when the boot chain is intact)

• Cyber / Security Engineer
• Advanced
• ~90 min
• Free · no account required

Why it matters

Everyone learns that full-disk encryption protects a laptop that's lost or stolen. Far fewer can answer the very next question a real system has to solve: if the disk is encrypted, WHO types the passphrase when the server reboots at 3am in a locked cage? The mature answer is to bind the unlock key to the machine's MEASURED BOOT state using a TPM — the disk auto-unlocks with no human, but ONLY if the firmware, bootloader, and kernel that booted are the ones you trusted when you sealed the key. Tamper with the boot chain (an evil-maid swaps the bootloader, someone boots a rescue USB to read…

What you'll learn

• the distinction that trips everyone: 'the disk is encrypted' vs 'the key is protected' — TPM auto-unlock trades a passphrase prompt for boot-state binding, it adds NO extra encryption
• what a TPM PCR is and what the common ones measure — PCR 0 = firmware/UEFI code, PCR 7 = Secure Boot policy state, PCR 11 = the systemd-measured kernel/UKI — and why the PCR choice is the whole ballgame
• creating a LUKS2 container inside a disposable LOOP FILE (never a real partition) and adding a passphrase keyslot as the permanent fallback BEFORE anything else
• sealing a second unlock key into the TPM with `systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7`, which writes a LUKS2 token bound to the current PCR values
• proving auto-unlock: opening the volume with `systemd-cryptsetup attach ... tpm2-device=auto` and no passphrase, then reading the LUKS2 tpm2 token/keyslots with `cryptsetup luksDump`
• BREAKING the seal reproducibly with `tpm2_pcrextend` so the sealed PCR no longer matches, watching the TPM unseal fail, and watching the unlock fall back to the passphrase keyslot
• the named failure modes: PCR brittleness (too many/wrong PCRs -> disk stops unlocking after every legit kernel/firmware update), NO fallback keyslot -> a broken PCR or dead TPM = PERMANENT data loss, and the TPM dictionary-attack lockout after repeated bad unseals
• managing keyslots and TPM tokens safely: inspecting with `cryptsetup luksDump`, re-enrolling after a legitimate change, and removing a slot with `systemd-cryptenroll --wipe-slot` (never the fallback)
• the judgment call: brittle RAW-PCR policy vs systemd's SIGNED PCR policy (`--tpm2-public-key`, PCR 11 kernel-signature binding via UKI / systemd-pcrlock) which survives updates, plus Clevis/Tang network-bound (NBDE) as the alternative anchor
• what a TPM does and does NOT stop — it does not defend against a cold-boot attack on live RAM, an evil-maid attack that captures the passphrase, or a PCR 7 that stays valid across a malicious-but-Secure-Boot-signed kernel

Steps in this lab

1. The mental model: 'encrypted' vs 'key protected', PCRs, and sealing
2. Stand up the disposable VM, confirm the TPM, install the tools
3. Build the THROWAWAY LUKS2 volume on a loop file — with a passphrase keyslot FIRST
4. Seal a TPM keyslot to PCR 7 with systemd-cryptenroll
5. Prove it: auto-unlock with NO passphrase via the TPM
6. BREAK the seal: change PCR 7 and watch the fallback fire
7. The named failure modes — brittleness, no-fallback data loss, DA lockout
8. The judgment: raw-PCR vs SIGNED policy, Clevis/Tang, and what a TPM does NOT stop

Open the full interactive lab →