mirror of
https://github.com/tpm2dev/tpm.dev.tutorials.git
synced 2024-11-10 01:12:10 +00:00
WIP
This commit is contained in:
parent
f42e665d0b
commit
ebe5b0a88f
1 changed files with 52 additions and 28 deletions
|
@ -90,6 +90,18 @@ Hash extension makes "message" boundaries strong.
|
||||||
Hash extension is most of what a PCR is, but hash extension is in other
|
Hash extension is most of what a PCR is, but hash extension is in other
|
||||||
TPM concepts besides PCRs, such as policy naming.
|
TPM concepts besides PCRs, such as policy naming.
|
||||||
|
|
||||||
|
## Coping with Severe Resource Limits Using Digests and Hash Extension
|
||||||
|
|
||||||
|
Hardware TPMs are extremely limited in memory and non-volatile memory
|
||||||
|
capacity. As a result they cannot hold large entities.
|
||||||
|
|
||||||
|
A common theme in TPMs is the use of digests, and hash extension digests
|
||||||
|
in particular, as a stand-in for large entities that cannot exist at
|
||||||
|
once on the TPM.
|
||||||
|
|
||||||
|
We'll discuss at least two such large entities: event logs, and
|
||||||
|
policies.
|
||||||
|
|
||||||
## Platform Configuration Registers (PCRs)
|
## Platform Configuration Registers (PCRs)
|
||||||
|
|
||||||
A PCR, then, is just a hash extension output. The only operations on
|
A PCR, then, is just a hash extension output. The only operations on
|
||||||
|
@ -111,11 +123,8 @@ one must know the meaning of each such value.
|
||||||
Any TPM-using platform has to provide a way to keep a log of PCR hash
|
Any TPM-using platform has to provide a way to keep a log of PCR hash
|
||||||
extension values. Such a log is known as the "eventlog".
|
extension values. Such a log is known as the "eventlog".
|
||||||
|
|
||||||
The TPM itself cannot hold this log for the TPM is resource-constrained.
|
The TPM itself cannot hold this log -- the TPM is too
|
||||||
|
resource-constrained.
|
||||||
Indeed, hash extension is used by TPMs as a sort of a compression
|
|
||||||
function that represents a larger state that may not fit on the TPM.
|
|
||||||
PCRs are one case, and authorization policies are another.
|
|
||||||
|
|
||||||
## Root of Trust Measurements (RTM)
|
## Root of Trust Measurements (RTM)
|
||||||
|
|
||||||
|
@ -173,7 +182,7 @@ 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.
|
||||||
|
|
||||||
## 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
|
||||||
pointer-like "handles" that they are often used in the TPM APIs. But
|
pointer-like "handles" that they are often used in the TPM APIs. But
|
||||||
|
@ -246,6 +255,8 @@ trees of keys below the primary key:
|
||||||
...
|
...
|
||||||
```
|
```
|
||||||
|
|
||||||
|
Note that every key has a parent or is a primary key.
|
||||||
|
|
||||||
There are three built-in hierarchies:
|
There are three built-in hierarchies:
|
||||||
|
|
||||||
- platform hierarchy
|
- platform hierarchy
|
||||||
|
@ -263,23 +274,29 @@ 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 and Resource Management
|
## Key Wrapping
|
||||||
|
|
||||||
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 secret or private key is encrypted to a
|
because of _key wrapping_, where a secret or private key is encrypted to
|
||||||
TPM's EKpub so that it can be safely sent to that TPM so that that TPM
|
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.
|
can then decrypt and use that secret.
|
||||||
|
|
||||||
|
## Saving Resources Off-TPM
|
||||||
|
|
||||||
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
|
||||||
saving keys off the TPM. This is used for resource management: since
|
saving keys off the TPM.
|
||||||
hardware TPMs have very limited resources, objects need to created or
|
|
||||||
loaded, used, then saved off-TPM to make room for other objects to be
|
This is used for resource management: since hardware TPMs have very
|
||||||
loaded (unless they are not to be used again, then saving them is
|
limited resources, objects need to created or loaded, used, then saved
|
||||||
pointless). Only a TPM that saved an object can load it again, but some
|
off-TPM to make room for other objects to be loaded (unless they are not
|
||||||
objects can be exported to other TPMs by encrypting them to their
|
to be used again, then saving them is pointless). Only a TPM that saved
|
||||||
destination TPMs' EKpubs.
|
an object can load it again, but some objects can be exported to other
|
||||||
|
TPMs by encrypting them to their destination TPMs' EKpubs.
|
||||||
|
|
||||||
|
With a resource manager and access broker, a TPM can appear to have
|
||||||
|
infinite resources.
|
||||||
|
|
||||||
### Controlling Exportability of Keys
|
### Controlling Exportability of Keys
|
||||||
|
|
||||||
|
@ -355,14 +372,16 @@ always "compressed" to a hash digest.
|
||||||
|
|
||||||
It is the responsibility of the application that will attempt to use a
|
It is the responsibility of the application that will attempt to use a
|
||||||
policy-protected resource to know what the policy's definition is and
|
policy-protected resource to know what the policy's definition is and
|
||||||
restate it to the TPM when it goes to make use of that resource. Thus,
|
restate it to the TPM when it goes to make use of that resource. The
|
||||||
and because policies are `O(1)` in storage size, they can be arbitrarily
|
TPM will evaluate the policy and, at the end, check that its digest
|
||||||
more complex than a TPM's limited resources would otherwise allow.
|
matches that of the policy-protected resource. Thus, and because policy
|
||||||
|
digests are small and fixed-sized, they can be arbitrarily more complex
|
||||||
|
than a TPM's limited resources would otherwise allow.
|
||||||
|
|
||||||
All the policy commands that are to be evaluated successfully to grant
|
All the policy commands that are to be evaluated successfully to grant
|
||||||
access have to be known to the entity that wants that access. Of
|
access have to be known to the entity that wants that access. Of
|
||||||
course, that entity will have to satisfy -at access time- the conditions
|
course, that entity will have to satisfy -at access time- the conditions
|
||||||
expressed by the relevant policy. The application has to know the
|
expressed by the relevant policy. And that entity has to know the
|
||||||
policy because the TPM knows only a digest of it.
|
policy because the TPM knows only a digest of it.
|
||||||
|
|
||||||
### Policy Construction
|
### Policy Construction
|
||||||
|
@ -409,12 +428,11 @@ With all these features, and with all the flexibility allowed by NV
|
||||||
indexes, policies can be used to:
|
indexes, policies can be used to:
|
||||||
|
|
||||||
- require that N-of-M users authenticate
|
- require that N-of-M users authenticate
|
||||||
- enforce bank vault-like time of day restrictions
|
|
||||||
- require multi-factor authentication (password, biometric, smartcard)
|
- require multi-factor authentication (password, biometric, smartcard)
|
||||||
- check revocation
|
- enforce bank vault-like time of day restrictions
|
||||||
- check system RTM state
|
- check revocation (using NV index bit-field objects)
|
||||||
- distinguish user roles (admin roles get access to some resources,
|
- check system RTM state (PCRs)
|
||||||
user roles get access to other resources)
|
- distinguish user roles
|
||||||
|
|
||||||
## Sessions
|
## Sessions
|
||||||
|
|
||||||
|
@ -429,9 +447,9 @@ Cryptographic keys can either be unrestricted or restricted.
|
||||||
|
|
||||||
An unrestricted signing key can be used to sign arbitrary content.
|
An unrestricted signing key can be used to sign arbitrary content.
|
||||||
|
|
||||||
A restricted signing key can be used to sign only content that begins
|
A restricted signing key can be used to sign only TPM-generated content
|
||||||
with a magic byte sequence, and which the TPM allows only to be used in
|
as part of specific TPM restricted signing commands. Such content
|
||||||
certain operations.
|
always begins with a 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
|
||||||
|
@ -440,11 +458,17 @@ TPM-using application to get the plaintext if and only if (IFF) the
|
||||||
plaintext cryptographically names an object that the application has
|
plaintext cryptographically names an object that the application has
|
||||||
access to. This is used to communicate secrets ("credentials") to TPMs.
|
access to. This is used to communicate secrets ("credentials") to TPMs.
|
||||||
|
|
||||||
|
There is also a notion of signing keys that can only be used to sign
|
||||||
|
PKIX certificates.
|
||||||
|
|
||||||
## Attestation
|
## Attestation
|
||||||
|
|
||||||
Attestation is the process of demonstrating that a system's current
|
Attestation is the process of demonstrating that a system's current
|
||||||
state is "trusted", or the truthfulness of some set of assertions.
|
state is "trusted", or the truthfulness of some set of assertions.
|
||||||
|
|
||||||
|
Often a system gets something in exchange for attesting to its current
|
||||||
|
state. E.g., keys for unlocking filesystems, or device credentials.
|
||||||
|
|
||||||
As you can see in our [tutorial on attestation](Attestation/README.md),
|
As you can see in our [tutorial on attestation](Attestation/README.md),
|
||||||
many TPM concepts can be used to great effect:
|
many TPM concepts can be used to great effect:
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue