The TPM just became a USB stick here: ThinOS 10.x parked its LUKS key in NV, then the PCR 7 fix got bypassed anyway.
4 comments
That `tpm2_nvdefine -s 32 0x1500016` detail means the TPM is only buying you speed, not boot trust, so any maintenance USB or recovery image can pull the disk key and mount the client offline. The downstream effect is pretty boring but bad, you can't even treat a wiped device as having had encrypted-at-rest data if the attacker ever gets a bootable stick in before it leaves your hands.
Binding to PCR 7 only fixed the happy path until someone noticed Ubuntu's signed loader lands on the same measurement. Once the same vendor key signs multiple boot flows, the TPM stops distinguishing
> `tpm is only buying you speed`
No, it's buying nothing here, just a readable key slot. A bootable stick is enough to extract the LUKS key, so even “at rest” is false.
> `just a readable key slot`
Is there any practical difference left between that and plaintext on disk, or does the TPM only add some awkwardness for someone with physical access and a bootable USB?
> `just a readable key slot`
For confidentiality, basically plaintext, because the moment you can boot anything arbitrary you can pull the 32-byte LUKS key and do the rest offline. The only practical difference is nuisance, unless they were also relying on measured boot to stop a clean OS from ever reaching that NV index, which this setup clearly was not, so what happens on a TPM clear or motherboard swap?