Re: DOSing the TPM to leak the rootfs encryption key

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mo, 10.03.25 15:04, Adrian Vovk (adrianvovk@xxxxxxxxx) wrote:

> What's protecting against this, if anything?
>
> In theory, this should all be detectable. The pcrphase measurements should
> fail if the TPM fails to reply that it has handled the command, and also
> pcrphase should probably _read back_ the PCRs and make sure they're at the
> expected value. Unfortunately, I don't think we actually care at the moment
> if these measurements fail - they can fail and we'll keep booting.

So a simple fix is this:

https://github.com/systemd/systemd/pull/36705

The full fix would be to immediately get a signed quote of the PCR
from the TPM and authenticating that with the key we pinned in
systemd-tpm2-setup.service. Certainly doable, but so far I didn't
spend time on implementing quotes.

While I think it's nice to lock this down, I don't think this is that
crucial though right now.

> 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?

To avoid MITM we have to authenticate the TPM. For which there are
concepts in the specs ("endorsement certificate"), but the question is
how realistic they are in real-life given virtualized environments
(what is a "true" TPM even there). I think a TOFU concept makes more
sense I think: pin the TPM on first boot, and on later operations
check we are still talking to the same TPM.

We already implement such pinning for the FDE key release. But we do
not do such pinning for the measurements. That would entail getting a
signed "quote" from the tpm covering the PCR state, then checking the
signature against the pinned SRK, and checking that the PCR
measurements we just made are actually in the logs.

Lennart

--
Lennart Poettering, Berlin