[systemd-devel] DOSing the TPM to leak the rootfs encryption key

[aplanas]

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.