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
