fmaury/tpm.dev.tutorials
1
0
Fork 0
mirror of https://github.com/tpm2dev/tpm.dev.tutorials.git synced 2024-11-22 05:52:11 +00:00
Code Issues Projects Releases Packages Wiki Activity

Attestation: Add secrets storage options

Browse source
This commit is contained in:
Nicolas Williams 2021-05-18 17:20:49 -05:00
parent 3183bc537a
commit 98fb65d65b
1 changed files with 24 additions and 8 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

32
Attestation/README.md
View file

@ -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?