mirror of
https://github.com/tpm2dev/tpm.dev.tutorials.git
synced 2024-11-10 01:12:10 +00:00
Merge pull request #11 from nicowilliams/attestation
Attestation: Add secrets storage options
This commit is contained in:
commit
e086641daf
1 changed files with 24 additions and 8 deletions
|
@ -667,7 +667,7 @@ key-encryption-keys to a client. But one might not want to store those
|
||||||
keys in the clear on the attestation server. As well, one might want a
|
keys in the clear on the attestation server. As well, one might want a
|
||||||
break-glass way to recover those secrets.
|
break-glass way to recover those secrets.
|
||||||
|
|
||||||
For break-glass recover, the simplest thing to do is to store
|
For break-glass recovery, the simplest thing to do is to store
|
||||||
`Encrypt_backupKey({EKpub, hostname, secrets})`, where `backupKey` is an
|
`Encrypt_backupKey({EKpub, hostname, secrets})`, where `backupKey` is an
|
||||||
asymmetric key whose private key is stored offline (e.g., in a safe, or
|
asymmetric key whose private key is stored offline (e.g., in a safe, or
|
||||||
in an offline HSM). To break the glass and recover the key, just bring
|
in an offline HSM). To break the glass and recover the key, just bring
|
||||||
|
@ -682,11 +682,13 @@ successful attestation:
|
||||||
- Store `TPM2_MakeCredential(EKpub, someObjectName, key0), Encrypt_key0(secrets)`.
|
- Store `TPM2_MakeCredential(EKpub, someObjectName, key0), Encrypt_key0(secrets)`.
|
||||||
|
|
||||||
In this mode the server sends the client the stored data, then client
|
In this mode the server sends the client the stored data, then client
|
||||||
gets to recreate `someObject` (possibly by loading a saved object) on
|
gets to recreate `someObject` (possibly by loading a saved object or
|
||||||
its TPM so that the corresponding call to `TPM2_ActivateCredential()`
|
by re-creating it on the same non-NULL hierarchy from the same
|
||||||
can succeed, then the client recovers `key0` and decrypts the
|
primary seed using the same template and extra entropy) on its TPM so
|
||||||
encrypted secrets. Here `someObject` can be trivial and need only
|
that the corresponding call to `TPM2_ActivateCredential()` can
|
||||||
exist to make the `{Make,Activate}Credential` machinery work.
|
succeed, then the client recovers `key0` and decrypts the encrypted
|
||||||
|
secrets. Here `someObject` can be trivial and need only exist to
|
||||||
|
make the `{Make,Activate}Credential` machinery work.
|
||||||
|
|
||||||
TPM replacement and/or migration of a host from one physical system
|
TPM replacement and/or migration of a host from one physical system
|
||||||
to another can be implemented by learning the new system's TPM's
|
to another can be implemented by learning the new system's TPM's
|
||||||
|
@ -694,6 +696,14 @@ successful attestation:
|
||||||
`TPM2_MakeCredential(EKpub_new, someObjectName, key0)` and update the
|
`TPM2_MakeCredential(EKpub_new, someObjectName, key0)` and update the
|
||||||
host's entry.
|
host's entry.
|
||||||
|
|
||||||
|
- Alternatively generate a non-restricted decryption private key using
|
||||||
|
a set template and extra entropy, on the same non-NULL hierarchy
|
||||||
|
(i.e., from the same seed), enroll the public key to this private key
|
||||||
|
in an attestation protocol, and have the attestation server store
|
||||||
|
secrets encrypted to that public key.
|
||||||
|
|
||||||
|
(The EK cannot be used this way because it is restricted.)
|
||||||
|
|
||||||
- Store a secret value that will be extended into an application PCR
|
- Store a secret value that will be extended into an application PCR
|
||||||
that is used as a policy PCR for unsealing a persistent object stored
|
that is used as a policy PCR for unsealing a persistent object stored
|
||||||
on the client's TPM.
|
on the client's TPM.
|
||||||
|
@ -702,8 +712,14 @@ successful attestation:
|
||||||
value, and the client uses it to extend a PCR such that it can then
|
value, and the client uses it to extend a PCR such that it can then
|
||||||
unseal the real storage / filesystem decryption keys.
|
unseal the real storage / filesystem decryption keys.
|
||||||
|
|
||||||
- A hybrid of the previous two options, where the server stores a
|
Using a PCR and a policy on the key object allows for a clever
|
||||||
secret PCR extension value wrapped with `TPM2_MakeCredential()`.
|
break-glass secret recovery mechanism by using a compound extended
|
||||||
|
authorization (EA) policy that allows either unsealing based on a
|
||||||
|
PCR, or maybe based on an password-based HMAC (with machine passwords
|
||||||
|
stored in a safe).
|
||||||
|
|
||||||
|
- A hybrid of the previous options, where the server stores a secret
|
||||||
|
PCR extension value wrapped with `TPM2_MakeCredential()`.
|
||||||
|
|
||||||
Other ideas?
|
Other ideas?
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue