On Wed, Nov 21, 2018 at 02:24:18AM +0000, Jeremy Boone wrote:
> 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.
Not quite, it is not 'any' secrets. We can and absolutely should
competently encrypt various things, like shared secrets for unlocking
keys private data to be seal/unsealed, etc. There are robust working
mechanisms for this already in the spec.
I think this is very important and I know I've always coded my TPM
implementations to make use of these features.
But PCR extend is not private data, the data is well known.
> 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”.
This is basically my concern. HMACing the PCRs does not magically
allow measured boot to detect "hardware tampering". Even if all layers
from the BIOS down do this correctly. Pretending otherwise continues
to push the incorrect message that PCRs do anything beyond detecting
"firmware tampering", as you say.
> 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.
I agree with this, but if you want to defent against hardware
tampering then one should defend robustly against all hardware
tampering and call that a TPM capability. A half implemented hardware
tampering defence only gives a false sense of security.
I think it is possible to do, but it requires some updates to the TPM
specification.
A general proposal would go something like...
1) The TPM gains a new NV flag 'Secure Reset Required' and a new command
'Secure Reset'
2) Issuing the'Secure Reset' command requires the TPM and CPU to both
prove to each other they are authentic, using some crypto protocol
(lots of options here)
2a) The TPM will store it's private secret for #2 either as a loaded blob
against a NV key or in NV itself. There is some protocol during
owning that allows the BIOS to initialize this stuff and set
Secure Reset Required. Maybe we assume the HW is untampered during
owning.
2b) The CPU will store its private secret for #2 encrypted using modern
CPU encryption technology like Intel's SGX, or similar. The
encrypted key will be stored in BIOS flash.
3) Upon boot the CPU will securely decrypt it's secret and issue
'Secure Reset'. The TPM will not function until this command is
issued. The only other option is a complete wipe.
4) During the 'Secure Reset' crypto the two sides will exchange
trusted or secret information used to authenticate and encrypt
all future communications
5) The BIOS will pass the #4 data down to the bootloader and to the
kernel for use when executign TPM commands, or maybe the BIOS will
transparently link it into the ACPI CRB executor or something.
6) TPM will reject any unathenticated&encrypted packet after Secure Reset
Now we have properly defended against a wide range of HW
tampering. You can't snoop/hijack the TPM bus. You can't reset the
TPM. You can't hack the BIOS FLASH and take over the BIOS before TPM
reset (assuming SGX is implemented properly). You can't replace the
trusted CPU with a hostile CPU. You can't desolder the TPM. This is an
excellent improvement in HW defense. If the SGX code also sets up DRAM
encryption then we are getting to be really properly secured against
HW tampering.
This is sort of what I mean when I say a spec update is needed. The
spec needs to be designed to properly detect and combat HW tampering.
We can't add this new feature robustly with only the functional
elements already in the spec.
[Of course this is kind of a silly thing to do, because if you have
this CPU technology then you may was well just implement the TPM in
the CPU.. But this is more of a thought experiment as to what would be
needed to secure a discrete TPM against HW tampering]
> 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.
My concern is we haven't done this simply because the reset-line
attack is less cost and complexity than the interposer on the data bus
attack, so we must prevent it first and foremost. Then prevent data
bus mangling, then prevent loading modified BIOS's, then prevent
hacked CPUs, and so on until things become properly expensive.
> 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.
We absolutely should be using encrypted and authenticated sessions
when transporting any secret data.
> 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.
Right, but this chain of trust starts at the reset line, not at the
BIOS. There is language in the spec requiring the platform to control
the reset line along with the CPU reset - this is critically necessary
to make PCRs work for 'measured boot'.
In my mind an interposer also means hostile control over the reset
line, so reset protection must be part of any complete defence against
an interposer.
The idea James had with the null key to detect reset doesn't mitigate
the case where hostile code is running on the CPU along with an
interposer. We can't make the assumption that only trusted code is
running in the CPU - if we could assume that we wouldn't need PCRs and
measured boot in the first place. ;)
Jason
