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