Re: Is tpm2-measure-pcr really an additional security?

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mo, 10.03.25 11:16, Adrian Vovk (adrianvovk@xxxxxxxxx) wrote:

> Hello,
>
> Just to see if I understand your concern correctly, I'll try boiling it
> down to its simplest, by cutting out the need for two partitions. Here's
> the scenario:
>
> - An attacker replaces the real rootfs with a malicious one that just drops
> to a shell. The attacker keeps a copy of the original real rootfs
>
> - The system boots, then tries and fails to decrypt the fake rootfs.
>
> - The attacker now starts impeding communication between the TPM and the
> CPU. Potentially by physically interposing on the bus and blocking
> communication. Or by glitching the bus so that the data isn't successfully
> measured. Anyway, the attacker somehow makes TPM measurements fail
>
> - The attacker unlocks their malicious rootfs, and then the system
> continues booting. The attacker now gains control of the system via the
> root shell.
>
> - The attacker stops impeding the communication between the TPM and the
> CPU. The TPM is still in the same state as it was in the initrd. The
> leave-initrd pcrphase, and the PCR15 measurement of the fake root's volume
> key, are both missing
>
> - The attacker is in control of the system, and the TPM is in the right
> state to unlock the real rootfs. The attacker talks to the TPM to get the
> real rootfs's volume key. Attacker wins
>
> I think, ultimately, this is the same issue as the one you describe. Do you
> think that's correct?
>
> Lennart would have a better idea than I do of what mitigations to this
> would look like. But I suspect that:
>
> - You can't MITM the TPM, since the communication is encrypted

Nope. PCR measurements are not encrypted, at least not by systemd.

Lennart

--
Lennart Poettering, Berlin