From 90d9bc261974ea24b993267d46d9b17014371149 Mon Sep 17 00:00:00 2001 From: Nicolas Williams Date: Tue, 11 May 2021 18:54:56 -0500 Subject: [PATCH 01/10] Add introduction to TPMs --- Intro/README.md | 455 ++++++++++++++++++++++++++++++++++++++++++++++++ README.md | 8 +- 2 files changed, 459 insertions(+), 4 deletions(-) create mode 100644 Intro/README.md diff --git a/Intro/README.md b/Intro/README.md new file mode 100644 index 0000000..bf08ad4 --- /dev/null +++ b/Intro/README.md @@ -0,0 +1,455 @@ +# Introduction to TPMs + +Trusted Platform Modules (TPMs) are a large and complex topic, made all +the more difficult to explain by the intricate relationships between the +relevant concepts. This is an attempt at a simple explanation -- +simpler than reading hundreds of pages of documents, but then too, too +light on detail to be immediately useful. + +So what is a TPM? Well, it's a cryptographic co-processor with special +features to enable "root of trust measurement" (RTM), remote attestation +of system state, unlocking of local resources that are kept encrypted +(e.g., filesystems), and more. A TPM can do those things, and it can do +it with rich authentication and authorization policies. + +Typically a TPM is a hardware module, a chip, though there are firmware, +virtual, and simulated TPMs as well, all implemented in software. + +To simplify things we'll consider only TPM 2.0. Also to simplify things +we'll ignore algorithm agility. + +Other parts of this [tutorial](README.md) may cover specific concepts in +much more detail. + +# Core Concepts + +Some core concepts in the world of TPMs + + - cryptography: + - digest functions + - hash extension + - HMAC + - symmetric encryption + - asymmetric encryption and/or signature algorithms + - platform configuration registers (PCRs) + - cryptographic object naming + - immutability of object public areas + - key hierarchies + - key wrapping + - limited resources + - tickets + - resource management + - sessions + - authorization + - restricted cryptographic keys + - policies + - other object types + - non-volatile (NV) indexes + - attestation + +We'll assume reader familiarity with cryptography so we need not explain +it. + +Authorization is the most important aspect of a TPM, since that's +ultimately what it exists for: to authorize a system or application to +perform certain duties when all the desired conditions allow for it. + +TPMs have a very rich set of options for authorization. It's not just +[policies](#Policies), but also cryptographic object names used with +restricted keys to allow access only to applications that also have +other access. + +Where to start? Let's start with hash extension, which may be the only +trivial concept in the world of TPMs! + +## Important Notes + + - Chained implications. + + It is important to note the TPM ecosystem's critical dependence on + TPMs performing authorization as specified. A lot can be + accomplished by chaining cryptographic implications. Sending a + secret to a TPM-using application, with the secret encrypted in that + TPM's primary endorsement public key is safe when one knows that + public key truly is a legitimate hardware TPM's public key: the TPM + will not release the secret to the application unless the recipient + has some access specified by the sender. Complex chains of events + can be secure provided one knows that it involves legitimate hardware + TPMs that otherwise could not be secured. Therefore the legitimacy + of a TPM that one communicates with is essential. + + - Limited resources. + + Hardware TPMs are very resource-starved. The set of commands defined + by the TCG TPM specifications is specifically constructed to a) be + small and simple (simple-enough anyways), yet b) enable rich + semantics in spite of this. + + These limited resources mean, among other things, that TPMs don't do + complex things like PKIX certificate validation path construction, or + even PKIX certificate path validation, nor do they implement complex + authentication protocols using PKIX, nor Kerberos, nor even simple + protocols like JWT. Hardware TPMs can be used to implement portions + of such complex protocols (e.g., certificate issuance), but they + cannot implement the entirety of such protocols. + + - Hardware TPMs are _slow_. + + - A *lot* of detail is left out here. Nothing is said about how TPMs + interface with the system or applications. Little is said about + specific commands, and nothing is said about most commands. Nothing + is said about TPM software stacks or APIs. + + Our goal is only to help the lay reader understand TPMs well enough + at the conceptual level that they will be more comfortable + approaching mure more detailed TPM-related tutorials, documents, + books, or TCG specifications. + +## Hash Extension + +Hash extension is just appending some data to a current digest-sized +value, hashing that, and then calling the output the new current value: + +``` + v_0 = 0 # size-of-digest-output zero bits + v_1 = Extend(v_0, e_0) + = H(v_0 || e_0) + v_2 = Extend(v_1, e_1) + = H(v_1 || e_1) + = H(H(v_0 || e_0) || e_1) + v_3 = Extend(v_2, e_2) + = H(v_2 || e_2) + = H(H(v_1 || e_1) || e_2) + = H(H(H(v_0 || e_0) || e_1) || e_2) + .. + v_n = Extend(v_n-1, e_n-1) + = H(v_n-1 || e_n-1) + = H(H(v_n-2 || e_n-2) || e_n-1) + = H(H(...) || e_n-1) +``` + +where `H()` is a cryptographic hash function. + +Hash extension is most of what a PCR is, but hash extension is in other +TPM concepts besides PCRs, such as policy naming. + +## Platform Configuration Registers (PCRs) + +A PCR, then, is just a hash output. The only operations on PCRs are: +read, extend, and reset. All richness of semantics of PCRs come from +how they are used: + + - how they are extended and by what code + - what purposes they are read for + - attestation + - authorization + +## Root of Trust Measurements (RTM) + +When a computer and its TPM start up, most PCRs are set to all-zeros, +and then the computer's boot firmware performs a core root of trust +measurement (CRTM) to "measure" (i.e., hash) the the next boot stage and +extend it into an agreed-upon PCR. The entire boot process should, +ideally, perform RTMs. At the end of the boot process some set of PCRs +should reflect the totality of the code path taken to complete booting. + +Some PCRs are used to measure the BIOS, others to measure option ROMs, +and others to measure the operating system. In principle one could +measure the entirety of an operating system and all the code that is +installed on the system. + +RTM can be used to ensure that only known-trusted code is executed, and +that important resources are not unlocked unless the state of the system +when they are needed is "only executed trusted code". + +Note that some PCRs are left to be used by "applications". + +Some terms: + + - core RTM (CRTM) -- initial measurements performed upon power-on + - static RTM (SRTM) -- subsequent-to-CRTM measurements of next boot + stages + - dynamic RTM (DRTM) -- measurements involved in rebooting + +Resource unlocking can be done by creating objects tied to a set of PCRs +such that they must each have specific values for the TPM to be willing +to unlock (unseal) the object. + +### The PCR Extension Eventlog + +On the "PC platform" (which includes x64 servers) the BIOS keeps a log +of all the PCR extensions it has performed. The OS should keep its own +log of extensions it performs. + +The eventlog documents how the PCRs evolved to their current state, +whatever it might be. Since PCR extension values are typically digests, +the eventlog is very dry, but it can still be used to evaluate whether +the current PCR values represent a trusted state. For example, one +might have a database of known-good and known-bad firmware/ROM digests, +then one can check that only known-good ones appear in the eventlog and +that reproducing the hash extensions described by the eventlot produces +the same PCR values as one can read, and if so it follows that the +system has only executed trusted code. + +Note though that PCRs and RTM are not enough on their own to keep a +system from executing untrusted code. A system can be configured to +allow execution of arbitrary code at some point (e.g., download and +execute) and to not extend PCRs accordingly, in which case the execution +of untrusted code will not be reflected in any RTM. + +## Object Naming + +TPMs support a variety of types of objects. Objects generally have +pointer-like "handles" that they are often used in the TPM APIs. But +more importantly, objects have cryptographically-secure names that are +used in many cases. + + The cryptographically-secure name of an object is the hash of the + object's "public area". + +The public area of, say, an asymmetric key is a data structure that +includes the public key (corresponding to the private key), and various +attributes of the key (e.g., its algorithm, but also whether it is bound +to the TPM where it resides, or to its key hierarchy), unseal policy, +and access policy. + +This concept is extremely important. Because object names are the +outputs of cryptographically strong digest (hash) functions, they are +resistant to collision attacks, first pre-image attacks, and second +pre-image attacks -- as strong as the hash algorithm used anyways. +Which means that object names cannot be forged easily, which means that +they can be used in context where a peer needs certain guarantees, or +to defeat active attacks. + +### Immutability of Object Public Areas + +Because the name of an object is a digest of its public area, the public +area cannot be changed after creating it. One can delete and then +recreate an object in order to "change" its public area, but this +necessarily yields a new name (assuming no digest collisions). + +## Key Hierarchies + +TPMs have multiple key hierarchies, all rooted in a primary decrypt-only +asymmetric private key derived from a seed, with arbitrarily complex +trees of keys below the primary key: + +``` + seed + | + | + v + primary key (asymmetric encryption) + | + | + v + secondary keys (of any kind) + | + | + v + ... +``` + +There are three built-in hierarchies: + + - platform hierarchy + - endorsement hierarchy + - storage hierarchy + +of which only the endorsement and storage hierarchies will be of +interest to most readers. + +The endorsement hierarchy is used to authenticate (when needed) that a +TPM is a legitimate TPM. The primary endorsement key is known as the EK +(endorsement key). Hardware TPMs come with a certificate for the EK +issued by the TPM's manufacturer. This EK certificate ("EKcert") can be +used to authenticate the TPM's legitimacy. The EK's public key +("EKpub") can be used to uniquely identify a TPM, and possibly link to +the platform's, and even the platform's user(s)' identities. + +## Key Wrapping and Resource Management + +The primary key is always a decrypt-only asymmetric private key, and its +corresponding public key is therefore encrypt-only. This is largely +because of key wrapping, where a symmetric key or asymmetric private key +is encrypted to a TPM's EKpub so that it can be safely sent to that TPM +so that that TPM can then decrypt and use that secret. + +As well as wrapping secrets by encryption to public keys, TPMs also use +wrapping in a symmetric key known only to the TPM for the purpose of +saving keys off the TPM. This is used for resource management: since +hardware TPMs have very limited resources, objects need to created or +loaded, used, then saved off-TPM to make room for other objects to be +loaded (unless they are not to be used again, then saving them is +pointless). Only a TPM that saved an object can load it again, but some +objects can be exported to other TPMs by encrypting them to their +destination TPMs' EKpubs. + +### Controlling Exportability of Keys + +A key that is `fixedTPM` cannot leave the TPM in cleartext. It can be +saved off the TPM it resides in, but only that TPM can load it again. + +A key that is `fixedParent` cannot be re-parented, though if its parent +is neither `fixedParent` nor `fixedTPM` then the parent and its +descendants can be moved as a group to some other TPM. + +## Persistence + +Cryptographic keys are, by default, not stored on non-volatile memory. +Hardware TPMs have very little non-volatile (NV) memory. They also have +very limited volatile memory as well. + +PCRs always exist, but they get reset on restart. + +Keys can be moved to NV storage. + +## Non-Volatile (NV) Indexes + +TPMs also have a special kind of non-volatile object: NV indexes. + +NV indexes come in multiple flavors for various uses: + + - store public data (e.g., an NV index is used to store the EKcert) + - emulate PCRs + - monotonic counters + - fields of write-once bits (for, e.g., revocation) + - ... + +NV indexes can be used standalone, and/or in connection with policies, +to enrich application TPM semantics. + +## Authentication and Authorization + +TPMs have multiple ways to authenticate users/entities: + + - plain passwords (legacy) + - HMAC based on secret keys or passwords + - public key signed attestations of identification by biometric + authentication devices + +TPMs have two ways to authorize access to various objects: + + - plain passwords (legacy) + - HMAC proof of possession of a secret key or password + - arbitrarily complex policies that can make reference to: + - PCR state + - NV index state + - time of day + - authentication state + - etc. + +### Policies + +A policy consists of a sequence of "commands" that each asserts +something of interest. + +Policies are particularly interesting because they are cryptographically +named using hash extension with the sequence of "commands" that make up +a policy. Therefore no matter how complex and large a policy is, it is +always "compressed" to a hash digest. + +It is the responsibility of the application that will attempt to use a +policy-protected resource to know what the policy's definition is and +restate it to the TPM when it goes to make use of that resource. Thus, +and because policies are `O(1)` in storage size, they can be arbitrarily +more complex than a TPM's limited resources would otherwise allow. + +All the policy commands that are to be evaluated successfully to grant +access have to be known to the entity that wants that access. Of +course, that entity will have to satisfy -at access time- the conditions +expressed by the relevant policy. The application has to know the +policy because the TPM knows only a digest of it. + +### Policy Construction + +Construction of a policy consists of computing it by hash extending an +initial all-zeroes value with the commands that make up the policy. + +### Policy Evaluation + +Evaluation of a policy consists of issuing those same commands to the +TPM in a session, with those commands either evaluated immediately or +deferred to the time of execution of the to-be-authorized command, but +the TPM computes the same hash extension as it goes. Once all policy +commands being evaluated have succeeded, the resulting hash extension +value is compared to the policy that protects the resource(s) being used +by the to-be-authorized command, and if it matches, then the command is +allowed, otherwise it is not. + +### Indirect Policies + +Because an object's policy is part of its name, that policy cannot be +changed after creation. An indirect policy command allows for the +inclusion of a policy stored in an NV index. + +### Compound Policies + +Policies consist of a conjunction (logical-AND) of assertions that must +be true at evaluation time. + +However, there is a special policy command that allows for alternation +(logical-OR). This policy command has a number of alternative policy +digests. At evaluation time, one of the alternation digests must match +the extension value for the policy commands up to (but excluding) the +logical-OR policy command. At evaluation time the caller must have +picked one of the alternatives and executed the commands that make it +up. + +(Recall that the application has to know the definition of the policy +because the TPM knows only the policy's digest.) + +### Rich Policy Semantics + +With all these features, and with all the flexibility allowed by NV +indexes, policies can be used to: + + - require that N-of-M users authenticate + - enforce bank vault-like time of day restrictions + - require multi-factor authentication (password, biometric, smartcard) + - check revocation + - check system RTM state + - distinguish user roles (admin roles get access to some resources, + user roles get access to other resources) + +## Sessions + +A session is an object (meaning, among other things, that it can be +loaded and unloaded as needed) that represents the current policy +construction or evaluation hash extension digest (the `policyDigest`), +and the objects that have been granted access. + +## Restricted Cryptographic Keys + +Cryptographic keys can either be unrestricted or restricted. + +An unrestricted signing key can be used to sign arbitrary content. + +A restricted signing key can be used to sign only content that begins +with a magic byte sequence, and which the TPM allows only to be used in +certain operations. + +A restricted decryption key can only be used to decrypt ciphertexts +whose plaintexts have a certain structure. In particular these are used +for `TPM2_MakeCredential()`/`TPM2_ActivateCredential()` to allow the +TPM-using application to get the plaintext if and only if (IFF) the +plaintext cryptographically names an object that the application has +access to. This is used to communicate secrets ("credentials") to TPMs. + +## Attestation + +Attestation is the process of demonstrating that a system's current +state is "trusted", or the truthfulness of some set of assertions. + +As you can see in our [tutorial on attestation](Attestation/README.md), +many TPM concepts can be used to great effect: + + - using PCRs to attest to system state + - using policies and sealed-to-PCRs objects to attest to authentication + events on the system + - using restricted keys to authenticate a TPM and bind it to its host + - delivering key material to authenticated systems via their TPMs + - unlocking resources following successful attestation + - authorization of devices onto a network + - etc. + diff --git a/README.md b/README.md index 2f2e693..7149d11 100644 --- a/README.md +++ b/README.md @@ -12,10 +12,10 @@ Why GitHub? ## Current list of tutorials from [TPM.dev] members -1. Attestation, MakeCredential, ActivateCredential -1. Boot with TPM: Secure vs Measured vs Trusted -1. Random Number Generator -1. TPM Introduction (Work in progress - PR #8) +1. [Boot with TPM: Secure vs Measured vs Trusted](Boot-with-TPM/tpmboot.md) +1. [Random Number Generator](Random_Number_Generator/article.md) +1. [Attestation, MakeCredential, ActivateCredential](Attestation/README.md) +1. Introduction to TPM Concepts (Work in progress - PR #8) ## List of tutorials that will be transfered to GitHub from [TPM.dev] From 17ddd5b3dfc350f4432b8c40347cce487da2a720 Mon Sep 17 00:00:00 2001 From: Nicolas Williams Date: Fri, 14 May 2021 00:34:48 -0500 Subject: [PATCH 02/10] WIP --- Intro/README.md | 119 ++++++++++++++++++++++++------------------------ 1 file changed, 60 insertions(+), 59 deletions(-) diff --git a/Intro/README.md b/Intro/README.md index bf08ad4..6e48ed5 100644 --- a/Intro/README.md +++ b/Intro/README.md @@ -23,16 +23,13 @@ much more detail. # Core Concepts -Some core concepts in the world of TPMs +Some core concepts in the world of TPMs (not all of which we'll discuss +here): - - cryptography: - - digest functions - - hash extension - - HMAC - - symmetric encryption - - asymmetric encryption and/or signature algorithms - - platform configuration registers (PCRs) + - cryptography + - hash extension - cryptographic object naming + - platform configuration registers (PCRs) - immutability of object public areas - key hierarchies - key wrapping @@ -62,49 +59,6 @@ other access. Where to start? Let's start with hash extension, which may be the only trivial concept in the world of TPMs! -## Important Notes - - - Chained implications. - - It is important to note the TPM ecosystem's critical dependence on - TPMs performing authorization as specified. A lot can be - accomplished by chaining cryptographic implications. Sending a - secret to a TPM-using application, with the secret encrypted in that - TPM's primary endorsement public key is safe when one knows that - public key truly is a legitimate hardware TPM's public key: the TPM - will not release the secret to the application unless the recipient - has some access specified by the sender. Complex chains of events - can be secure provided one knows that it involves legitimate hardware - TPMs that otherwise could not be secured. Therefore the legitimacy - of a TPM that one communicates with is essential. - - - Limited resources. - - Hardware TPMs are very resource-starved. The set of commands defined - by the TCG TPM specifications is specifically constructed to a) be - small and simple (simple-enough anyways), yet b) enable rich - semantics in spite of this. - - These limited resources mean, among other things, that TPMs don't do - complex things like PKIX certificate validation path construction, or - even PKIX certificate path validation, nor do they implement complex - authentication protocols using PKIX, nor Kerberos, nor even simple - protocols like JWT. Hardware TPMs can be used to implement portions - of such complex protocols (e.g., certificate issuance), but they - cannot implement the entirety of such protocols. - - - Hardware TPMs are _slow_. - - - A *lot* of detail is left out here. Nothing is said about how TPMs - interface with the system or applications. Little is said about - specific commands, and nothing is said about most commands. Nothing - is said about TPM software stacks or APIs. - - Our goal is only to help the lay reader understand TPMs well enough - at the conceptual level that they will be more comfortable - approaching mure more detailed TPM-related tutorials, documents, - books, or TCG specifications. - ## Hash Extension Hash extension is just appending some data to a current digest-sized @@ -130,20 +84,43 @@ value, hashing that, and then calling the output the new current value: where `H()` is a cryptographic hash function. +Each extension value can be arbitrarily large, and the TPM will use the +traditional `Init`/`Update`/`Final` approach to making digest +computation online. + +Note that `H(e0 || e1 || e2) != Extend(Extend(Extend(0, e0), e1), e2)`. +Hash extension makes "message" boundaries strong. + Hash extension is most of what a PCR is, but hash extension is in other TPM concepts besides PCRs, such as policy naming. ## Platform Configuration Registers (PCRs) -A PCR, then, is just a hash output. The only operations on PCRs are: -read, extend, and reset. All richness of semantics of PCRs come from -how they are used: +A PCR, then, is just a hash extension output. The only operations on +PCRs are: read, extend, and reset. All richness of semantics of PCRs +come from how they are used: - how they are extended and by what code - what purposes they are read for - attestation - authorization +Note that a PCR value by itself is devoid of meaning. To add meaning +one must have access to the list of discrete values extended into the +PCR, as well as the order in which they were extended into the PCR. And +one must know the meaning of each such value. + +### Eventlogs + +Any TPM-using platform has to provide a way to keep a log of PCR hash +extension values. Such a log is known as the "eventlog". + +The TPM itself cannot hold this log for the TPM is resource-constrained. + +Indeed, hash extension is used by TPMs as a sort of a compression +function that represents a larger state that may not fit on the TPM. +PCRs are one case, and authorization policies are another. + ## Root of Trust Measurements (RTM) When a computer and its TPM start up, most PCRs are set to all-zeros, @@ -154,9 +131,10 @@ ideally, perform RTMs. At the end of the boot process some set of PCRs should reflect the totality of the code path taken to complete booting. Some PCRs are used to measure the BIOS, others to measure option ROMs, -and others to measure the operating system. In principle one could -measure the entirety of an operating system and all the code that is -installed on the system. +and others to measure the operating system. Each platform has a +specification for which PCRs are used or reserved for what purposes. In +principle one could measure the entirety of an operating system and all +the code that is installed on the system. RTM can be used to ensure that only known-trusted code is executed, and that important resources are not unlocked unless the state of the system @@ -179,7 +157,9 @@ to unlock (unseal) the object. On the "PC platform" (which includes x64 servers) the BIOS keeps a log of all the PCR extensions it has performed. The OS should keep its own -log of extensions it performs. +log of extensions it performs of PCRs reserved to the OS. Each +application has to keep a log of the extensions of the PCRs allocated to +it. Again, the TPM itself cannot do this. The eventlog documents how the PCRs evolved to their current state, whatever it might be. Since PCR extension values are typically digests, @@ -228,6 +208,26 @@ area cannot be changed after creating it. One can delete and then recreate an object in order to "change" its public area, but this necessarily yields a new name (assuming no digest collisions). +### Cryptographic Object Naming as a Binding + +> This section comes too soon, since it relates to attestation and +> restricted keys. Still, it may be useful to illustrate cryptographic +> object naming with one particularly important use of it. + +A pair of functions, `TPM2_MakeCredential()` and +`TPM2_ActivateCredential()`, illustrate the use of cryptographic object +naming as a binding or a sort of authorization function. + +`TPM2_MakeCredential()` can be used to encrypt a datum (a "credential") +to a target TPM such that the target will _only be willing to decrypt +it_ if *and only if* the application calling `TPM2_ActivateCredential()` +to decrypt that credential has access to some key named by the sender, +and that name is a cryptographic name that the sender can and must +compute for itself. + +The semantics of these two functions can be used to defeat a +cut-and-paste attack in attestation protocols. + ## Key Hierarchies TPMs have multiple key hierarchies, all rooted in a primary decrypt-only @@ -447,7 +447,8 @@ many TPM concepts can be used to great effect: - using PCRs to attest to system state - using policies and sealed-to-PCRs objects to attest to authentication events on the system - - using restricted keys to authenticate a TPM and bind it to its host + - using restricted keys and cryptographic object naming to authenticate + a TPM and bind it to its host - delivering key material to authenticated systems via their TPMs - unlocking resources following successful attestation - authorization of devices onto a network From f42e665d0b31b1674c8fc96114bd7e03cb7b5537 Mon Sep 17 00:00:00 2001 From: Nicolas Williams Date: Fri, 14 May 2021 11:29:36 -0500 Subject: [PATCH 03/10] WIP --- Intro/README.md | 63 +++++++++++++++++++++++++++++++------------------ 1 file changed, 40 insertions(+), 23 deletions(-) diff --git a/Intro/README.md b/Intro/README.md index 6e48ed5..c0f57c2 100644 --- a/Intro/README.md +++ b/Intro/README.md @@ -2,7 +2,7 @@ Trusted Platform Modules (TPMs) are a large and complex topic, made all the more difficult to explain by the intricate relationships between the -relevant concepts. This is an attempt at a simple explanation -- +relevant concepts. This is an attempt at a simple explanation -- much simpler than reading hundreds of pages of documents, but then too, too light on detail to be immediately useful. @@ -15,8 +15,7 @@ it with rich authentication and authorization policies. Typically a TPM is a hardware module, a chip, though there are firmware, virtual, and simulated TPMs as well, all implemented in software. -To simplify things we'll consider only TPM 2.0. Also to simplify things -we'll ignore algorithm agility. +To simplify things we'll consider only TPM 2.0. Other parts of this [tutorial](README.md) may cover specific concepts in much more detail. @@ -33,19 +32,16 @@ here): - immutability of object public areas - key hierarchies - key wrapping + - restricted cryptographic keys - limited resources - - tickets - - resource management - - sessions - - authorization - - restricted cryptographic keys - - policies - - other object types - - non-volatile (NV) indexes + - sessions and authorization + - other object types, mainly non-volatile (NV) indexes - attestation -We'll assume reader familiarity with cryptography so we need not explain -it. +We'll assume reader familiarity with the basics of cryptography -- the +basics of cryptographic primitives as interfaces, but not their +internals. E.g., hash functions, symmetric encryption, asymmetric +encryption, and digital signatures. Authorization is the most important aspect of a TPM, since that's ultimately what it exists for: to authorize a system or application to @@ -138,7 +134,7 @@ the code that is installed on the system. RTM can be used to ensure that only known-trusted code is executed, and that important resources are not unlocked unless the state of the system -when they are needed is "only executed trusted code". +when they are needed is "has only executed trusted code to get here". Note that some PCRs are left to be used by "applications". @@ -167,7 +163,7 @@ the eventlog is very dry, but it can still be used to evaluate whether the current PCR values represent a trusted state. For example, one might have a database of known-good and known-bad firmware/ROM digests, then one can check that only known-good ones appear in the eventlog and -that reproducing the hash extensions described by the eventlot produces +that reproducing the hash extensions described by the eventlog produces the same PCR values as one can read, and if so it follows that the system has only executed trusted code. @@ -206,7 +202,7 @@ to defeat active attacks. Because the name of an object is a digest of its public area, the public area cannot be changed after creating it. One can delete and then recreate an object in order to "change" its public area, but this -necessarily yields a new name (assuming no digest collisions). +necessarily yields a new name. ### Cryptographic Object Naming as a Binding @@ -271,9 +267,9 @@ the platform's, and even the platform's user(s)' identities. The primary key is always a decrypt-only asymmetric private key, and its corresponding public key is therefore encrypt-only. This is largely -because of key wrapping, where a symmetric key or asymmetric private key -is encrypted to a TPM's EKpub so that it can be safely sent to that TPM -so that that TPM can then decrypt and use that secret. +because of key wrapping, where a secret or private key is encrypted to a +TPM's EKpub so that it can be safely sent to that TPM so that that TPM +can then decrypt and use that secret. As well as wrapping secrets by encryption to public keys, TPMs also use wrapping in a symmetric key known only to the TPM for the purpose of @@ -290,19 +286,27 @@ destination TPMs' EKpubs. A key that is `fixedTPM` cannot leave the TPM in cleartext. It can be saved off the TPM it resides in, but only that TPM can load it again. -A key that is `fixedParent` cannot be re-parented, though if its parent -is neither `fixedParent` nor `fixedTPM` then the parent and its +A key that is `fixedParent` cannot be moved from one part of a key +hierarchy to another -- it cannot be "re-parented". Though if its +parent is neither `fixedParent` nor `fixedTPM` then the parent and its descendants can be moved as a group to some other TPM. +> Key hierarchies are an important TPM topic that we're not really +> addresing in this intro. + ## Persistence Cryptographic keys are, by default, not stored on non-volatile memory. Hardware TPMs have very little non-volatile (NV) memory. They also have very limited volatile memory as well. -PCRs always exist, but they get reset on restart. +Keys can be moved to NV storage, to a point. -Keys can be moved to NV storage. +Keys can also be persisted off-TPM by saving them (see above). For this +the TPM will encrypt the exported key in a symmetric secret key that +only the TPM knows, and only the same TPM can reload it. + +PCRs always exist, but they get reset on restart. ## Non-Volatile (NV) Indexes @@ -454,3 +458,16 @@ many TPM concepts can be used to great effect: - authorization of devices onto a network - etc. +# Other Resources + +Nokia has a [TPM course](https://github.com/nokia/TPMCourse/tree/master/docs). + +The TCG has a number of members-only tutorials, but it seems that it is +possible to be invited to be a non-fee paying member. + +Core TCG TPM specs: + + - [TCG TPM 2.0 Library part 1: Architecture](https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part1_Architecture_pub.pdf). + - [TCG TPM 2.0 Library part 2: Structures](https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part2_Structures_pub.pdf). + - [TCG TPM 2.0 Library part 3: Commands, section 12](https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part3_Commands_pub.pdf). + - [TCG TPM 2.0 Library part 3: Commands Code, section 12](https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part3_Commands_code_pub.pdf). From ebe5b0a88fb53501c8ce800ddecb6896f3e2b258 Mon Sep 17 00:00:00 2001 From: Nicolas Williams Date: Fri, 14 May 2021 11:52:01 -0500 Subject: [PATCH 04/10] WIP --- Intro/README.md | 80 ++++++++++++++++++++++++++++++++----------------- 1 file changed, 52 insertions(+), 28 deletions(-) diff --git a/Intro/README.md b/Intro/README.md index c0f57c2..718b204 100644 --- a/Intro/README.md +++ b/Intro/README.md @@ -90,6 +90,18 @@ Hash extension makes "message" boundaries strong. Hash extension is most of what a PCR is, but hash extension is in other TPM concepts besides PCRs, such as policy naming. +## Coping with Severe Resource Limits Using Digests and Hash Extension + +Hardware TPMs are extremely limited in memory and non-volatile memory +capacity. As a result they cannot hold large entities. + +A common theme in TPMs is the use of digests, and hash extension digests +in particular, as a stand-in for large entities that cannot exist at +once on the TPM. + +We'll discuss at least two such large entities: event logs, and +policies. + ## Platform Configuration Registers (PCRs) A PCR, then, is just a hash extension output. The only operations on @@ -111,11 +123,8 @@ one must know the meaning of each such value. Any TPM-using platform has to provide a way to keep a log of PCR hash extension values. Such a log is known as the "eventlog". -The TPM itself cannot hold this log for the TPM is resource-constrained. - -Indeed, hash extension is used by TPMs as a sort of a compression -function that represents a larger state that may not fit on the TPM. -PCRs are one case, and authorization policies are another. +The TPM itself cannot hold this log -- the TPM is too +resource-constrained. ## Root of Trust Measurements (RTM) @@ -173,7 +182,7 @@ allow execution of arbitrary code at some point (e.g., download and execute) and to not extend PCRs accordingly, in which case the execution of untrusted code will not be reflected in any RTM. -## Object Naming +## Cryptographic Object Naming TPMs support a variety of types of objects. Objects generally have pointer-like "handles" that they are often used in the TPM APIs. But @@ -246,6 +255,8 @@ trees of keys below the primary key: ... ``` +Note that every key has a parent or is a primary key. + There are three built-in hierarchies: - platform hierarchy @@ -263,23 +274,29 @@ used to authenticate the TPM's legitimacy. The EK's public key ("EKpub") can be used to uniquely identify a TPM, and possibly link to the platform's, and even the platform's user(s)' identities. -## Key Wrapping and Resource Management +## Key Wrapping The primary key is always a decrypt-only asymmetric private key, and its corresponding public key is therefore encrypt-only. This is largely -because of key wrapping, where a secret or private key is encrypted to a -TPM's EKpub so that it can be safely sent to that TPM so that that TPM +because of _key wrapping_, where a secret or private key is encrypted to +a TPM's EKpub so that it can be safely sent to that TPM so that that TPM can then decrypt and use that secret. +## Saving Resources Off-TPM + As well as wrapping secrets by encryption to public keys, TPMs also use wrapping in a symmetric key known only to the TPM for the purpose of -saving keys off the TPM. This is used for resource management: since -hardware TPMs have very limited resources, objects need to created or -loaded, used, then saved off-TPM to make room for other objects to be -loaded (unless they are not to be used again, then saving them is -pointless). Only a TPM that saved an object can load it again, but some -objects can be exported to other TPMs by encrypting them to their -destination TPMs' EKpubs. +saving keys off the TPM. + +This is used for resource management: since hardware TPMs have very +limited resources, objects need to created or loaded, used, then saved +off-TPM to make room for other objects to be loaded (unless they are not +to be used again, then saving them is pointless). Only a TPM that saved +an object can load it again, but some objects can be exported to other +TPMs by encrypting them to their destination TPMs' EKpubs. + +With a resource manager and access broker, a TPM can appear to have +infinite resources. ### Controlling Exportability of Keys @@ -355,14 +372,16 @@ always "compressed" to a hash digest. It is the responsibility of the application that will attempt to use a policy-protected resource to know what the policy's definition is and -restate it to the TPM when it goes to make use of that resource. Thus, -and because policies are `O(1)` in storage size, they can be arbitrarily -more complex than a TPM's limited resources would otherwise allow. +restate it to the TPM when it goes to make use of that resource. The +TPM will evaluate the policy and, at the end, check that its digest +matches that of the policy-protected resource. Thus, and because policy +digests are small and fixed-sized, they can be arbitrarily more complex +than a TPM's limited resources would otherwise allow. All the policy commands that are to be evaluated successfully to grant access have to be known to the entity that wants that access. Of course, that entity will have to satisfy -at access time- the conditions -expressed by the relevant policy. The application has to know the +expressed by the relevant policy. And that entity has to know the policy because the TPM knows only a digest of it. ### Policy Construction @@ -409,12 +428,11 @@ With all these features, and with all the flexibility allowed by NV indexes, policies can be used to: - require that N-of-M users authenticate - - enforce bank vault-like time of day restrictions - require multi-factor authentication (password, biometric, smartcard) - - check revocation - - check system RTM state - - distinguish user roles (admin roles get access to some resources, - user roles get access to other resources) + - enforce bank vault-like time of day restrictions + - check revocation (using NV index bit-field objects) + - check system RTM state (PCRs) + - distinguish user roles ## Sessions @@ -429,9 +447,9 @@ Cryptographic keys can either be unrestricted or restricted. An unrestricted signing key can be used to sign arbitrary content. -A restricted signing key can be used to sign only content that begins -with a magic byte sequence, and which the TPM allows only to be used in -certain operations. +A restricted signing key can be used to sign only TPM-generated content +as part of specific TPM restricted signing commands. Such content +always begins with a magic byte sequence. A restricted decryption key can only be used to decrypt ciphertexts whose plaintexts have a certain structure. In particular these are used @@ -440,11 +458,17 @@ TPM-using application to get the plaintext if and only if (IFF) the plaintext cryptographically names an object that the application has access to. This is used to communicate secrets ("credentials") to TPMs. +There is also a notion of signing keys that can only be used to sign +PKIX certificates. + ## Attestation Attestation is the process of demonstrating that a system's current state is "trusted", or the truthfulness of some set of assertions. +Often a system gets something in exchange for attesting to its current +state. E.g., keys for unlocking filesystems, or device credentials. + As you can see in our [tutorial on attestation](Attestation/README.md), many TPM concepts can be used to great effect: From 63f5e96b0f225146f3751565532a06eac0284948 Mon Sep 17 00:00:00 2001 From: Nicolas Williams Date: Fri, 14 May 2021 13:09:52 -0500 Subject: [PATCH 05/10] WIP --- Intro/README.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/Intro/README.md b/Intro/README.md index 718b204..bb3b9d0 100644 --- a/Intro/README.md +++ b/Intro/README.md @@ -99,8 +99,13 @@ A common theme in TPMs is the use of digests, and hash extension digests in particular, as a stand-in for large entities that cannot exist at once on the TPM. -We'll discuss at least two such large entities: event logs, and -policies. +TPMs use digests as stand-ins for large entities of various types: + + - eventlogs + - policies + - auditing + +We'll discuss at least two of those: event logs, and policies. ## Platform Configuration Registers (PCRs) @@ -255,7 +260,8 @@ trees of keys below the primary key: ... ``` -Note that every key has a parent or is a primary key. +Note that every key has a parent or is a primary key, and every key can +have zero, one, or more children. There are three built-in hierarchies: From ca4b14f5a2df606255b705b14d8166e2bf99cd81 Mon Sep 17 00:00:00 2001 From: Nicolas Williams Date: Fri, 14 May 2021 14:40:55 -0500 Subject: [PATCH 06/10] WIP --- Intro/README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Intro/README.md b/Intro/README.md index bb3b9d0..7ad9974 100644 --- a/Intro/README.md +++ b/Intro/README.md @@ -52,8 +52,7 @@ TPMs have a very rich set of options for authorization. It's not just restricted keys to allow access only to applications that also have other access. -Where to start? Let's start with hash extension, which may be the only -trivial concept in the world of TPMs! +Where to start? Let's start with hash extension. ## Hash Extension @@ -282,8 +281,8 @@ the platform's, and even the platform's user(s)' identities. ## Key Wrapping -The primary key is always a decrypt-only asymmetric private key, and its -corresponding public key is therefore encrypt-only. This is largely +The primary key is generally a decrypt-only asymmetric private key, and +its corresponding public key is therefore encrypt-only. This is largely because of _key wrapping_, where a secret or private key is encrypted to a TPM's EKpub so that it can be safely sent to that TPM so that that TPM can then decrypt and use that secret. @@ -455,7 +454,8 @@ An unrestricted signing key can be used to sign arbitrary content. A restricted signing key can be used to sign only TPM-generated content as part of specific TPM restricted signing commands. Such content -always begins with a magic byte sequence. +always begins with a magic byte sequence, and the TPM refuses to sign +externally generated content that starts with that magic byte sequence. A restricted decryption key can only be used to decrypt ciphertexts whose plaintexts have a certain structure. In particular these are used From b84c7075c1e16a43dde580e01e5ad4e33400aa0b Mon Sep 17 00:00:00 2001 From: Nicolas Williams Date: Fri, 14 May 2021 17:16:52 -0500 Subject: [PATCH 07/10] WIP --- Intro/README.md | 81 +++++++++++++++++++++++++++++++++++-------------- 1 file changed, 58 insertions(+), 23 deletions(-) diff --git a/Intro/README.md b/Intro/README.md index 7ad9974..d4841d5 100644 --- a/Intro/README.md +++ b/Intro/README.md @@ -27,6 +27,7 @@ here): - cryptography - hash extension + - tickets - cryptographic object naming - platform configuration registers (PCRs) - immutability of object public areas @@ -186,6 +187,36 @@ allow execution of arbitrary code at some point (e.g., download and execute) and to not extend PCRs accordingly, in which case the execution of untrusted code will not be reflected in any RTM. +## Tickets + +> Tickets are yet another device for coping with TPMs having limited +> resources. Interaction with TPMs is via request/response +> commands. + +To avoid having to re-perform various operations -or remember having +performed them- between command invocations, a TPM can produce a +"ticket" that consists of an HMAC over a TPM-generated assertion, keyed +by a key known only to the TPM, and return it to the caller who can then +present it in a subsequent command related to the first. + +For example, when signing data the TPM will first digest the data to +sign over several commands and generate a ticket saying it did produce +that digest, then later it can sign the digest after validating the +ticket that it produced. + +Another example is a policy ticket, which allows one to avoid having to +re-authenticate (e.g., with smartcard, biometrics, passwords) on every +command for small window of time. + +> When would a user be authenticated? Well, typically at boot time, or +> maybe at wake from sleep/hibernate time. A laptop could be configured +> to require a user to authenticate with biometrics and possibly a +> password or a smartcard. + +> There are five types of tickets. We won't cover them here. Readers +> who end up needing to know about them can look at section 11.4.6.3 of +> `TCG TPM 2.0 Library, part 1: Architecture`. + ## Cryptographic Object Naming TPMs support a variety of types of objects. Objects generally have @@ -239,9 +270,8 @@ cut-and-paste attack in attestation protocols. ## Key Hierarchies -TPMs have multiple key hierarchies, all rooted in a primary decrypt-only -asymmetric private key derived from a seed, with arbitrarily complex -trees of keys below the primary key: +TPMs have multiple key hierarchies, each with zero, one or more primary +keys, each with zero, one, or more children keys: ``` seed @@ -259,14 +289,14 @@ trees of keys below the primary key: ... ``` -Note that every key has a parent or is a primary key, and every key can -have zero, one, or more children. +Note that every key has a parent or is a primary key. -There are three built-in hierarchies: +There are four built-in hierarchies: - platform hierarchy - endorsement hierarchy - storage hierarchy + - null hierarchy of which only the endorsement and storage hierarchies will be of interest to most readers. @@ -279,15 +309,13 @@ used to authenticate the TPM's legitimacy. The EK's public key ("EKpub") can be used to uniquely identify a TPM, and possibly link to the platform's, and even the platform's user(s)' identities. -## Key Wrapping +## Key Wrapping and Resource Management -The primary key is generally a decrypt-only asymmetric private key, and -its corresponding public key is therefore encrypt-only. This is largely -because of _key wrapping_, where a secret or private key is encrypted to -a TPM's EKpub so that it can be safely sent to that TPM so that that TPM -can then decrypt and use that secret. +Key wrapping is encrypting a secret or private key (key encryotion key, +or KEK) such that a specific entity may recover the plain key. -## Saving Resources Off-TPM +A decrypt-only asymmetric private key can be used to encrypt secrets to +the TPM on which that private key resides. As well as wrapping secrets by encryption to public keys, TPMs also use wrapping in a symmetric key known only to the TPM for the purpose of @@ -318,17 +346,23 @@ descendants can be moved as a group to some other TPM. ## Persistence -Cryptographic keys are, by default, not stored on non-volatile memory. -Hardware TPMs have very little non-volatile (NV) memory. They also have -very limited volatile memory as well. +In a TPM, key objects are, by default, transient, meaning the TPM will +forget them if restarted. Still, they can be saved (encrypted in a +secret key only the TPM knows) and later reloaded. -Keys can be moved to NV storage, to a point. +Transient objects can be made persistent, but because hardware TPMs have +very little non-volatile memory, few keys should be made persistent. +Instead you can save them (wrapped to a TPM-only KEK) and reload them as +needed. -Keys can also be persisted off-TPM by saving them (see above). For this -the TPM will encrypt the exported key in a symmetric secret key that -only the TPM knows, and only the same TPM can reload it. +Because primary keys (for any hierarchy other than the null hierarchy) +are derived deterministically from a built-in and protected seed, and +from a template, they are persistent even when not moved to NV storage +and even when not saved. -PCRs always exist, but they get reset on restart. +PCRs always persist, but they get reset on restart. + +NV indexes always persist. ## Non-Volatile (NV) Indexes @@ -454,8 +488,9 @@ An unrestricted signing key can be used to sign arbitrary content. A restricted signing key can be used to sign only TPM-generated content as part of specific TPM restricted signing commands. Such content -always begins with a magic byte sequence, and the TPM refuses to sign -externally generated content that starts with that magic byte sequence. +always begins with a magic byte sequence. Conversely, the TPM refuses +to sign externally generated content that starts with that magic byte +sequence. A restricted decryption key can only be used to decrypt ciphertexts whose plaintexts have a certain structure. In particular these are used From 47e2e5210baa395d641ca40478a622cac37d6889 Mon Sep 17 00:00:00 2001 From: Nicolas Williams Date: Fri, 14 May 2021 20:36:15 -0500 Subject: [PATCH 08/10] WIP --- Intro/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Intro/README.md b/Intro/README.md index d4841d5..ace1a28 100644 --- a/Intro/README.md +++ b/Intro/README.md @@ -27,7 +27,6 @@ here): - cryptography - hash extension - - tickets - cryptographic object naming - platform configuration registers (PCRs) - immutability of object public areas @@ -191,7 +190,8 @@ of untrusted code will not be reflected in any RTM. > Tickets are yet another device for coping with TPMs having limited > resources. Interaction with TPMs is via request/response -> commands. +> commands, and tickets are largely about making TPMs stateless between +> related commands. To avoid having to re-perform various operations -or remember having performed them- between command invocations, a TPM can produce a From cea79316bf3cb2e8c9b797995bbee83e6b99333f Mon Sep 17 00:00:00 2001 From: Nicolas Williams Date: Tue, 18 May 2021 11:34:51 -0500 Subject: [PATCH 09/10] WIP --- Intro/README.md | 72 ++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 59 insertions(+), 13 deletions(-) diff --git a/Intro/README.md b/Intro/README.md index ace1a28..4329f23 100644 --- a/Intro/README.md +++ b/Intro/README.md @@ -12,6 +12,9 @@ of system state, unlocking of local resources that are kept encrypted (e.g., filesystems), and more. A TPM can do those things, and it can do it with rich authentication and authorization policies. +> The standards development organization that publishes TPM specifications +> is the [Trusted Computing Group (TCG)](https://trustedcomputinggroup.org). + Typically a TPM is a hardware module, a chip, though there are firmware, virtual, and simulated TPMs as well, all implemented in software. @@ -20,10 +23,41 @@ To simplify things we'll consider only TPM 2.0. Other parts of this [tutorial](README.md) may cover specific concepts in much more detail. +# Goals + +The goal of this introductory material is to help readers new to TPMs to +understand them well enough to approach the subjects of: + + - [attestation](/Attestation/README.md) + - [secure boot](/Boot-with-TPM/README.md) + +and to think about the sorts of things that one can do with TPMs in +general, which include: + + - device on-boarding + - ascertaining the state of a device (e.g., has it executed only + trusted code) + - unlocking of devices using TPM-based authentication and authorization + policies (e.g., unlocking a laptop on boot multiple factors such as + biometrics, smartcards, passwords, time of day, even interaction with + remote services) + - using a TPM as a source of entropy for a running OS + +> NOTE: At this time this introduction is very much a layman's +> introduction, and only an introduction. Readers seeking to do +> software development using TPMs will want to make use of [TCG +> specifications and other resources](#Other-Resources). + +## Glossary + +> For a glossary, see section 4 of [TCG TPM 2.0 Library part 1: +> Architecture](https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part1_Architecture_pub.pdf). + # Core Concepts -Some core concepts in the world of TPMs (not all of which we'll discuss -here): +Some core concepts in the world of TPMs: + +> NOTE: We will not cover all of these here. - cryptography - hash extension @@ -86,8 +120,8 @@ computation online. Note that `H(e0 || e1 || e2) != Extend(Extend(Extend(0, e0), e1), e2)`. Hash extension makes "message" boundaries strong. -Hash extension is most of what a PCR is, but hash extension is in other -TPM concepts besides PCRs, such as policy naming. +Hash extension is most of what a PCR is, but hash extension is used in +other TPM concepts besides PCRs, such as policy naming. ## Coping with Severe Resource Limits Using Digests and Hash Extension @@ -95,7 +129,7 @@ Hardware TPMs are extremely limited in memory and non-volatile memory capacity. As a result they cannot hold large entities. A common theme in TPMs is the use of digests, and hash extension digests -in particular, as a stand-in for large entities that cannot exist at +in particular, as a stand-in for large entities that might not fit at once on the TPM. TPMs use digests as stand-ins for large entities of various types: @@ -112,7 +146,8 @@ A PCR, then, is just a hash extension output. The only operations on PCRs are: read, extend, and reset. All richness of semantics of PCRs come from how they are used: - - how they are extended and by what code + - what the governing TCG platform specification says about them + - what they are extended with and by what code (in what locality) - what purposes they are read for - attestation - authorization @@ -170,7 +205,7 @@ log of extensions it performs of PCRs reserved to the OS. Each application has to keep a log of the extensions of the PCRs allocated to it. Again, the TPM itself cannot do this. -The eventlog documents how the PCRs evolved to their current state, +The eventlog documents how each PCR evolved to their current state, whatever it might be. Since PCR extension values are typically digests, the eventlog is very dry, but it can still be used to evaluate whether the current PCR values represent a trusted state. For example, one @@ -178,7 +213,8 @@ might have a database of known-good and known-bad firmware/ROM digests, then one can check that only known-good ones appear in the eventlog and that reproducing the hash extensions described by the eventlog produces the same PCR values as one can read, and if so it follows that the -system has only executed trusted code. +system has only executed trusted code to arrive at the state identified +by the PCRs. Note though that PCRs and RTM are not enough on their own to keep a system from executing untrusted code. A system can be configured to @@ -211,7 +247,8 @@ command for small window of time. > When would a user be authenticated? Well, typically at boot time, or > maybe at wake from sleep/hibernate time. A laptop could be configured > to require a user to authenticate with biometrics and possibly a -> password or a smartcard. +> password or a smartcard. Note that such policies are not required by +> the specifications, but rather something that one can choose to use. > There are five types of tickets. We won't cover them here. Readers > who end up needing to know about them can look at section 11.4.6.3 of @@ -368,12 +405,18 @@ NV indexes always persist. TPMs also have a special kind of non-volatile object: NV indexes. +> NOTE: NV indexes are not "objects" in the sense that the TCG's +> specifications mean. TCG's definition of "object" is +> +> > key or data that has a public portion and, optionally, a +> > sensitive portion; and which is a member of a hierarchy + NV indexes come in multiple flavors for various uses: - store public data (e.g., an NV index is used to store the EKcert) - emulate PCRs - monotonic counters - - fields of write-once bits (for, e.g., revocation) + - fields of write-once bits (bitfields) (for, e.g., revocation) - ... NV indexes can be used standalone, and/or in connection with policies, @@ -442,8 +485,8 @@ allowed, otherwise it is not. ### Indirect Policies Because an object's policy is part of its name, that policy cannot be -changed after creation. An indirect policy command allows for the -inclusion of a policy stored in an NV index. +changed after creation. An indirect policy command allows for a policy +to change over time without having to recreate the authorized object. ### Compound Policies @@ -510,7 +553,7 @@ state is "trusted", or the truthfulness of some set of assertions. Often a system gets something in exchange for attesting to its current state. E.g., keys for unlocking filesystems, or device credentials. -As you can see in our [tutorial on attestation](Attestation/README.md), +As you can see in our [tutorial on attestation](/Attestation/README.md), many TPM concepts can be used to great effect: - using PCRs to attest to system state @@ -525,6 +568,9 @@ many TPM concepts can be used to great effect: # Other Resources +[A Practical Guide to TPM 2.0](https://trustedcomputinggroup.org/resource/a-practical-guide-to-tpm-2-0/) +is an excellent book that informed much of this tutorial. + Nokia has a [TPM course](https://github.com/nokia/TPMCourse/tree/master/docs). The TCG has a number of members-only tutorials, but it seems that it is From eca6a3b7d60df602c16000cb281b2f119e92cb4a Mon Sep 17 00:00:00 2001 From: Nicolas Williams Date: Tue, 18 May 2021 17:19:17 -0500 Subject: [PATCH 10/10] WIP --- Intro/README.md | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/Intro/README.md b/Intro/README.md index 4329f23..d3efdd0 100644 --- a/Intro/README.md +++ b/Intro/README.md @@ -346,6 +346,11 @@ used to authenticate the TPM's legitimacy. The EK's public key ("EKpub") can be used to uniquely identify a TPM, and possibly link to the platform's, and even the platform's user(s)' identities. +The `TPM2_CreatePrimary()` and `TPM2_CreateLoaded()` commands create key +objects deterministically from the hierarchy's seed and the "template" +used to create the key (which includes a "unique" area that provides +"entropy" to the key derivation function). + ## Key Wrapping and Resource Management Key wrapping is encrypting a secret or private key (key encryotion key, @@ -395,11 +400,17 @@ needed. Because primary keys (for any hierarchy other than the null hierarchy) are derived deterministically from a built-in and protected seed, and from a template, they are persistent even when not moved to NV storage -and even when not saved. +and even when not saved as long as the hierarchy's seed is not reset. + +(Resetting the endorsement hierarchy seed is a very dramatic action, as +it changes the EK/EKpub and renders any provisioned EKcert useless. +Resetting the storage hierarchy seed is much less dramatic. The NULL +hierarchy is reset every time the TPM resets.) PCRs always persist, but they get reset on restart. -NV indexes always persist. +NV indexes always persist. (But in disorderly resets/shutdowns a +hybrid NV index may not be sync'ed to NV.) ## Non-Volatile (NV) Indexes