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
