To prevent timing attacks, HMAC value comparison needs to be constant
time.  Replace the memcmp() with the correct function, crypto_memneq().

Fixes: 1085b8276bb4 ("tpm: Add the rest of the session HMAC API")
Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
---
 drivers/char/tpm/Kconfig         | 1 +
 drivers/char/tpm/tpm2-sessions.c | 6 +++---
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index dddd702b2454a..f9d8a4e966867 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -31,10 +31,11 @@ config TCG_TPM2_HMAC
 	bool "Use HMAC and encrypted transactions on the TPM bus"
 	default X86_64
 	select CRYPTO_ECDH
 	select CRYPTO_LIB_AESCFB
 	select CRYPTO_LIB_SHA256
+	select CRYPTO_LIB_UTILS
 	help
 	  Setting this causes us to deploy a scheme which uses request
 	  and response HMACs in addition to encryption for
 	  communicating with the TPM to prevent or detect bus snooping
 	  and interposer attacks (see tpm-security.rst).  Saying Y
diff --git a/drivers/char/tpm/tpm2-sessions.c b/drivers/char/tpm/tpm2-sessions.c
index bdb119453dfbe..5fbd62ee50903 100644
--- a/drivers/char/tpm/tpm2-sessions.c
+++ b/drivers/char/tpm/tpm2-sessions.c
@@ -69,10 +69,11 @@
 #include <linux/unaligned.h>
 #include <crypto/kpp.h>
 #include <crypto/ecdh.h>
 #include <crypto/hash.h>
 #include <crypto/hmac.h>
+#include <crypto/utils.h>
 
 /* maximum number of names the TPM must remember for authorization */
 #define AUTH_MAX_NAMES	3
 
 #define AES_KEY_BYTES	AES_KEYSIZE_128
