Comment by keeperofdakeys

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

No, that's not an effective mitigation. The signed kernel+initrd would still boot into the impersonated root.

> 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.

With some logic to update the values on kernel updates and re-seal the secret this can be handled transparently. That's the design with sdbootutil in openSUSE (https://en.opensuse.org/Systemd-fde, https://github.com/openSUSE/sdbootutil).

You can use tpm2_policyauthorize and allow the PCR to change without having to manually unlock. This was not supported in TPM 1.2.

You can use it with Systemd.

https://github.com/tpm2-software/tpm2-tools/blob/master/man/...

> 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.

It's ridiculous that there's no software implementation to do this, it's a huge problem.

Auto update should be able to include the kernel, initrd and grub cmdline from the running system I have no idea what's holding this back since evidently code already exists somewhere to do exactly that.

At least for PCR 7, it's well specified and documented how the digest is generated. You can dump the component digests of a PCR using `tpm2_eventlog`, and I've written a tool that can be used to populate the requisite data structures for hashing.

https://github.com/balena-os/tcgtool