Bypassing disk encryption on systems with automatic TPM2 unlock

You can mitigate this by including PCRs that sign the kernel and initrd, however it means whenever you update you need to unlock manually. On Redhat-based distros this can be done with PCRs 8 and 9, though IIRC this may change on other distros.

Also AFAIK there is no standard way to guess the new PCRs on reboot so you can't pre-update them before rebooting. So you either need to unlock manually or use a network decryption like dracut-sshd.

> You can mitigate this by including PCRs that sign the kernel and initrd

nope! the trick the article is describing works even if the kernel and initrd is measured. it uses the same kernel, initrd, and command line.

the reason this trick works is that initrds usually fall back to password unlock if the key from the tpm doesn't work. so the hack replaces the encrypted volume, not the kernel, with a compromised one. that is:

1. (temporarily) replace encrypted volume with our own, encrypted with a known password.

2. boot the device.

3. the automated tpm unlock fails, prompting for a password.

4. type in our password. now we're in, using the original kernel and initrd, but it's our special filesystem, not the one we're trying to decrypt.

5. ask the tpm again for the key. since we're still using the original kernel, initrd, and command line, we should now get the key to unlock the original encrypted volume.

the way to fix this is to somehow also measure encrypted volume itself. the article points to suggestions of deriving a value from the encryption key.

> 3. the automated tpm unlock fails, prompting for a password.

> 4. type in our password.

In a serious security conscious setup this should be a big red flag to investigate. Any unexpected boot password prompt.

yes of course - but in this case the "unexpected" prompt is presented to the attacker, not the user.