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] [thread-next>] [day] [month] [year] [list]
Message-ID: <ca85bbe8a3235102707da3b24dba07a8649c3771.camel@HansenPartnership.com>
Date: Fri, 01 Aug 2025 07:36:02 -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 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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