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

[Jeremy Boone <jeremy.boone@nccgroup.com>]

[-- Attachment #1: Type: text/plain, Size: 5979 bytes --]



> On Nov 20, 2018, at 6:39 PM, Jason Gunthorpe <jgg@ziepe.ca> wrote:
> 
>> On Tue, Nov 20, 2018 at 02:34:52PM -0800, James Bottomley wrote:
>> 
>> https://protect-eu.mimecast.com/s/D_7bCj2BliYEYn0TWDV1q
> 
> 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???

The idea is that if the bootloader(s) also protect the bus transactions with an HMAC, then we could detect tampering and before ever booting into a hostile kernel.

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

Yes. I said as much in the TPM Genie paper. A firmware TPM is even better, as we never need to worry about protecting the bus because it is never exposed in the first place. 

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

I think it’s worth recognizing that TPMs are used in a variety of deployments, each with their own unique threat model and attack surface. 

For example, some users may care about evil maid scenarios. Heck, TPM-TOTP (and dare I mention the Qubes Anti-Evil Maid technology) utilizes the TPM to attest the boot state to the device owner. 

Other users may care about the “lost in the back of a taxi” scenario wherein the attacker may have extended physical access to the mobile device (a phone or laptop) before returning it to the owner. 

In other scenarios, the device user may be a different entity than the device owner, and as such, different security considerations must be applied. Think of a set top box that you’ve rented from your cable service provider which uses a TPM to remotely attest the firmware before being trusted to handle content decryption keys. Or a car share program that uses the TPM as a means to store temporary keyless-entry tokens — After all, the TCG Automotive Thin Profile is taking off, as are the SAE J3101 requirements which suggest the use of TPM in automotive applications.  An interposer, or even a simple sniffer attached to test points on the bus, would be able to observe any secrets transmitted between the TPM and host. 

I believe that the Linux kernel has an obligation to build in active defences that protect TPM users against serial bus attacks, and makes no blind assumptions about the ways in which a TPM may be used or deployed in a variety of creative or unexpected ways. 

This is especially true in light of the fact that the TCG (and TPM chip manufacturers as well) have not plainly documented that, despite having expended considerable effort defending against invasive silicon attacks (see Chris Tarnovsky’s work), a trivial interposer can still defeat TPM security. I believe that many do not understand this fact, and conflate the idea that measured boot can detect “hardware tampering” vs. mere “firmware tampering”. Regardless, it seems odd to me that we wish to defend against one-off attacks involving an electron microscope, but do not wish to defend against a simple microcontroller acting as a man-in-the-middle on the bus. 

It’s true that with sufficient time and motivation, a dedicated and well-funded adversary can defeat almost any protection mechanism. But our job as defenders is to raise the bar so that cheap and inexpensive attacks are no longer feasible. By raising the cost of exploitation beyond the adversary’s appetite, we eliminate entire classes of attack.

Choosing to do nothing simply because other attack avenues exist is a little too defeatist of an attitude for me. Especially given that the TPM specification does support payload encryption and integrity protection through the use of Authorization Sessions. So we do have the necessary tools to begin to solve this problem. Unfortunately, it is also true that this issue extends beyond the kernel. We also need to land similar patches for every stage of the boot process that performs a PCR Extend operation. Otherwise the chain of trust can be broken before the kernel is even started. 

All that said, I’m pretty invested in TPM Genie, so I am obviously biased towards seeing a fix. 

Jeremy

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2703 bytes --]