[systemd-devel] DOSing the TPM to leak the rootfs encryption key

[aplanas]

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)