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

Tue Nov 20 11:10:49 UTC 2018

On Mon, Nov 19, 2018 at 09:34:04AM -0800, James Bottomley wrote:
> 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/

This is basically rewrite of TPM genie paper with extras. Maybe just
shorten it to include the proposed architecture and point to the TPM
Genie paper (which is not in the references at all ATM).

The way I see it the data validation is way more important than
protecting against physical interposer to be frank.

The attack scenario would require to open the damn device. For laptop
that would leave physical marks (i.e. evil maid). In a data center with
armed guards I would wish you good luck accomplishing it. It is not
anything like sticking a USB stick and run.

We can take a fix into Linux with a clean implementation but it needs
to be an opt-in feature because not all users will want to use it.

/Jarkko