@@ -827,16 +828,15 @@ int tpm_buf_check_hmac_response(struct tpm_chip *chip, struct tpm_buf *buf,
 	sha256_update(&sctx, auth->our_nonce, sizeof(auth->our_nonce));
 	sha256_update(&sctx, &auth->attrs, 1);
 	/* we're done with the rphash, so put our idea of the hmac there */
 	tpm2_hmac_final(&sctx, auth->session_key, sizeof(auth->session_key)
 			+ auth->passphrase_len, rphash);
-	if (memcmp(rphash, &buf->data[offset_s], SHA256_DIGEST_SIZE) == 0) {
-		rc = 0;
-	} else {
+	if (crypto_memneq(rphash, &buf->data[offset_s], SHA256_DIGEST_SIZE)) {
 		dev_err(&chip->dev, "TPM: HMAC check failed\n");
 		goto out;
 	}
+	rc = 0;
 
 	/* now do response decryption */
 	if (auth->attrs & TPM2_SA_ENCRYPT) {
 		/* need key and IV */
 		tpm2_KDFa(auth->session_key, SHA256_DIGEST_SIZE
-- 
2.50.1

On Thu, 2025-07-31 at 14:52 -0700, Eric Biggers wrote:
> To prevent timing attacks, HMAC value comparison needs to be constant
> time.  Replace the memcmp() with the correct function,
> crypto_memneq().

Um, OK, I'm all for more security but how could there possibly be a
timing attack in the hmac final comparison code?  All it's doing is
seeing if the HMAC the TPM returns matches the calculated one.  Beyond
this calculation, there's nothing secret about the HMAC key.

Regards,

James

On Thu, Jul 31, 2025 at 10:28:49PM -0400, James Bottomley wrote:
> On Thu, 2025-07-31 at 14:52 -0700, Eric Biggers wrote:
> > To prevent timing attacks, HMAC value comparison needs to be constant
> > time.  Replace the memcmp() with the correct function,
> > crypto_memneq().
> 
> Um, OK, I'm all for more security but how could there possibly be a
> timing attack in the hmac final comparison code?  All it's doing is
> seeing if the HMAC the TPM returns matches the calculated one.  Beyond
> this calculation, there's nothing secret about the HMAC key.

I'm not sure I understand your question.  Timing attacks on MAC
validation are a well-known issue that can allow a valid MAC to be
guessed without knowing the key.  Whether it's practical in this
particular case for some architecture+compiler+kconfig combination is
another question, but there's no reason not to use the constant-time
comparison function that solves this problem.

Is your claim that in this case the key is public, so the MAC really
just serves as a checksum (and thus the wrong primitive is being used)?

- Eric

On Thu, 2025-07-31 at 20:02 -0700, Eric Biggers wrote:
> On Thu, Jul 31, 2025 at 10:28:49PM -0400, James Bottomley wrote:
> > On Thu, 2025-07-31 at 14:52 -0700, Eric Biggers wrote:
> > > To prevent timing attacks, HMAC value comparison needs to be
> > > constant time.  Replace the memcmp() with the correct function,
> > > crypto_memneq().
> > 
> > Um, OK, I'm all for more security but how could there possibly be a
> > timing attack in the hmac final comparison code?  All it's doing is
> > seeing if the HMAC the TPM returns matches the calculated one. 
> > Beyond this calculation, there's nothing secret about the HMAC key.
> 
> I'm not sure I understand your question.  Timing attacks on MAC
> validation are a well-known issue that can allow a valid MAC to be
> guessed without knowing the key.  Whether it's practical in this
> particular case for some architecture+compiler+kconfig combination is
> another question, but there's no reason not to use the constant-time
> comparison function that solves this problem.
> 
> Is your claim that in this case the key is public, so the MAC really
> just serves as a checksum (and thus the wrong primitive is being
> used)?

The keys used for TPM HMAC calculations are all derived from a shared
secret and updating parameters making them one time ones which are
never reused, so there's no benefit to an attacker working out after
the fact what the key was.

Regards,

James

On Fri, Aug 01, 2025 at 07:36:02AM -0400, James Bottomley wrote:
> On Thu, 2025-07-31 at 20:02 -0700, Eric Biggers wrote:
> > On Thu, Jul 31, 2025 at 10:28:49PM -0400, James Bottomley wrote:
> > > On Thu, 2025-07-31 at 14:52 -0700, Eric Biggers wrote:
> > > > To prevent timing attacks, HMAC value comparison needs to be
> > > > constant time.  Replace the memcmp() with the correct function,
> > > > crypto_memneq().
> > > 
> > > Um, OK, I'm all for more security but how could there possibly be a
> > > timing attack in the hmac final comparison code?  All it's doing is
> > > seeing if the HMAC the TPM returns matches the calculated one. 
> > > Beyond this calculation, there's nothing secret about the HMAC key.
> > 
> > I'm not sure I understand your question.  Timing attacks on MAC
> > validation are a well-known issue that can allow a valid MAC to be
> > guessed without knowing the key.  Whether it's practical in this
> > particular case for some architecture+compiler+kconfig combination is
> > another question, but there's no reason not to use the constant-time
> > comparison function that solves this problem.
> > 
> > Is your claim that in this case the key is public, so the MAC really
> > just serves as a checksum (and thus the wrong primitive is being
> > used)?
> 
> The keys used for TPM HMAC calculations are all derived from a shared
> secret and updating parameters making them one time ones which are
> never reused, so there's no benefit to an attacker working out after
> the fact what the key was.

MAC timing attacks forge MACs; they don't leak the key.

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.

I guses I'm struggling to understand the point of your comments.  Even
if in a follow-up message you're finally able to present a correct
argument for why memcmp() is okay, it's clearly subtle enough that we
should just use crypto_memneq() anyway, just like everywhere else in the
kernel that validates MACs.  If you're worried about performance, you
shouldn't be: it's a negligible difference that is far outweighed by all
the optimizations I've been making to lib/crypto/.

- Eric

On Fri, 2025-08-01 at 10:11 -0700, Eric Biggers wrote:
> On Fri, Aug 01, 2025 at 07:36:02AM -0400, James Bottomley wrote:
> > On Thu, 2025-07-31 at 20:02 -0700, Eric Biggers wrote:
> > > On Thu, Jul 31, 2025 at 10:28:49PM -0400, James Bottomley wrote:
> > > > On Thu, 2025-07-31 at 14:52 -0700, Eric Biggers wrote:
> > > > > To prevent timing attacks, HMAC value comparison needs to be
> > > > > constant time.  Replace the memcmp() with the correct
> > > > > function, crypto_memneq().
> > > > 
> > > > Um, OK, I'm all for more security but how could there possibly
> > > > be a timing attack in the hmac final comparison code?  All it's
> > > > doing is seeing if the HMAC the TPM returns matches the
> > > > calculated one.  Beyond this calculation, there's nothing
> > > > secret about the HMAC key.
> > > 
> > > I'm not sure I understand your question.  Timing attacks on MAC
> > > validation are a well-known issue that can allow a valid MAC to
> > > be guessed without knowing the key.  Whether it's practical in
> > > this particular case for some architecture+compiler+kconfig
> > > combination is another question, but there's no reason not to use
> > > the constant-time comparison function that solves this problem.
> > > 
> > > Is your claim that in this case the key is public, so the MAC
> > > really just serves as a checksum (and thus the wrong primitive is
> > > being used)?
> > 
> > The keys used for TPM HMAC calculations are all derived from a
> > shared secret and updating parameters making them one time ones
> > which are never reused, so there's no benefit to an attacker
> > working out after the fact what the key was.
> 
> MAC timing attacks forge MACs; they don't leak the key.

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

> I guses I'm struggling to understand the point of your comments.

Your commit message, still quoted above, begins "To prevent timing
attacks ..." but I still don't think there are any viable timing
attacks against this code.  However, that statement gives the idea that
it's fixing a crypto vulnerablility and thus is going to excite the AI
based CVE producers.

>   Even if in a follow-up message you're finally able to present a
> correct argument for why memcmp() is okay, it's clearly subtle enough
> that we should just use crypto_memneq() anyway, just like everywhere
> else in the kernel that validates MACs.  If you're worried about
> performance, you shouldn't be: it's a negligible difference that is
> far outweighed by all the optimizations I've been making to
> lib/crypto/.

So if you change the justification to something like "crypto people
would like to update hmac compares to be constant time everywhere to
avoid having to check individual places for correctness" I think I'd be
happy.

Regards,

James

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:
> > On Fri, Aug 01, 2025 at 07:36:02AM -0400, James Bottomley wrote:
> > > On Thu, 2025-07-31 at 20:02 -0700, Eric Biggers wrote:
> > > > On Thu, Jul 31, 2025 at 10:28:49PM -0400, James Bottomley wrote:
> > > > > On Thu, 2025-07-31 at 14:52 -0700, Eric Biggers wrote:
> > > > > > To prevent timing attacks, HMAC value comparison needs to be
> > > > > > constant time.  Replace the memcmp() with the correct
> > > > > > function, crypto_memneq().
> > > > > 
> > > > > Um, OK, I'm all for more security but how could there possibly
> > > > > be a timing attack in the hmac final comparison code?  All it's
> > > > > doing is seeing if the HMAC the TPM returns matches the
> > > > > calculated one.  Beyond this calculation, there's nothing
> > > > > secret about the HMAC key.
> > > > 
> > > > I'm not sure I understand your question.  Timing attacks on MAC
> > > > validation are a well-known issue that can allow a valid MAC to
> > > > be guessed without knowing the key.  Whether it's practical in
> > > > this particular case for some architecture+compiler+kconfig
> > > > combination is another question, but there's no reason not to use
> > > > the constant-time comparison function that solves this problem.
> > > > 
> > > > Is your claim that in this case the key is public, so the MAC
> > > > really just serves as a checksum (and thus the wrong primitive is
> > > > being used)?
> > > 
> > > The keys used for TPM HMAC calculations are all derived from a
> > > shared secret and updating parameters making them one time ones
> > > which are never reused, so there's no benefit to an attacker
> > > working out after the fact what the key was.
> > 
> > MAC timing attacks forge MACs; they don't leak the key.
> 
> > 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.

> > I guses I'm struggling to understand the point of your comments.
> 
> Your commit message, still quoted above, begins "To prevent timing
> attacks ..." but I still don't think there are any viable timing
> attacks against this code.  However, that statement gives the idea that
> it's fixing a crypto vulnerablility and thus is going to excite the AI
> based CVE producers.
> 
> >   Even if in a follow-up message you're finally able to present a
> > correct argument for why memcmp() is okay, it's clearly subtle enough
> > that we should just use crypto_memneq() anyway, just like everywhere
> > else in the kernel that validates MACs.  If you're worried about
> > performance, you shouldn't be: it's a negligible difference that is
> > far outweighed by all the optimizations I've been making to
> > lib/crypto/.
> 
> So if you change the justification to something like "crypto people
> would like to update hmac compares to be constant time everywhere to
> avoid having to check individual places for correctness" I think I'd be
> happy.

Sure, provided that memcmp() is actually secure here.  So far, it hasn't
been particularly convincing when each argument you've given for it
being secure has been incorrect.

But I do see that each call to tpm_buf_check_hmac_response() is paired
with a call to tpm_buf_append_hmac_session() which generates a fresh
nonce.  That nonce is then sent to the other endpoint (the one that
claims to be a TPM) and then implicitly becomes part of the response
message (but is not explicitly transmitted back in it).  That may be the
real reason: messages are guaranteed to not be repeated, so a MAC timing
attack can't be done.  Do you agree that is the actual reason?

- Eric

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.

Regards,

James

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

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

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