linux-kernel - Re: [PATCH 1/2] tpm: Compare HMAC values in constant time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250801201455.GA5141@sol>
Date: Fri, 1 Aug 2025 13:14:55 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: James Bottomley <James.Bottomley@...senpartnership.com>
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, Aug 01, 2025 at 03:20:52PM -0400, James Bottomley wrote:
> 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.

No, it's not "simply a semantic quibble".  You're just wrong.

As I said earlier, our_nonce (which is not a key) does appear to make
MAC timing attacks not possible.  All the other fields appear to be
attacker-controlled, contrary to what you're claiming above.

Anyway, point taken: I'll drop the Fixes and Cc stable from the commit,
and include my own analysis of why MAC timing attacks don't appear to be
possible with this protocol.  Everything else in this thread has just
been a pointless distraction.

- Eric