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

[James Bottomley]

On Mon, 2018-11-19 at 14:44 -0700, Jason Gunthorpe wrote:
> On Mon, Nov 19, 2018 at 01:34:41PM -0800, James Bottomley wrote:
> > On Mon, 2018-11-19 at 14:19 -0700, Jason Gunthorpe wrote:
> > [...]
> > > Sure, for stuff working with shared secrets, etc, this make
> > > sense. But PCR extends are not secret, so there is no reason to
> > > encrypt them on the bus.
> > 
> > OK, there's a miscommunication here.  I believe the current
> > document states twice that there's no encryption for PCR
> > operations.  We merely use a salted HMAC session to ensure that
> > they're reliably received by the TPM and not altered in-flight.
> 
> Sure, but again, what is this preventing?

It prevents the interposer having free reign to set the PCR values by
substituting every measurement you send to the TPM.  It also allows you
some scope for detecting the presence of an interposer if it does try
to tamper with your measurements.  I agree there's no guarantee of non
tamper, like there is for confidentiality of sealed data and random
numbers, but it seems to be an improvement on what's currently there
given that we have to install the session machinery for
encryption/decryption anyway.

> If you accept that PCB trust is essential for PCR security, then I
> think trusting the PCB to deliver the PCR extends is perfectly fine.

The *current* interposer is a hardware device on the bus.  The next gen
is reported to be more software based.

> > > > In theory, but we don't seem to have one.  The theory is that
> > > > TPMs come provisioned according to the TCG guidance which
> > > > specifies RSA and EC storage keys be at 81000001 and 81000002
> > > > respectively
> > > > ... it
> > > > just seems that the current TPM generation don't respect this,
> > > > so
> > > > they come with no permanent keys at all.
> > > 
> > > Seems surprising.. And the use models you have don't alwaus load
> > > a key that could be used for this?
> > 
> > I think it's because Microsoft realised after the first generation
> > of TPM 2.0s that not having any key at all was a problem, so lots
> > of them shipped before the spec got updated and manufacturers are
> > somewhat slow to retool production lines.  My TPM 2.0 doesn't even
> > have an EC certificate (although Nuvoton now claims this was a
> > manufacturing mistake) never mind a derived primary key.
> 
> Ah, the usual mess in TPM land then :)

Yes, sigh.

James