feat(security): bind TPM2 auto-unlock to PCRs 0+7

[luminoso]

What changes

Binds TPM2 LUKS auto-unlock in luks-tpm2-autounlock to PCRs 0 and 7 (--tpm2-pcrs=0+7).

Why

The script previously passed --tpm2-pcrs='', which bound the LUKS token to no PCRs. With an empty PCR policy, the TPM chip unseals the drive key unconditionally for any software booted on that board.

Binding to 0+7 ensures the TPM checks system integrity before releasing the key:

• PCR 0 validates the core UEFI firmware code.
• PCR 7 validates Secure Boot state and certificates (PK, KEK, db, dbx, shim SBAT).

If Secure Boot is turned off or an unsigned bootloader runs, PCR 7 changes and the TPM hard-locks.

Threat model and limitations

This is an incremental hardening step, not a complete solution against all physical attacks.

Current Fedora and Universal Blue systems use split boot components: GRUB, a separate initramfs, and a mutable kernel command line. Because these change across updates, binding PCRs 8, 9, 11, or 12 directly is not feasible without breaking unlock on every update.

This leaves specific gaps where combining a PIN with PCRs helps:

• Why PIN alone is insufficient: A PIN stops unauthorized power-ons on clean hardware. However, without PCR binding, an attacker can modify the unencrypted boot partition with a fake prompt or malicious initramfs. The TPM would release the decryption key as soon as the user enters the PIN.
• Why PCRs 0+7 help: When an attacker modifies the boot chain or disables Secure Boot, PCR 7 changes. The TPM refuses to release the key even if the valid PIN is provided.

A full solution for verified passwordless boot requires signed Unified Kernel Images (UKIs) and composefs (as described in the Fedora Magazine article on sealed atomic desktops). Until UKIs land in standard builds, combining PCRs 0+7 with an optional PIN is the safest baseline available on split boot chains.

Trade-offs

• PCR 1 is excluded: measuring SMBIOS data and hardware config causes false-positive lockouts on RAM upgrades, dock connections, and standard BIOS setting changes.
• PCR 7 is required: without it (such as using 0+1), disabling Secure Boot leaves the disk unlock open to unsigned boot media.

References

• UAPI Linux TPM PCR Registry
• Sealed Fedora Atomic Desktop bootable container images

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[renner0e]

Hmm, secureblue uses 7+14, might be worth looking into why they are doing that

https://github.com/secureblue/secureblue/blob/91526a2533684b9e4bbca2aea5e159fb7c0a37c3/files/system/usr/libexec/luks-enable-tpm2-autounlock.sh#L92

[luminoso]

Good point. shim measures the Machine Owner Key (MOK) list into PCR 14.

While PCR 7 covers the firmware Secure Boot certs and db/dbx, enrolling a custom MOK key to sign and load an unauthorized kernel or driver only trips PCR 14. Binding PCR 14 closes that gap.

Since we enroll one, having PCR14 sounds good. I have updated the PR to include PCR 14 in the policy (0+7+14).

[renner0e]

This is related https://github.com/rhboot/shim/blob/main/README.tpm

[luminoso]

Thanks for the reference. That confirms PCR 14 covers MokList and MokSBState under shim.

Maybe the way to go for now is keeping this simple with 0+7+14 as a solid baseline. Upstream work like the Fedora Sealed Atomic Desktops project (signed UKIs + composefs) will eventually handle full measured boot cleanly. In the meantime, this seems like a sensible step forward without over-complicating the script.

[renner0e]

thanks