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

[James Bottomley]

On Tue, 2018-11-20 at 14:33 -0700, Jason Gunthorpe wrote:
> 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.

I don't disagree, but this is their site not mine:

https://trustedcomputinggroup.org/resource/implementing-hardware-roots-of-trust/

and the industry expects us at least to make an effort to support them
in using it.  I fully agree it's nowhere near foolproof.  However, I
think the plan proposed is a reasonable course of action against
interposers ... it's certainly better than doing nothing.

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

Yes, that's my exact point: a nation state can definitely overcome a
TPM in a system they possess.  Previously it wasn't thought possible
with $10 of hardware, a screwdriver and about 5 minutes of access,
which has tipped the tables somewhat.

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

Right, but that's why I want to detect the error and shut down the TPM.

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

Absolutely agreed on this point: the next step, in fact, is to
circulate the document to Microsoft and the UEFI people to see if they
want to use it as part of their defence against this.  Ideally if we
all agree on the null seed proposal, we can add passing the name
through the boot interfaces for standardisation.

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

Right, that's why I'll be trying to get that consensus.  Us agreeing
among ourselves is just the first step, the second, and much harder is
getting the other consumer (Microsoft) and the BIOS (UEFI/Tianocore
because they're a single entity) communities to follow.

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

Sure ... but at least we're moving back to only well funded entities
and nation states, not just the average hacker in the street ...

James