[jansommer]

7+11 is default for BitLocker as far as I know. Binding to other values will bite you later if you update UEFI firmware or change some settings.

GRUB and all other boot loaders are unecessary with UEFI. See my comment history for more.

Kernel updates + Secure Boot is easy with a Debian hook.

The hard part is making it work with TPM when you want to add encryption...

[jansommer]

Found the article where I read about PCR 7+11 being the default [1]. The reason I looked it up is because if this is actually true, and the TPM is built into the cpu, what prevents someone from placing the cpu and disk on another motherboard?

Say that you have disabled usb booting and secured UEFI settings with a password. If you extract the cpu (and thereby its tpm) and the disk, then you'd still be able to boot, right? Meaning that without a TPM pin, you'd be able to do OP's attack on a different motherboard even when the original machine was off and UEFI settings secured.

What am I missing? Is it that easy to circumvent UEFI settings protection and maintain the PCR 7 value?

[1] https://blog.scrt.ch/2023/09/15/a-deep-dive-into-tpm-based-b...

[dist-epoch]

From what I know, the state of the UEFI settings is hashed into some PCR registers. Potentially even hardware serial numbers. Sometimes when I modify non-secureboot BIOS settings, Bitlocker complains and enters into recovery mode.

So I really doubt TPM will release the keys on a different motherboard with different UEFI settings.

User changed motherboard and TPM complains: https://old.reddit.com/r/pcmasterrace/comments/vdvni1/swappe...

[jansommer]

Odd that you have to recover from changing UEFI settings with Secure Boot! You should be able to change any setting when that's enabled. BitLocker binds to a lot of other things when SB is off and might be fragile in that state. But it does seem that some changes will affect PCR 7:

> PCR 7 changes when UEFI SecureBoot mode is enabled/disabled, or firmware certificates (PK, KEK, db, dbx, …) are updated. The shim project will measure most of its (non-MOK) certificates and SBAT data into this PCR. — https://uapi-group.org/specifications/specs/linux_tpm_pcr_re...

It makes sense to use the certificates to generate PCR 7. I wonder if you can swap out the motherboard with one of the same model with the same certificates without modifying the PCR 7 digest...

But if Shim actually modifies the digest, I guess that SB would completely mitigate OP's exploit since the TPM policy is going to fail when the PCR 7 values doesn't match.