mirror of
https://github.com/tpm2dev/tpm.dev.tutorials.git
synced 2024-11-12 18:02:10 +00:00
WIP
This commit is contained in:
parent
ca4b14f5a2
commit
b84c7075c1
1 changed files with 58 additions and 23 deletions
|
@ -27,6 +27,7 @@ here):
|
||||||
|
|
||||||
- cryptography
|
- cryptography
|
||||||
- hash extension
|
- hash extension
|
||||||
|
- tickets
|
||||||
- cryptographic object naming
|
- cryptographic object naming
|
||||||
- platform configuration registers (PCRs)
|
- platform configuration registers (PCRs)
|
||||||
- immutability of object public areas
|
- 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
|
execute) and to not extend PCRs accordingly, in which case the execution
|
||||||
of untrusted code will not be reflected in any RTM.
|
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
|
## Cryptographic Object Naming
|
||||||
|
|
||||||
TPMs support a variety of types of objects. Objects generally have
|
TPMs support a variety of types of objects. Objects generally have
|
||||||
|
@ -239,9 +270,8 @@ cut-and-paste attack in attestation protocols.
|
||||||
|
|
||||||
## Key Hierarchies
|
## Key Hierarchies
|
||||||
|
|
||||||
TPMs have multiple key hierarchies, all rooted in a primary decrypt-only
|
TPMs have multiple key hierarchies, each with zero, one or more primary
|
||||||
asymmetric private key derived from a seed, with arbitrarily complex
|
keys, each with zero, one, or more children keys:
|
||||||
trees of keys below the primary key:
|
|
||||||
|
|
||||||
```
|
```
|
||||||
seed
|
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
|
Note that every key has a parent or is a primary key.
|
||||||
have zero, one, or more children.
|
|
||||||
|
|
||||||
There are three built-in hierarchies:
|
There are four built-in hierarchies:
|
||||||
|
|
||||||
- platform hierarchy
|
- platform hierarchy
|
||||||
- endorsement hierarchy
|
- endorsement hierarchy
|
||||||
- storage hierarchy
|
- storage hierarchy
|
||||||
|
- null hierarchy
|
||||||
|
|
||||||
of which only the endorsement and storage hierarchies will be of
|
of which only the endorsement and storage hierarchies will be of
|
||||||
interest to most readers.
|
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
|
("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 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
|
Key wrapping is encrypting a secret or private key (key encryotion key,
|
||||||
its corresponding public key is therefore encrypt-only. This is largely
|
or KEK) such that a specific entity may recover the plain key.
|
||||||
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
|
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
|
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
|
||||||
|
@ -318,17 +346,23 @@ descendants can be moved as a group to some other TPM.
|
||||||
|
|
||||||
## Persistence
|
## Persistence
|
||||||
|
|
||||||
Cryptographic keys are, by default, not stored on non-volatile memory.
|
In a TPM, key objects are, by default, transient, meaning the TPM will
|
||||||
Hardware TPMs have very little non-volatile (NV) memory. They also have
|
forget them if restarted. Still, they can be saved (encrypted in a
|
||||||
very limited volatile memory as well.
|
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
|
Because primary keys (for any hierarchy other than the null hierarchy)
|
||||||
the TPM will encrypt the exported key in a symmetric secret key that
|
are derived deterministically from a built-in and protected seed, and
|
||||||
only the TPM knows, and only the same TPM can reload it.
|
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
|
## 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
|
A restricted signing key can be used to sign only TPM-generated content
|
||||||
as part of specific TPM restricted signing commands. Such content
|
as part of specific TPM restricted signing commands. Such content
|
||||||
always begins with a magic byte sequence, and the TPM refuses to sign
|
always begins with a magic byte sequence. Conversely, the TPM refuses
|
||||||
externally generated content that starts with that magic byte sequence.
|
to sign externally generated content that starts with that magic byte
|
||||||
|
sequence.
|
||||||
|
|
||||||
A restricted decryption key can only be used to decrypt ciphertexts
|
A restricted decryption key can only be used to decrypt ciphertexts
|
||||||
whose plaintexts have a certain structure. In particular these are used
|
whose plaintexts have a certain structure. In particular these are used
|
||||||
|
|
Loading…
Reference in a new issue