On Fri, 2025-08-01 at 12:03 -0700, Eric Biggers wrote:
On Fri, Aug 01, 2025 at 02:53:09PM -0400, James Bottomley wrote:
On Fri, 2025-08-01 at 11:40 -0700, Eric Biggers wrote:
On Fri, Aug 01, 2025 at 02:03:47PM -0400, James Bottomley wrote:
On Fri, 2025-08-01 at 10:11 -0700, Eric Biggers wrote:
[...]
It's true that such attacks don't work with one-time keys. But here it's not necessarily a one-time key. E.g., tpm2_get_random() sets a key, then authenticates multiple messages using that key.
The nonces come one from us and one from the TPM. I think ours doesn't change if the session is continued although it could, whereas the TPM one does, so the HMAC key is different for every communication of a continued session.
Again, tpm2_get_random() sets a HMAC key once and then uses it multiple times.
No it doesn't. If you actually read the code, you'd find it does what I say above. Specifically tpm_buf_fill_hmac_session() which is called inside that loop recalculates the hmac key from the nonces. This recalculated key is what is used in tpm_buf_check_hmac_response(), and which is where the new tpm nonce is collected for the next iteration.
tpm_buf_fill_hmac_session() computes a HMAC value, but it doesn't modify the HMAC key. tpm2_parse_start_auth_session() is the only place where the HMAC key is changed. You may be confusing HMAC values with keys.
Is this simply a semantic quibble about what gets called a key? For each TPM command we compute a cphash across all the command parameters (and for each return a rphash). This hash then forms a hmac(session_key, cphash | our_nonce | tpm_nonce | attrs). The point being that although session_key is fixed across the session, the our_nonce and tpm_nonce can change with every iteration. Since the cphash is over the ciphertext, it's the only bit you get to vary with a chosen ciphertext attack, so the other parameters effectively key the hmac.
Regards,
James