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. - Eric
