On Mon, 2018-11-19 at 16:08 -0700, Jason Gunthorpe wrote: > On Mon, Nov 19, 2018 at 02:36:28PM -0800, James Bottomley wrote: > > 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. > > But the threat model for PCR excludes the possibility of an > interposer. If you have an interposer the PCB is broken and all PCR > security is already lost. Yours might, mine doesn't and I think I can mitigate the we can give you approved PCRs attack ... I can't prevent the we muck with your PCRs attack. > > some scope for detecting the presence of an interposer if it does > > try to tamper with your measurements. > > But I can still tamper with them.. I can have the interposer > delete/fail the kernel PCR commands and issue un-hashed ones. You can't because you don't have the HMAC key to fake the response, so as long as I check the HMAC return I know you've tampered. > The kernel would have to do something extreme like fault the TPM and > totally disable the linux device if any PCR extend fails. That should > probably be included in the plan? If we detect an interposer (if one of the HMACs or encrypt/decrypt fails) it depends on policy what you do. We certainly log a message saying TPM integrity is compromised. I think we should also disable the TPM, but I haven't done that yet because I thought it would bear more discussion. > > 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. > > Sure, if you have the machinery and it can be used at PCR time, then > why not use it.. But I think any description about why this is being > done should be clear about what the threat model is for PCR. Right, the threat model for me is complete control of the PCRs. I can mitigate that by HMACing the request and response and checking the response HMAC. > I'm mostly concerned about how the document was written which makes > it seems like security of extend beyond what is integral to the > PCB/chipset is meaningful, considering the threat model PCR is based > on. > > We don't want people to become confused and think they are getting > more security than there really is. Agreed. > > > 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. > > Well, that is terrifying. > > But a SW based attack that can toggle TPM reset or alter TPM commands > in flight getting very much into the 'chips are broken' territory > where the chain of trust required for PCR is broken. This is breaking > fundamental assumptions of the threat model here :( > > It is hard to know if more crypto could really prevent problems > without knowing the details of how this is being done?? I think if I can mitigate some of the PCR problems and prevent snooping for the hardware interposer, it will also go a long way to defeating the more software one ... of course, not having seen it, this is just a guess, but it's based on the idea that the software one probably has the same or more limited access to the bus. James