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 02:34:52PM -0800, James Bottomley wrote:

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

Notice none of their examples include 'prevent tampering with the
hardware' all are focused on pure software attacks, which the TPM is
excellent at preventing. The TPM was never supposed to prevent
physical attacks against the HW for the PCR feature.

The only HW guarentee it ever provided is to prevent theft of the
private secrets, even with physical access.

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

Well, I think this is a lot of industry effort and still leaves open
other fairly simple physical attacks, like wire-to-the-reset.

I can always make an interposer that did wire-to-the-reset, I don't
need to do complicated dynamic things with PCR extend commands.

And the null key doesn't really protect against wire-to-the-reset, as
the null key doesn't participate in the PCR extend. So
unseal/seal/attest commands don't know if the TPM was booted
authentically or via a wire-to-the-reset and a hostile kernel.

Yes, it lets a trusted kernel detect a problem, but a threat model
that includes an interposer and excludes a hostile kernel doesn't
sound so interesting to me???

Like I said at the start, the way the spec is written, PCR requires
trusted HW. Without a TPM spec change we can't fix this basic
assumption.

A better mitigation to the interposer threat is for PCB manufactures
to use BGA packages, blind vias and internal traces to physically deny
easy access to the TPM bus and reset signal.

The last TPM project I worked on took physical security into account
when designing the PCB and TPM chip placement, others should do the
same :)

Jason