Re: DOSing the TPM to leak the rootfs encryption key

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

 



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


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

  Powered by Linux