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

[James Bottomley]

Hi All,

I took the action at the Edinburgh meeting to document this, so the
attached is what I'm proposing (I'll also add this to my patch set
doing the implementation to live in Documentation/security/tpm/tpm-
security.rst).  Please could you give it a read; one thing that came
out of the Edinburgh meeting was that people with too much exposure to
TPM crypto acquire twists in their brains which mean stuff which seems
obvious to them isn't to anyone else, so I need external reviewers to
assure me that the document is understandable by non-TPM security
people.

Once this passes the understandability bar, I'll pass it on to
Microsoft and TianoCore/UEFI as our preferred mechanism for thwarting
interposer attacks.

Thanks,

James

---

TPM Security
============

The object of this document is to describe how we make the kernel's
use of the TPM reasonably robust in the face of external snooping and
packet alteration attacks.  The current security document is for TPM
2.0.

Introduction
------------

The TPM is usually a discrete chip attached to a PC via some type of
low bandwidth bus.  There are exceptions to this such as the Intel
PTT, which is a software TPM running inside a software environment
close to the CPU, which are subject to different attacks, but right at
the moment, most hardened security environments require a discrete
hardware TPM, which is the use case discussed here.

Snooping and Alteration Attacks against the bus
-----------------------------------------------

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.

The first can be thwarted by always doing HMAC protection of the PCR
extend and read command meaning measurement values cannot be
substituted without producing a detectable HMAC failure in the
response.  However, the second can only really be detected by relying
on some sort of mechanism for protection which would change over TPM
reset.

Secrets Guarding
----------------

Certain information passing in and out of the TPM, such as key sealing
and private key import and random number generation, is vulnerable to
interception which HMAC protection alone cannot protect, so for these
types of command we must also employ request and response encryption
to prevent the loss of secret information.

Establishing Initial Trust with the TPM
---------------------------------------

In order to provide security from the beginning, an initial shared or
asymmetric secret must be established which must also be unknown to
the attacker.  The most obvious avenues for this are the endorsement
and storage seeds, which can be used to derive asymmetric keys.
However, using these keys is difficult because the only way to pass
them into the kernel would be on the command line, which requires
extensive support in the boot system, and there's no guarantee that
either hierarchy would not have some type of authorization.

The mechanism chosen for the Linux Kernel is to derive the primary
elliptic curve key from the null seed using the standard storage seed
parameters.  The null seed has two advantages: firstly the hierarchy
physically cannot have an authorization, so we are always able to use
it and secondly, the null seed changes across TPM resets, meaning if
we establish trust on the null seed at start of day, all sessions
salted with the derived key will fail if the TPM is reset and the seed
changes.

Obviously using the null seed without any other prior shared secrets,
we have to create and read the initial public key which could, of
course, be intercepted and substituted by the bus interposer.
However, the TPM has a key certification mechanism (using the EK
endorsement certificate, creating an attestation identity key and
certifying the null seed primary with that key) which is too complex
to run within the kernel, so we keep a copy of the null primary key
name, which is what is certified so user-space can run the full
certification when it boots.  The definitive guarantee here is that if
the null primary key certifies correctly, you know all your TPM
transactions since start of day were secure and if it doesn't, you
know there's an interposer on your system (and that any secret used
during boot may have been leaked).

Stacking Trust
--------------

In the current null primary scenario, the TPM must be completely
cleared before handing it on to the next consumer.  However the kernel
hands to user-space the name of the derived null seed key which can
then be verified by certification in user-space.  Therefore, this chain
of name handoff can be used between the various boot components as
well (via an unspecified mechanism).  For instance, grub could use the
null seed scheme for security and hand the name off to the kernel in
the boot area.  The kernel could make its own derivation of the key
and the name and know definitively that if they differ from the handed
off version that tampering has occurred.  Thus it becomes possible to
chain arbitrary boot components together (UEFI to grub to kernel) via
the name handoff provided each successive component knows how to
collect the name and verifies it against its derived key.

Session Properties
------------------

All TPM commands the kernel uses allow sessions.  HMAC sessions may be
used to check the integrity of requests and responses and decrypt and
encrypt flags may be used to shield parameters and responses.  The
HMAC and encryption keys are usually derived from the shared
authorization secret, but for a lot of kernel operations that is well
known (and usually empty).  Thus, every HMAC session used by the
kernel must be created using the null primary key as the salt key
which thus provides a cryptographic input into the session key
derivation.  Thus, the kernel creates the null primary key once (as a
volatile TPM handle) and keeps it around in the kernel TPM space for
every in-kernel use of the TPM.  Currently, because of a lack of
de-gapping in the in-kernel resource manager, the session must be
created and destroyed for each operation, but, in future, a single
session may also be reused for the in-kernel HMAC, encryption and
decryption sessions.

Protection Types
----------------

For every in-kernel operation we use null primary salted HMAC to
protect the integrity.  Additionally, we use parameter encryption to
protect key sealing and parameter decryption to protect key unsealing
and random number generation.

Null Primary Key Certification in Userspace
===========================================

Every TPM comes shipped with a couple of X.509 certificates for the
primary endorsement key.  This document assumes that the Elliptic
Curve version of the certificate exists at 01C00002, but will work
equally well with the RSA certificate (at 01C00001).

The first step in the certification is primary creation using the
template from the `TCG EK Credential Profile`_ which allows comparison
of the generated primary key against the one in the certificate (the
public key must match).  Note that generation of the EK primary
requires the EK hierarchy password, but a pre-generated version of the
EC primary should exist at 81010002 and a TPM2_ReadPublic() may be
performed on this without needing the key authority.  Next, the
certificate itself must be verified to chain back to the manufacturer
root (which should be published on the manufacturer website).  Once
this is done, the generated EK primary key may now be used to run an
attestation on the null seed.  The specific problem here is that the
EK primary is not a signing key so cannot on its own be used to sign
the key certification, hence the complex process below.

Note: this process is a simplified abbreviation of the usual privacy
CA based attestation process.  The assumption here is that the
attestation is done by the TPM owner who thus has access to only the
owner hierarchy.  The owner creates an external public/private key
pair (assume elliptic curve in this case) and wraps the private key
for import using an inner wrapping process and parented to the EC
derived storage primary.  The TPM2_Import() is done using a parameter
decryption HMAC session salted to the EK primary (which also does not
require the EK key authority) meaning that the inner wrapping key is
the encrypted parameter and thus the TPM will not be able to perform
the import unless is possesses the certified EK so if the command
succeeds and the HMAC verifies on return we know we have a loadable
copy of the private key only for the certified TPM.  This key is now
loaded into the TPM and the Storage primary flushed (to free up space
for the null key generation).

The null EC primary is now generated using the Storage profile
outlined in the `TCG TPM v2.0 Provisioning Guidance`_; the name of
this key (the hash of the public area) is computed and compared to the
null seed name presented by the kernel in
/sys/class/tpm/tpm0/null_name.  If the names do not match, the TPM is
compromised.  If the names match, the user performs a TPM2_Certify()
using the null primary as the object handle and the loaded private key
as the sign handle and providing randomized qualifying data.  The
signature of the returned certifyInfo is verified against the public
part of the loaded private key and the qualifying data checked to
prevent replay.  If all of these tests pass, the user is now assured
that TPM integrity and privacy was preserved across the entire boot
sequence of this kernel.

.. _TCG EK Credential Profile: https://trustedcomputinggroup.org/resource/tcg-ek-credential-profile-for-tpm-family-2-0/
.. _TCG TPM v2.0 Provisioning Guidance: https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/