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

[James Bottomley]

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.

> And if someone manipulates the unencrypted PCR extend commands then
> we are back to 'the PCB is broken' and all PCR based security has
> been lost.
> 
> > 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.

James