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

[Jason Gunthorpe]

On Mon, Nov 19, 2018 at 12:20:39PM -0800, James Bottomley wrote:
> On Mon, 2018-11-19 at 13:05 -0700, Jason Gunthorpe wrote:
> > On Mon, Nov 19, 2018 at 09:34:04AM -0800, James Bottomley wrote:
> > 
> > > The current state of the art for snooping the TPM Genie hardware
> > > interposer https://www.nccgroup.trust/us/our-research/tpm-genie/
> > > which
> > > is a simple external device that can be installed in a couple of
> > > seconds on any system or laptop.  However, the next phase of
> > > research
> > > seems to be hacking existing devices on the bus to act as
> > > interposers,
> > > so the fact that the attacker requires physical access for a few
> > > seconds might evaporate.  However, the goal of this document is to
> > > protect TPM secrets and integrity as far as we are able in this
> > > environment and to try to insure that if we can't prevent the
> > > attack
> > > then at least we can detect it.
> > > 
> > > Unfortunately, most of the TPM functionality, including the
> > > hardware
> > > reset capability can be controlled by an attacker who has access to
> > > the bus, so we'll discuss some of the disruption possibilities
> > > below.
> > > 
> > > Measurement (PCR) Integrity
> > > 
> > > Since the attacker can send their own commands to the TPM, they can
> > > send arbitrary PCR extends and thus disrupt the measurement system,
> > > which would be an annoying denial of service attack.  However,
> > > there
> > > are two, more serious, classes of attack aimed at entities sealed
> > > to
> > > trust measurements.
> > > 
> > > 1. The attacker could intercept all PCR extends coming from the
> > > system
> > >    and completely substitute their own values, producing a replay
> > > of
> > >    an untampered state that would cause PCR measurements to attest
> > > to
> > >    a trusted state and release secrets
> > > 
> > > 2. At some point in time the attacker could reset the TPM, clearing
> > >    the PCRs and then send down their own measurements which would
> > >    effectively overwrite the boot time measurements the TPM has
> > >    already done.
> > 
> > I can just de-solder the TPM, attach it to a rig and do whatever I
> > want to it, including fake PCR loads and trigger seal/uneal of any
> > data I like.
> 
> You wouldn't be able to resolder the TPM without causing a reset and
> losing the PCR values.

The attacker would issue extend commands and reload the PCR values.

In the PCR thread model the data used in TPM extend commands is not
considered secret.

ie for extends issued by linux, these are all easy to compute, we have
the source code and there is no secret information mixed in. Get a
copy of /boot and you know the values.

For the BIOS, this might need some inside info, or reverse
engineering, but it is still not secret. Ultimately it is various
hashes of static information stored in flash. At worst inserting a
false TPM would capture the information once for a specific hardware..

> The TPM is not designed to be secure against physical attacks that go
> after its internal seed values, that's true.  It is supposed to be
> secure against attacks that go after the information transmission into
> and out of the TPM, which is what the interposer is doing

The TPM is supposed to be secure in the sense it will not disclose its
internal secret information on its pins. De-lidding and other physical
things may disclose the information.

However, the PCR security model is a bit different, and hinges on a
cascading chain of trust. The very top of that chain is the PCB the
TPM is installed in, and from there it goes to the other chips
installed on the PCB, then the code in the BIOS, etc.

Break the PCB and you break the top of the chain of trust. All
security of the PCR is totally lost. Adding more encryption down the
line can't fixup the broken top of chain of trust.

This is why I don't think it makes sense to consider a threat model
for PCRs that contemplates any manipulation of the PCB..

> > The treat model for PCR users always contained the implicit
> > assumption that the security of the physical TPM HW, and the secure
> > linkage to the CPU (ie secure control over reset, and other things)
> > is maintained.
> > 
> > So, I'm not sure adding more crypto here really fits with the threat
> > model the TPM lives in?
> 
> It is, because the attack is a man in the middle, even if it's at the
> bus level, which TPM crypto and HMAC is supposed to thwart.

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.

And if someone manipulates the unencrypted PCR extend commands then we
are back to 'the PCB is broken' and all PCR based security has been
lost.

> In theory, but we don't seem to have one.  The theory is that TPMs come
> provisioned according to the TCG guidance which specifies RSA and
> EC storage keys be at 81000001 and 81000002 respectively ... it just
> seems that the current TPM generation don't respect this, so they come
> with no permanent keys at all.

Seems surprising.. And the use models you have don't alwaus load a key
that could be used for this?

Jason