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

[Jason Gunthorpe]

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?

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.

> > > 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 :)

Jason