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 04:54:32PM -0800, James Bottomley wrote:
> 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.

It is not 'mine' or 'your' threat model. These trade offs are baked
into the TPM protocol design itself.

I guess I haven't really heard you explain what your threat model
is.

I would think if an interposer can muck with the PCRs then the main
attack would be to cause the CPU to run code that does not match the
PCRs while tricking the TPM into thinking the PCR matches.

This would let an attack unseal, say, a disk encryption secret while
running a hostile version of Linux. A big failure of the fundamental
PCR guarentee.

So any point along the PCR trust chain that does not do secure PCR
updates is a failure point. Since the BIOS doesn't do it, one would
probably start by replacing the bootloader and kernel in conjunction
with the interposer?

The incremental gain from having the kernel do this seems negligible
to me.

I think to properly address this threat work needs to be done in the
TPM spec to establish a secure TPM communication channel at power on..

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

.. and you stop using the TPM after this. Otherwise the interposer can
fail the command, issue an extend with the right data, and cause the
PCRs to match trusted data while running actually untrusted code.

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

Logging doesn't seem useful - if a HW interposer is present then
someone is already in control of the HW and will happily ignore
warnings ...

Jason