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

Merge pull request #11 from nicowilliams/attestation

Browse source 
Attestation: Add secrets storage options
This commit is contained in:
Dimitar Tomov 2021-05-19 16:47:49 +03:00 committed by GitHub
commit e086641daf
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
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
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
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
@ -682,11 +682,13 @@ successful attestation:
- Store `TPM2_MakeCredential(EKpub, someObjectName, key0), Encrypt_key0(secrets)`.
In this mode the server sends the client the stored data, then client
gets to recreate `someObject` (possibly by loading a saved object) on
its TPM so that the corresponding call to `TPM2_ActivateCredential()`
can 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.
gets to recreate `someObject` (possibly by loading a saved object or
by re-creating it on the same non-NULL hierarchy from the same
primary seed using the same template and extra entropy) on its TPM so
that the corresponding call to `TPM2_ActivateCredential()` can
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
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
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
that is used as a policy PCR for unsealing a persistent object stored
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
unseal the real storage / filesystem decryption keys.
- A hybrid of the previous two options, where the server stores a
secret PCR extension value wrapped with `TPM2_MakeCredential()`.
Using a PCR and a policy on the key object allows for a clever
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?