3 ms·
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-secure
by dist-epoch 2y ago
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/swapped_motherboards_and_now_it_wont_boot_up_keep/ https://old.reddit.com/r/pcmasterrace/comments/vdvni1/swappe...
- jansommer 2y agoOdd 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_registry/ 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.