Fedora Full-Disk Encryption with TPM2 + Secure Boot
A practical guide to setting up, managing, and recovering LUKS2 disk encryption using TPM2 + PIN on a Fedora laptop with Secure Boot.
How It Works
At boot, unlocking happens in this order:
UEFI + Secure Boot → GRUB → initramfs → TPM checks PCRs → PIN prompt → disk unlocked
Two independent unlock methods exist at all times:
| Slot | Type | When to use |
|---|---|---|
| 0 | Password | Recovery, firmware updates, fallback |
| 1 | TPM2+PIN | Normal daily boot |
Either slot unlocks the disk independently. Never delete slot 0.
PCR Reference — What Gets Measured
PCRs (Platform Configuration Registers) are slots inside the TPM that store hashes of the boot chain. Each PCR covers a specific layer. The TPM will only release the LUKS key if every selected PCR matches exactly what was recorded at enrolment time. If anything in that layer changed, the measurement changes, the PCR no longer matches, and the TPM refuses to unlock.
PCR Index Reference
| PCR | Measures | Changes when |
|---|---|---|
| 0 | UEFI firmware code | Firmware update |
| 1 | UEFI firmware config | BIOS settings changed |
| 2 | Option ROM / drivers | Hardware added or removed |
| 3 | Option ROM config | Hardware config changed |
| 4 | Bootloader (MBR/EFI binary) | GRUB updated or replaced |
| 5 | Bootloader config | GRUB config file changed |
| 6 | Platform state | Suspend/resume events |
| 7 | Secure Boot state + signing certs | Secure Boot toggled, cert rotation |
| 8 | Kernel command line | Boot parameters changed |
| 9 | initrd / kernel image | Kernel update |
| 11 | Unified kernel image (UKI) | UKI updated |
| 14 | Shim MOK certificates | MOK key enrolled or removed |
Why PCR 7+14 is the Right Choice for Fedora
Binding to PCRs 0, 4, 8, or 9 would mean re-enrolling on every kernel update, every GRUB config change, and every firmware tweak — far too much maintenance.
PCR 7 and 14 strike the right balance:
- PCR 7 captures whether Secure Boot is on and which signing certificates are trusted. This catches the most serious attacks: disabling Secure Boot, swapping to an untrusted bootloader, or loading an unsigned kernel.
- PCR 14 captures the shim's Machine Owner Keys (MOK). This detects someone enrolling a rogue signing key to bypass Secure Boot validation.
Together they give you strong tamper detection without breaking on routine Fedora updates. You only need to re-enroll when certificates actually change — which is rare and deliberate.
What Changes Will Break Unlock and Require Re-enrolment
The following will change PCR 7 or 14 and cause the TPM to refuse to unlock until you re-enrol (Part 4 of this guide):
- UEFI firmware update that rotates Secure Boot certificates
- Enrolling or removing a MOK key (
mokutil --import/--delete) - Disabling and re-enabling Secure Boot in UEFI settings
- Replacing the shim or bootloader with one signed by a different key
The following will not break unlock with PCR 7+14:
- Routine kernel updates
- GRUB config changes
- initramfs regeneration
- Adding or removing hardware
Part 1 — Initial Setup
Prerequisites
Confirm TPM2 is present and Secure Boot is enabled:
systemd-cryptenroll --tpm2-device=list
# should show /dev/tpmrm0
mokutil --sb-state
# should show: SecureBoot enabled
If you are on AMD, update firmware first to avoid the 2023 fTPM vulnerability:
sudo fwupdmgr refresh
sudo fwupdmgr update
Find your LUKS partition
lsblk
Look for a partition of type crypt — on NVMe laptops it is usually nvme0n1p3.
Confirm it is a LUKS2 device:
sudo cryptsetup luksDump /dev/nvme0n1p3 | grep -E "Version|LUKS"
# Version: 2
Enroll TPM2 + PIN into LUKS
sudo systemd-cryptenroll \
--tpm2-device=auto \
--tpm2-pcrs=7+14 \
--tpm2-with-pin=yes \
/dev/nvme0n1p3
You will be asked to:
- Set a new PIN
- Confirm the PIN
- Enter your existing LUKS passphrase to authorise the new slot
Verify both slots exist:
sudo cryptsetup luksDump /dev/nvme0n1p3 | grep -A2 "Keyslot"
You should see slot 0 (password) and slot 1 (tpm2).
Update /etc/crypttab
Find the current entry:
cat /etc/crypttab
# luks-<uuid> UUID=<uuid> none discard
Add the TPM2 options:
sudo sed -i 's/discard/discard,tpm2-device=auto,tpm2-pcrs=7+14,tpm2-pin=yes/' /etc/crypttab
Verify it looks correct:
cat /etc/crypttab
# luks-<uuid> UUID=<uuid> none discard,tpm2-device=auto,tpm2-pcrs=7+14,tpm2-pin=yes
Regenerate initramfs
sudo dracut -fv --regenerate-all
Reboot and test
sudo reboot
On next boot you will be prompted for your TPM PIN. If anything goes wrong, your original passphrase (slot 0) always works as fallback.
Part 2 — Change TPM PIN
You cannot edit a PIN in place. The process is: wipe the TPM slot, re-enroll with the new PIN.
Step 1 — Wipe the existing TPM slot
sudo systemd-cryptenroll --wipe-slot=tpm2 /dev/nvme0n1p3
You will be prompted for your LUKS passphrase to authorise the wipe. Confirm the slot is gone:
sudo cryptsetup luksDump /dev/nvme0n1p3 | grep -A2 "Keyslot"
# only slot 0 (password) should remain
Step 2 — Re-enroll with new PIN
sudo systemd-cryptenroll \
--tpm2-device=auto \
--tpm2-pcrs=7+14 \
--tpm2-with-pin=yes \
/dev/nvme0n1p3
Enter the new PIN when prompted, then your LUKS passphrase to authorise.
Step 3 — Regenerate initramfs
sudo dracut -fv --regenerate-all
sudo reboot
Part 3 — Change LUKS Passphrase
The passphrase lives in slot 0. You can change it without touching the TPM slot.
Step 1 — Change the passphrase
sudo cryptsetup luksChangeKey /dev/nvme0n1p3
You will be asked for:
- The current passphrase
- The new passphrase (twice)
Step 2 — Verify slots are intact
sudo cryptsetup luksDump /dev/nvme0n1p3 | grep -A2 "Keyslot"
# slot 0 (password) and slot 1 (tpm2) should both still be present
No reboot or initramfs regeneration needed — the passphrase change takes effect immediately. Test it:
sudo cryptsetup open --test-passphrase /dev/nvme0n1p3
# enter new passphrase — no output means success
Part 4 — Re-enroll After Certificate Changes
This is required when PCR measurements change and the TPM stops releasing the key. Common causes:
- UEFI firmware update
- Secure Boot certificate rotation (fwupd, shim update, kernel signing key change)
- MOK (Machine Owner Key) changes
- You replaced the bootloader
The symptom is: PIN prompt is skipped and you fall straight through to the LUKS passphrase. That is the fallback working correctly — your data is safe.
Step 1 — Boot using your passphrase
When prompted, type your LUKS passphrase (slot 0) instead of the PIN. The system boots normally.
Step 2 — Identify what changed (optional but useful)
# Check current PCR values
sudo systemd-analyze pcrs 7 14
# Compare to what the TPM slot was sealed against
sudo systemd-cryptenroll /dev/nvme0n1p3
Step 3 — Wipe the stale TPM slot
sudo systemd-cryptenroll --wipe-slot=tpm2 /dev/nvme0n1p3
Enter your LUKS passphrase to authorise.
Step 4 — Re-enroll against the new PCR state
sudo systemd-cryptenroll \
--tpm2-device=auto \
--tpm2-pcrs=7+14 \
--tpm2-with-pin=yes \
/dev/nvme0n1p3
The TPM now seals the key against the new, updated PCR measurements.
Step 5 — Regenerate initramfs
sudo dracut -fv --regenerate-all
sudo reboot
PIN unlock should work normally on next boot.
Quick Reference
| Task | Command |
|---|---|
| List TPM devices | systemd-cryptenroll --tpm2-device=list |
| Check Secure Boot | mokutil --sb-state |
| View LUKS slots | sudo cryptsetup luksDump /dev/nvme0n1p3 | grep -A2 Keyslot |
| Enroll TPM + PIN | sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7+14 --tpm2-with-pin=yes /dev/nvme0n1p3 |
| Wipe TPM slot | sudo systemd-cryptenroll --wipe-slot=tpm2 /dev/nvme0n1p3 |
| Change passphrase | sudo cryptsetup luksChangeKey /dev/nvme0n1p3 |
| Test passphrase | sudo cryptsetup open --test-passphrase /dev/nvme0n1p3 |
| Regenerate initramfs | sudo dracut -fv --regenerate-all |
| Check current PCR values | sudo systemd-analyze pcrs 7 14 |
Important Notes
- Never delete slot 0 (your passphrase). It is your only recovery path if the TPM fails.
- PCR 7+14 is the recommended combination — it detects Secure Boot changes without breaking on routine kernel updates.
- If you replace the laptop motherboard, the TPM is gone. Boot with passphrase and re-enroll.
- The LUKS passphrase is not the same as your Fedora login password. They are separate.