From f42e665d0b31b1674c8fc96114bd7e03cb7b5537 Mon Sep 17 00:00:00 2001 From: Nicolas Williams Date: Fri, 14 May 2021 11:29:36 -0500 Subject: [PATCH] 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).