On Mon, Mar 10, 2025 at 09:10:59PM +0000, aplanas wrote: > 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 How does parameter encryption establish the shared secret between the CPU and the TPM? Ideally the secure connection would be established at CPU reset using a secret fused into the CPU, and a hash of that secret would be measured by the TPM itself. Unfortunately, this is not a feature TPMs have. Mobile secure elements solve this by having the SoC and the secure element permanently paired to each other, allowing them to mutually authenticate and establish an encrypted and authenticated connection. I don't know any way to do this with a TPM. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab
Attachment:
signature.asc
Description: PGP signature
