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.
