mirror of
https://github.com/tpm2dev/tpm.dev.tutorials.git
synced 2024-11-24 23:02:11 +00:00
WIP
This commit is contained in:
parent
17ddd5b3df
commit
f42e665d0b
1 changed files with 40 additions and 23 deletions
|
@ -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).
|
||||
|
|
Loading…
Reference in a new issue