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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Tue, Nov 20, 2018 at 09:17:59AM -0800, James Bottomley wrote:

> > > 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.
> 
> OK, the TPM is supposed to provide attestation of the correct
> environment on a device under someone else's control (the classic
> example is laptop provided by a company to an employee).  The device is
> under the physical control of the entity you don't entirely trust so
> the TPM is supposed to attest that they're running an approved OS ...
> we have whole TCG specs for that situation.

Well.. Attestation started out as a way to prove things about hardware
you physically control - ie data center servers. That they haven't
been manipulated.

I'm not surprised people want to use this on the client, but in this
case you really have to trust the employee to not disassemble the
laptop...

The idea that it could extend to HW you don't control is, frankly, a
bit of wishful thinking. The system is strong enough to defend against
casual abuse, but a determined and funded adversary has, many, many,
options to create a situation where the TPM attests the system is
running software that it actually isn't.

The scary thing about the interposer is how inexpensive and simple it
is, many other attacks require considerable determination and funding.

> > 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.
> 
> The interposer sits on the serial bus ... it has no contact with the
> CPU.  That's the point about it, it's a simple to attach easy to
> construct device because the TPM bus (LPC, i2c, spi etc) is easy to
> interface to.  getting a device which can man in the middle the main
> CPU address bus, say, is at least an order of magnitude more difficult.

It doesn't need contact with the CPU. The basic flow would be to use
the interposer on SPI or LPC to block the Nth PCR update, having
determined that Nth comes from the BIOS and covers the
bootloader.. The BIOS ignores the error, or can't tell the PCR update
was corrupted. From there it is easy to see how to get into a hostile
kernel and extend the PCRs to match a trusted kernel.

But even this convoluted attack is kind of silly. If I can touch the
TPM physically then just boot into my hostile kernel and *trigger TPM
reset*. Then I can simply issue reset and then extends from the
hostile kernel to mimic a trusted system. Easy! One wire and a
microscope will do the job!

So it really is essential that all steps, including the BIOS use
secure PCR updates, or you may as well not bother in Linux, at least
for security reasons.

And I think you were on the right track, the TPM should have a
per-boot authorization that flows through all layers of the TPM stack
and guarantees the TPM hasn't been rebooted and with crypto prevents
lost PCR updates. 

But that does require standardization, as we do need the BIOS to
participate.

Though keep in mind, tt doesn't prevent physical access from
manipulating the PCRs, it just makes it more expensive than one wire
and a microscope. Maybe it now involves de-soldering, etc.

Jason