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