[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <605314b70efde2e31f9e6a34a6bb0ea0060e0c67.camel@HansenPartnership.com>
Date: Fri, 01 Aug 2025 15:20:52 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Peter Huewe <peterhuewe@....de>, Jarkko Sakkinen <jarkko@...nel.org>,
linux-integrity@...r.kernel.org, Jason Gunthorpe <jgg@...pe.ca>,
linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
stable@...r.kernel.org
Subject: Re: [PATCH 1/2] tpm: Compare HMAC values in constant time
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
Powered by blists - more mailing lists