This commit is contained in:
Nicolas Williams 2021-05-14 11:29:36 -05:00
parent 17ddd5b3df
commit f42e665d0b

View file

@ -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
- limited resources
- tickets
- resource management
- sessions
- authorization
- restricted cryptographic keys
- policies
- other object types
- non-volatile (NV) indexes
- limited resources
- 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).