[lamps] Attestation Design Team Notes

[Michael StJohns <[e-mail]>]

The team met via Teams on Monday with about a dozen attendees. Primary 
discussion was the content of an attestation (specifically not a 
format).  Working from my initial list - we walked first through the 
overall list of attestation components - specifically the fields if you 
will that would be signed by the attestation private key.  We then 
walked through a list of proposed key attributes.  In the list below 
items marked with (???) were mentioned, but mostly didn't get a lot of 
love.

In the attestation components section we were pretty much agreed on the 
first three items being required.  There was a healthy discussion about 
clock time vs relative time and the relative merits and limitations of 
each.   Basically relative time provides ordering of attestations from a 
single source and is pretty easy to implement within an HSM, while clock 
time gives more information, but is mostly not verifiable by the relying 
party without things like third party time stamps.

Items were added, deleted and moved during the session.  Please take a 
look, and see if this list meets your needs.  If not, propose a change, 
or your own list.

The field marked with a (?) was discussed, but needs more discussion to 
resolve (e.g. whether - like the TPM - we include the attributes of the 
attesting key under the signed attestation).


++ Attestation Components
 > Mandatory Components
   >> Attested Key and Attributes
   >> Signature
   >> External Data

 > Possible Mandatory (?)
   >> Attesting Key and Attributes

 > Optional
   >> Relative Time – Boot count and boot time

 > Others?
   >> Clock Time (???)
   >> Platform Health (??? - maybe different type of attest)

The list of key attributeshas four sub groups:  How was the key 
created?  How is it protected (e.g. extractable or not or with caveats)? 
Its usages (as enforced by the HSM,  and Its maximum lifecycle (does it 
have a fixed lifetime, can it be deleted, does it last past a user 
session, etc).

++ Key Attributes
 > Source/Creation (enum)
   >> Loaded
   >> Device Derived  (e.g. Derived from a device permanent
                      master secret such as a TPM hierarchy seed)
   >> Generated on Device
   >> Key Agreement (???) (Derived from a key agreement)
   >> Co-Generated (???) (Securely cogenerated on more than one machine)
   >> KDF (???) (Derived from a master secret which was in turn derived 
from a two - or greater -  party protocol).

 > Protection (enum - ordered from least to most protected)
   >> Unknown
   >> None/Software
   >> Extractable/Migratable (by the user)
   >> Extractable for Backup (encrypted under a key migratable to 
another HSM)
   >> Extractable for Storage (encrypted under a PUF, not migratable)
   >> Non Extractable

 > Usage (bit set) - HSM enforced, NOT end user usage.
   >> Attestation
   >> General Signing
   >> Key Agreement
   >> Key Encapsulation
   >> Encryption/Decryption
   >> Certificate/CSR Signing (???)

 > Persistence/Lifetime (enum)
   >> Unknown
   >> Ephemeral – single use
   >> Session (see PKCS11)
   >> Boot Cycle - (HSM boot cycle - RAM resident basically)
   >> Timed (???) - HSM enforced key lifetimes
      >>> Minute (> minute < hour)
      >>> Hour (>= hour < day )
      >>> Day (etc)
      >>> Week
      >>> Month
      >>> Year
   >> Persistent (flash/NVRam - user deletable)
   >> Permanent (flash/NVRam - admin/SO deletable, not deletable by user)
   >> Fixed – Device Clear
   >> Fixed – Physical (e.g Terminate)

 > Signing Policies (???) - basically proprietary extensions
   >> OIDs (???)

Michael R - do you have any other notes to share?

Mike