Re: DOSing the TPM to leak the rootfs encryption key

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2025-03-10 19:04, Adrian Vovk wrote:

Presuming a system like this:
- We've got a Linux desktop system
- We have two dm-verity protected /usr partitions
- We have one encrypted rootfs
- We're using systemd-repart to create the rootfs on first boot
- The rootfs is automatically unlocked by the initrd, at boot, using the
TPM. We're using systemd-pcrlock with a PCR 11 signature
- We're making use of systemd-pcrphase, and the rootfs is unlockable _only_ during `enter-initrd`. Once we hit `leave-initrd`, the rootfs is no longer unlockable. This means that the rootfs is only unlockable in the initrd.

If this a good idea in general? This makes impossible to update the NVIndex policy automatically via the recovery PIN. You need to ask the user for the PIN after each new make-policy.

Here's a potential attack:

It is very similar to the original one published some months ago[1], and the one described in the other thread. All three boils to the same topic, the measure boot is stopping in the initrd and we need a way to authenticate the device before delegating the execution. Just continue the measure boot one extra step.

[1] https://oddlama.org/blog/bypassing-disk-encryption-with-tpm2-unlock/

The solution presented there will resolve the three instances of this attack. You just need to measure the vk of each device that is in the initrd's /etc/crypttab in an ordered way and halt the system from the initrd if the value is not the expected one. systemd could do that, but if not it is not hard to implement [2]

[2] https://github.com/openSUSE/sdbootutil/blob/main/measure-pcr-validator.service

- Meanwhile, the attacker starts DOSing the TPM (i.e. by physically
interrupting the TPM's LPC bus)

You would need a bit more than that. The tcti commands needs to be parsed and make some assumptions about the encrypted payload, to determine what commands to filer out.

[...]
Detecting the situation and causing boot to fail, as described above, would force the attacker to not only DOS the TPM but actually completely MITM it.
Is this possible? Is this something that parameter encryption defends
against?

Yes, they are for that[3].

[3] https://trustedcomputinggroup.org/wp-content/uploads/TCG_CPU_TPM_Bus_Protection_Guidance_Passive_Attack_Mitigation_8May23-3.pdf

PS: We should probably be locking the rootfs down to the initial state of PCR 15 too. Since we can assume that PCR 15 must be zeroed out before we
unlock the rootfs, we can actually check that.

That is not true, I commented that in a different thread. systemd-cryptsetup is racy. If you have for example cr_swap and cr_root, both in initrd's /etc/crypttab, then you do not know the final value of PCR15 (SHA256(HMAC("cryptsetup:cr_root:$root_UUID", "$vk_root") | SHA256(HMAC("cryptsetup:cr_swap:cr_swap:$swap_UUID", "$vk_swap"))) or SHA256(HMAC("cryptsetup:cr_swap:$swap_UUID", "$vk_swap") | SHA256(HMAC("cryptsetup:cr_root:cr_root:$root_UUID", "$vk_root")))

This adds an extra layer of
protection: the rootfs can only be unlocked if it's the first rootfs being
unlocked. But still: this doesn't defend against the DOS scenario I
describe here, since the attack completely bypasses the measurement into
PCR 15

With the initrd final service you would be protected. As commented is just one step more in the measured boot chain.



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux