Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks

From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Ken Goldman <kgold@linux.ibm.com>,
	linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org
Subject: Re: Documenting the proposal for TPM 2.0 security in the face of bus interposer attacks
Date: Mon, 10 Dec 2018 09:30:47 -0800	[thread overview]
Message-ID: <1544463047.2753.24.camel@HansenPartnership.com> (raw)
In-Reply-To: <16c8baf7-e2a9-6e12-b736-a0e2384282ed@linux.ibm.com>

On Mon, 2018-12-10 at 11:33 -0500, Ken Goldman wrote:
> On 11/19/2018 12:34 PM, James Bottomley wrote:
> 
> > 2. At some point in time the attacker could reset the TPM, clearing
> >     the PCRs and then send down their own measurements which would
> >     effectively overwrite the boot time measurements the TPM has
> >     already done.
> > [snip]
> > However, the second can only really be detected by relying
> > on some sort of mechanism for protection which would change over
> > TPM reset.
> 
> FYI: TPM 2.0 has a resetCount that can be used to detect, but not 
> protect against, this attack.

Yes, but that would be an additional check we'd have to do.  Using the
NULL seed for salt means the HMAC and Encryption on commands instantly
breaks if the TPM is reset.

> > Every TPM comes shipped with a couple of X.509 certificates for the
> > primary endorsement key.  This document assumes that the Elliptic
> > Curve version of the certificate exists at 01C00002, but will work
> > equally well with the RSA certificate (at 01C00001).
> 
> A nit.  The RSA cert is at 01c00002.  The ECC cert is at 01c0000a.

Is this actually published somewhere? ... I was guessing from the TPM
2.0 provisioning guide.

James