On 2025-03-10 23:32, Demi Marie Obenour wrote:
On Mon, Mar 10, 2025 at 09:10:59PM +0000, aplanas wrote:
[...]
> 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.
The referenced doc[3] has more specific information about this topic,
but there are three (four) kind of sessions (unbound, bound and salted,
and the bound+salted that is not used), with the salted one you do not
need a shared a secret between the caller and the TPM2.
In this model you can leverage one of the keys stored in the TPM2 (like
the EK). You request the public part and encrypt a user-generated salt.
You will use the asymmetric key to communicate this salt to the TPM2.
This salt, together with other information known by both parts, are used
to generate an encryption key. This key is used to encrypt/decrypt the
secret parameter and the encrypted result between both sides, and
HMAC(key, msg) is used to validate this parameter and answer.
The salt session is a bit slower, but because there is no initial shared
secret, it is ideal to communicate this shared secret that other
sessions can use, and the result will be faster (but I think that this
is not the case in systemd)
There is even more detailed info in the "A Practical Guide to TPM 2.0"
book (Authorizations and Sessions chapter)
