217 lines · plain
1.. SPDX-License-Identifier: GPL-2.0-only2 3TPM Security4============5 6The object of this document is to describe how we make the kernel's7use of the TPM reasonably robust in the face of external snooping and8packet alteration attacks (called passive and active interposer attack9in the literature). The current security document is for TPM 2.0.10 11Introduction12------------13 14The TPM is usually a discrete chip attached to a PC via some type of15low bandwidth bus. There are exceptions to this such as the Intel16PTT, which is a software TPM running inside a software environment17close to the CPU, which are subject to different attacks, but right at18the moment, most hardened security environments require a discrete19hardware TPM, which is the use case discussed here.20 21Snooping and Alteration Attacks against the bus22-----------------------------------------------23 24The current state of the art for snooping the `TPM Genie`_ hardware25interposer which is a simple external device that can be installed in26a couple of seconds on any system or laptop. Recently attacks were27successfully demonstrated against the `Windows Bitlocker TPM`_ system.28Most recently the same `attack against TPM based Linux disk29encryption`_ schemes. The next phase of research seems to be hacking30existing devices on the bus to act as interposers, so the fact that31the attacker requires physical access for a few seconds might32evaporate. However, the goal of this document is to protect TPM33secrets and integrity as far as we are able in this environment and to34try to insure that if we can't prevent the attack then at least we can35detect it.36 37Unfortunately, most of the TPM functionality, including the hardware38reset capability can be controlled by an attacker who has access to39the bus, so we'll discuss some of the disruption possibilities below.40 41Measurement (PCR) Integrity42---------------------------43 44Since the attacker can send their own commands to the TPM, they can45send arbitrary PCR extends and thus disrupt the measurement system,46which would be an annoying denial of service attack. However, there47are two, more serious, classes of attack aimed at entities sealed to48trust measurements.49 501. The attacker could intercept all PCR extends coming from the system51 and completely substitute their own values, producing a replay of52 an untampered state that would cause PCR measurements to attest to53 a trusted state and release secrets54 552. At some point in time the attacker could reset the TPM, clearing56 the PCRs and then send down their own measurements which would57 effectively overwrite the boot time measurements the TPM has58 already done.59 60The first can be thwarted by always doing HMAC protection of the PCR61extend and read command meaning measurement values cannot be62substituted without producing a detectable HMAC failure in the63response. However, the second can only really be detected by relying64on some sort of mechanism for protection which would change over TPM65reset.66 67Secrets Guarding68----------------69 70Certain information passing in and out of the TPM, such as key sealing71and private key import and random number generation, is vulnerable to72interception which HMAC protection alone cannot protect against, so73for these types of command we must also employ request and response74encryption to prevent the loss of secret information.75 76Establishing Initial Trust with the TPM77---------------------------------------78 79In order to provide security from the beginning, an initial shared or80asymmetric secret must be established which must also be unknown to81the attacker. The most obvious avenues for this are the endorsement82and storage seeds, which can be used to derive asymmetric keys.83However, using these keys is difficult because the only way to pass84them into the kernel would be on the command line, which requires85extensive support in the boot system, and there's no guarantee that86either hierarchy would not have some type of authorization.87 88The mechanism chosen for the Linux Kernel is to derive the primary89elliptic curve key from the null seed using the standard storage seed90parameters. The null seed has two advantages: firstly the hierarchy91physically cannot have an authorization, so we are always able to use92it and secondly, the null seed changes across TPM resets, meaning if93we establish trust on the null seed at start of day, all sessions94salted with the derived key will fail if the TPM is reset and the seed95changes.96 97Obviously using the null seed without any other prior shared secrets,98we have to create and read the initial public key which could, of99course, be intercepted and substituted by the bus interposer.100However, the TPM has a key certification mechanism (using the EK101endorsement certificate, creating an attestation identity key and102certifying the null seed primary with that key) which is too complex103to run within the kernel, so we keep a copy of the null primary key104name, which is what is exported via sysfs so user-space can run the105full certification when it boots. The definitive guarantee here is106that if the null primary key certifies correctly, you know all your107TPM transactions since start of day were secure and if it doesn't, you108know there's an interposer on your system (and that any secret used109during boot may have been leaked).110 111Stacking Trust112--------------113 114In the current null primary scenario, the TPM must be completely115cleared before handing it on to the next consumer. However the kernel116hands to user-space the name of the derived null seed key which can117then be verified by certification in user-space. Therefore, this chain118of name handoff can be used between the various boot components as119well (via an unspecified mechanism). For instance, grub could use the120null seed scheme for security and hand the name off to the kernel in121the boot area. The kernel could make its own derivation of the key122and the name and know definitively that if they differ from the handed123off version that tampering has occurred. Thus it becomes possible to124chain arbitrary boot components together (UEFI to grub to kernel) via125the name handoff provided each successive component knows how to126collect the name and verifies it against its derived key.127 128Session Properties129------------------130 131All TPM commands the kernel uses allow sessions. HMAC sessions may be132used to check the integrity of requests and responses and decrypt and133encrypt flags may be used to shield parameters and responses. The134HMAC and encryption keys are usually derived from the shared135authorization secret, but for a lot of kernel operations that is well136known (and usually empty). Thus, every HMAC session used by the137kernel must be created using the null primary key as the salt key138which thus provides a cryptographic input into the session key139derivation. Thus, the kernel creates the null primary key once (as a140volatile TPM handle) and keeps it around in a saved context stored in141tpm_chip for every in-kernel use of the TPM. Currently, because of a142lack of de-gapping in the in-kernel resource manager, the session must143be created and destroyed for each operation, but, in future, a single144session may also be reused for the in-kernel HMAC, encryption and145decryption sessions.146 147Protection Types148----------------149 150For every in-kernel operation we use null primary salted HMAC to151protect the integrity. Additionally, we use parameter encryption to152protect key sealing and parameter decryption to protect key unsealing153and random number generation.154 155Null Primary Key Certification in Userspace156===========================================157 158Every TPM comes shipped with a couple of X.509 certificates for the159primary endorsement key. This document assumes that the Elliptic160Curve version of the certificate exists at 01C00002, but will work161equally well with the RSA certificate (at 01C00001).162 163The first step in the certification is primary creation using the164template from the `TCG EK Credential Profile`_ which allows comparison165of the generated primary key against the one in the certificate (the166public key must match). Note that generation of the EK primary167requires the EK hierarchy password, but a pre-generated version of the168EC primary should exist at 81010002 and a TPM2_ReadPublic() may be169performed on this without needing the key authority. Next, the170certificate itself must be verified to chain back to the manufacturer171root (which should be published on the manufacturer website). Once172this is done, an attestation key (AK) is generated within the TPM and173it's name and the EK public key can be used to encrypt a secret using174TPM2_MakeCredential. The TPM then runs TPM2_ActivateCredential which175will only recover the secret if the binding between the TPM, the EK176and the AK is true. the generated AK may now be used to run a177certification of the null primary key whose name the kernel has178exported. Since TPM2_MakeCredential/ActivateCredential are somewhat179complicated, a more simplified process involving an externally180generated private key is described below.181 182This process is a simplified abbreviation of the usual privacy CA183based attestation process. The assumption here is that the184attestation is done by the TPM owner who thus has access to only the185owner hierarchy. The owner creates an external public/private key186pair (assume elliptic curve in this case) and wraps the private key187for import using an inner wrapping process and parented to the EC188derived storage primary. The TPM2_Import() is done using a parameter189decryption HMAC session salted to the EK primary (which also does not190require the EK key authority) meaning that the inner wrapping key is191the encrypted parameter and thus the TPM will not be able to perform192the import unless is possesses the certified EK so if the command193succeeds and the HMAC verifies on return we know we have a loadable194copy of the private key only for the certified TPM. This key is now195loaded into the TPM and the Storage primary flushed (to free up space196for the null key generation).197 198The null EC primary is now generated using the Storage profile199outlined in the `TCG TPM v2.0 Provisioning Guidance`_; the name of200this key (the hash of the public area) is computed and compared to the201null seed name presented by the kernel in202/sys/class/tpm/tpm0/null_name. If the names do not match, the TPM is203compromised. If the names match, the user performs a TPM2_Certify()204using the null primary as the object handle and the loaded private key205as the sign handle and providing randomized qualifying data. The206signature of the returned certifyInfo is verified against the public207part of the loaded private key and the qualifying data checked to208prevent replay. If all of these tests pass, the user is now assured209that TPM integrity and privacy was preserved across the entire boot210sequence of this kernel.211 212.. _TPM Genie: https://www.nccgroup.trust/globalassets/about-us/us/documents/tpm-genie.pdf213.. _Windows Bitlocker TPM: https://dolosgroup.io/blog/2021/7/9/from-stolen-laptop-to-inside-the-company-network214.. _attack against TPM based Linux disk encryption: https://www.secura.com/blog/tpm-sniffing-attacks-against-non-bitlocker-targets215.. _TCG EK Credential Profile: https://trustedcomputinggroup.org/resource/tcg-ek-credential-profile-for-tpm-family-2-0/216.. _TCG TPM v2.0 Provisioning Guidance: https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/217