This commit is contained in:
Nicolas Williams 2021-05-14 17:16:52 -05:00
parent ca4b14f5a2
commit b84c7075c1

View file

@ -27,6 +27,7 @@ here):
- cryptography
- hash extension
- tickets
- cryptographic object naming
- platform configuration registers (PCRs)
- 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
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
TPMs support a variety of types of objects. Objects generally have
@ -239,9 +270,8 @@ cut-and-paste attack in attestation protocols.
## Key Hierarchies
TPMs have multiple key hierarchies, all rooted in a primary decrypt-only
asymmetric private key derived from a seed, with arbitrarily complex
trees of keys below the primary key:
TPMs have multiple key hierarchies, each with zero, one or more primary
keys, each with zero, one, or more children keys:
```
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
have zero, one, or more children.
Note that every key has a parent or is a primary key.
There are three built-in hierarchies:
There are four built-in hierarchies:
- platform hierarchy
- endorsement hierarchy
- storage hierarchy
- null hierarchy
of which only the endorsement and storage hierarchies will be of
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
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
its corresponding public key is therefore encrypt-only. This is largely
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.
Key wrapping is encrypting a secret or private key (key encryotion key,
or KEK) such that a specific entity may recover the plain key.
## 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
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
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.
In a TPM, key objects are, by default, transient, meaning the TPM will
forget them if restarted. Still, they can be saved (encrypted in a
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
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.
Because primary keys (for any hierarchy other than the null hierarchy)
are derived deterministically from a built-in and protected seed, and
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
@ -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
as part of specific TPM restricted signing commands. Such content
always begins with a magic byte sequence, and the TPM refuses to sign
externally generated content that starts with that magic byte sequence.
always begins with a magic byte sequence. Conversely, the TPM refuses
to sign externally generated content that starts with that magic byte
sequence.
A restricted decryption key can only be used to decrypt ciphertexts
whose plaintexts have a certain structure. In particular these are used