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

[Jason Gunthorpe <jgg@ziepe.ca>]

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.

> 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.

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?

> 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. 

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.

> > 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??

Jason