1.. SPDX-License-Identifier: GPL-2.0-only 2 3TPM Security 4============ 5 6The object of this document is to describe how we make the kernel's 7use of the TPM reasonably robust in the face of external snooping and 8packet alteration attacks (called passive and active interposer attack 9in the literature). The current security document is for TPM 2.0. 10 11Introduction 12------------ 13 14The TPM is usually a discrete chip attached to a PC via some type of 15low bandwidth bus. There are exceptions to this such as the Intel 16PTT, which is a software TPM running inside a software environment 17close to the CPU, which are subject to different attacks, but right at 18the moment, most hardened security environments require a discrete 19hardware TPM, which is the use case discussed here. 20 21Snooping and Alteration Attacks against the bus 22----------------------------------------------- 23 24The current state of the art for snooping the `TPM Genie`_ hardware 25interposer which is a simple external device that can be installed in 26a couple of seconds on any system or laptop. Recently attacks were 27successfully demonstrated against the `Windows Bitlocker TPM`_ system. 28Most recently the same `attack against TPM based Linux disk 29encryption`_ schemes. The next phase of research seems to be hacking 30existing devices on the bus to act as interposers, so the fact that 31the attacker requires physical access for a few seconds might 32evaporate. However, the goal of this document is to protect TPM 33secrets and integrity as far as we are able in this environment and to 34try to insure that if we can't prevent the attack then at least we can 35detect it. 36 37Unfortunately, most of the TPM functionality, including the hardware 38reset capability can be controlled by an attacker who has access to 39the bus, so we'll discuss some of the disruption possibilities below. 40 41Measurement (PCR) Integrity 42--------------------------- 43 44Since the attacker can send their own commands to the TPM, they can 45send arbitrary PCR extends and thus disrupt the measurement system, 46which would be an annoying denial of service attack. However, there 47are two, more serious, classes of attack aimed at entities sealed to 48trust measurements. 49 501. The attacker could intercept all PCR extends coming from the system 51 and completely substitute their own values, producing a replay of 52 an untampered state that would cause PCR measurements to attest to 53 a trusted state and release secrets 54 552. At some point in time the attacker could reset the TPM, clearing 56 the PCRs and then send down their own measurements which would 57 effectively overwrite the boot time measurements the TPM has 58 already done. 59 60The first can be thwarted by always doing HMAC protection of the PCR 61extend and read command meaning measurement values cannot be 62substituted without producing a detectable HMAC failure in the 63response. However, the second can only really be detected by relying 64on some sort of mechanism for protection which would change over TPM 65reset. 66 67Secrets Guarding 68---------------- 69 70Certain information passing in and out of the TPM, such as key sealing 71and private key import and random number generation, is vulnerable to 72interception which HMAC protection alone cannot protect against, so 73for these types of command we must also employ request and response 74encryption to prevent the loss of secret information. 75 76Establishing Initial Trust with the TPM 77--------------------------------------- 78 79In order to provide security from the beginning, an initial shared or 80asymmetric secret must be established which must also be unknown to 81the attacker. The most obvious avenues for this are the endorsement 82and storage seeds, which can be used to derive asymmetric keys. 83However, using these keys is difficult because the only way to pass 84them into the kernel would be on the command line, which requires 85extensive support in the boot system, and there's no guarantee that 86either hierarchy would not have some type of authorization. 87 88The mechanism chosen for the Linux Kernel is to derive the primary 89elliptic curve key from the null seed using the standard storage seed 90parameters. The null seed has two advantages: firstly the hierarchy 91physically cannot have an authorization, so we are always able to use 92it and secondly, the null seed changes across TPM resets, meaning if 93we establish trust on the null seed at start of day, all sessions 94salted with the derived key will fail if the TPM is reset and the seed 95changes. 96 97Obviously using the null seed without any other prior shared secrets, 98we have to create and read the initial public key which could, of 99course, be intercepted and substituted by the bus interposer. 100However, the TPM has a key certification mechanism (using the EK 101endorsement certificate, creating an attestation identity key and 102certifying the null seed primary with that key) which is too complex 103to run within the kernel, so we keep a copy of the null primary key 104name, which is what is exported via sysfs so user-space can run the 105full certification when it boots. The definitive guarantee here is 106that if the null primary key certifies correctly, you know all your 107TPM transactions since start of day were secure and if it doesn't, you 108know there's an interposer on your system (and that any secret used 109during boot may have been leaked). 110 111Stacking Trust 112-------------- 113 114In the current null primary scenario, the TPM must be completely 115cleared before handing it on to the next consumer. However the kernel 116hands to user-space the name of the derived null seed key which can 117then be verified by certification in user-space. Therefore, this chain 118of name handoff can be used between the various boot components as 119well (via an unspecified mechanism). For instance, grub could use the 120null seed scheme for security and hand the name off to the kernel in 121the boot area. The kernel could make its own derivation of the key 122and the name and know definitively that if they differ from the handed 123off version that tampering has occurred. Thus it becomes possible to 124chain arbitrary boot components together (UEFI to grub to kernel) via 125the name handoff provided each successive component knows how to 126collect the name and verifies it against its derived key. 127 128Session Properties 129------------------ 130 131All TPM commands the kernel uses allow sessions. HMAC sessions may be 132used to check the integrity of requests and responses and decrypt and 133encrypt flags may be used to shield parameters and responses. The 134HMAC and encryption keys are usually derived from the shared 135authorization secret, but for a lot of kernel operations that is well 136known (and usually empty). Thus, every HMAC session used by the 137kernel must be created using the null primary key as the salt key 138which thus provides a cryptographic input into the session key 139derivation. Thus, the kernel creates the null primary key once (as a 140volatile TPM handle) and keeps it around in a saved context stored in 141tpm_chip for every in-kernel use of the TPM. Currently, because of a 142lack of de-gapping in the in-kernel resource manager, the session must 143be created and destroyed for each operation, but, in future, a single 144session may also be reused for the in-kernel HMAC, encryption and 145decryption sessions. 146 147Protection Types 148---------------- 149 150For every in-kernel operation we use null primary salted HMAC to 151protect the integrity. Additionally, we use parameter encryption to 152protect key sealing and parameter decryption to protect key unsealing 153and random number generation. 154 155Null Primary Key Certification in Userspace 156=========================================== 157 158Every TPM comes shipped with a couple of X.509 certificates for the 159primary endorsement key. This document assumes that the Elliptic 160Curve version of the certificate exists at 01C00002, but will work 161equally well with the RSA certificate (at 01C00001). 162 163The first step in the certification is primary creation using the 164template from the `TCG EK Credential Profile`_ which allows comparison 165of the generated primary key against the one in the certificate (the 166public key must match). Note that generation of the EK primary 167requires the EK hierarchy password, but a pre-generated version of the 168EC primary should exist at 81010002 and a TPM2_ReadPublic() may be 169performed on this without needing the key authority. Next, the 170certificate itself must be verified to chain back to the manufacturer 171root (which should be published on the manufacturer website). Once 172this is done, an attestation key (AK) is generated within the TPM and 173it's name and the EK public key can be used to encrypt a secret using 174TPM2_MakeCredential. The TPM then runs TPM2_ActivateCredential which 175will only recover the secret if the binding between the TPM, the EK 176and the AK is true. the generated AK may now be used to run a 177certification of the null primary key whose name the kernel has 178exported. Since TPM2_MakeCredential/ActivateCredential are somewhat 179complicated, a more simplified process involving an externally 180generated private key is described below. 181 182This process is a simplified abbreviation of the usual privacy CA 183based attestation process. The assumption here is that the 184attestation is done by the TPM owner who thus has access to only the 185owner hierarchy. The owner creates an external public/private key 186pair (assume elliptic curve in this case) and wraps the private key 187for import using an inner wrapping process and parented to the EC 188derived storage primary. The TPM2_Import() is done using a parameter 189decryption HMAC session salted to the EK primary (which also does not 190require the EK key authority) meaning that the inner wrapping key is 191the encrypted parameter and thus the TPM will not be able to perform 192the import unless is possesses the certified EK so if the command 193succeeds and the HMAC verifies on return we know we have a loadable 194copy of the private key only for the certified TPM. This key is now 195loaded into the TPM and the Storage primary flushed (to free up space 196for the null key generation). 197 198The null EC primary is now generated using the Storage profile 199outlined in the `TCG TPM v2.0 Provisioning Guidance`_; the name of 200this key (the hash of the public area) is computed and compared to the 201null seed name presented by the kernel in 202/sys/class/tpm/tpm0/null_name. If the names do not match, the TPM is 203compromised. If the names match, the user performs a TPM2_Certify() 204using the null primary as the object handle and the loaded private key 205as the sign handle and providing randomized qualifying data. The 206signature of the returned certifyInfo is verified against the public 207part of the loaded private key and the qualifying data checked to 208prevent replay. If all of these tests pass, the user is now assured 209that TPM integrity and privacy was preserved across the entire boot 210sequence of this kernel. 211 212.. _TPM Genie: https://www.nccgroup.trust/globalassets/about-us/us/documents/tpm-genie.pdf 213.. _Windows Bitlocker TPM: https://dolosgroup.io/blog/2021/7/9/from-stolen-laptop-to-inside-the-company-network 214.. _attack against TPM based Linux disk encryption: https://www.secura.com/blog/tpm-sniffing-attacks-against-non-bitlocker-targets 215.. _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