fmaury/tpm.dev.tutorials
1
0
Fork 0
mirror of https://github.com/tpm2dev/tpm.dev.tutorials.git synced 2024-11-24 23:02:11 +00:00
Code Issues Projects Releases Packages Wiki Activity

WIP

Browse source
This commit is contained in:
Nicolas Williams 2021-05-14 11:29:36 -05:00
parent 17ddd5b3df
commit f42e665d0b
1 changed files with 40 additions and 23 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

63
Intro/README.md
View file

@ -2,7 +2,7 @@
Trusted Platform Modules (TPMs) are a large and complex topic, made all Trusted Platform Modules (TPMs) are a large and complex topic, made all
the more difficult to explain by the intricate relationships between the 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 simpler than reading hundreds of pages of documents, but then too, too
light on detail to be immediately useful. 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, Typically a TPM is a hardware module, a chip, though there are firmware,
virtual, and simulated TPMs as well, all implemented in software. virtual, and simulated TPMs as well, all implemented in software.
To simplify things we'll consider only TPM 2.0. Also to simplify things To simplify things we'll consider only TPM 2.0.
we'll ignore algorithm agility.
Other parts of this [tutorial](README.md) may cover specific concepts in Other parts of this [tutorial](README.md) may cover specific concepts in
much more detail. much more detail.
@ -33,19 +32,16 @@ here):
- immutability of object public areas - immutability of object public areas
- key hierarchies - key hierarchies
- key wrapping - key wrapping
- restricted cryptographic keys
- limited resources - limited resources
- tickets - sessions and authorization
- resource management - other object types, mainly non-volatile (NV) indexes
- sessions
- authorization
- restricted cryptographic keys
- policies
- other object types
- non-volatile (NV) indexes
- attestation - attestation
We'll assume reader familiarity with cryptography so we need not explain We'll assume reader familiarity with the basics of cryptography -- the
it. 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 Authorization is the most important aspect of a TPM, since that's
ultimately what it exists for: to authorize a system or application to 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 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 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". 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 the current PCR values represent a trusted state. For example, one
might have a database of known-good and known-bad firmware/ROM digests, 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 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 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.
@ -206,7 +202,7 @@ to defeat active attacks.
Because the name of an object is a digest of its public area, the public 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 area cannot be changed after creating it. One can delete and then
recreate an object in order to "change" its public area, but this 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 ### 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 The primary key is always a decrypt-only asymmetric private key, and its
corresponding public key is therefore encrypt-only. This is largely corresponding public key is therefore encrypt-only. This is largely
because of key wrapping, where a symmetric key or asymmetric private key because of key wrapping, where a secret or private key is encrypted to a
is encrypted to a TPM's EKpub so that it can be safely sent to that TPM TPM's EKpub so that it can be safely sent to that TPM so that that TPM
so that that TPM can then decrypt and use that secret. can then decrypt and use that secret.
As well as wrapping secrets by encryption to public keys, TPMs also use 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 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 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. 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 A key that is `fixedParent` cannot be moved from one part of a key
is neither `fixedParent` nor `fixedTPM` then the parent and its 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. 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 ## Persistence
Cryptographic keys are, by default, not stored on non-volatile memory. Cryptographic keys are, by default, not stored on non-volatile memory.
Hardware TPMs have very little non-volatile (NV) memory. They also have Hardware TPMs have very little non-volatile (NV) memory. They also have
very limited volatile memory as well. 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 ## Non-Volatile (NV) Indexes
@ -454,3 +458,16 @@ many TPM concepts can be used to great effect:
- authorization of devices onto a network - authorization of devices onto a network
- etc. - 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).