Re: [lamps] [EXTERNAL] Re: FW: PKIX Attestation - Strawman proposal for an attestation statement format for HSMs

[Michael StJohns <[e-mail]>]

On 4/27/2023 3:50 PM, Mike Ounsworth wrote:
> This is a good discussion. I feel like we're rooting out the definitional issues.
>
>> A certificate has as its target a large, unknown set of relying parties.
>> An attestation has as its target one entity for a specific purpose in a limited period of time.
> Why?
>
> Why can't the manufacture infra make an attestation about a device root key at manufacture time, and bundle it into the device? You're telling me that by definition that's not an "attestation" because its audience is not a single specific entity?

You're trying to make the definitions meet your goals and that's not 
working all that well.

The HSM manufacturing root key is ultimately self-signed.  And if 
they're doing it right was probably NOT generated on a single HSM, is 
backed up to the hilt and not much more about it can be said at the time 
it signs something than it was currently loaded to a particular HSM.

The HSM device key - either something like a TPM endorsement key (EK) 
for indirect enrollment or an attestation key (AK) for direct enrollment 
gets bound into a certificate signed by the HSM manufacturer root key.  
Any attributes set on this certificate are pretty much at the whim of 
the Root Key owner and aren't really "proof" as we normally think of 
it.  Ideally it's got markings that say something like "this key may be 
used to verify key attestations" or "this key may be used to enroll 
attestation keys" that are used by the relying party and are only as 
good as the trust in the root.  Any hardware statement (a key 
attestation statement of the EK or AK) is no more trustworthy than the 
general policy implied by the HSM manufacturers root cert policy.

I'd rather bind the key state of the attesting key into the attestation 
that goes along with the attested key in a CSR.  That tells me that - as 
long as I believe what the HSM manufacturer is telling me about the 
device root key (an EK or AK I guess) - then what I can glean from the 
key attestation relative to the state of the two keys was true at the 
time of attestation.

Key or Data Attestations are by their very nature over the state of the 
data at the time of the attestation.  They say nothing about what the 
state of the data  was prior to the attestation, and they can not by 
themselves make a claim of the state of the data even 5 minutes later.  
You might be able to infer from the attestation certificate chain that 
the manufacturer is saying "the state of the key as presented in the 
attestation statement will not change in a direction that is less secure 
than indicated in the attestation, however the continued existence of 
the key is not guaranteed" - but that really needs to be in the CPS for 
the HSM manufacturer's device signing hierarchy documents.


>
>
> You're using terms like "EK" and "AK" without defining them, which is 1) not helping my confusion, and 2) it feels like you already have a solution in mind and are forcing the requirements discussion to fit your solution.

I did say "TPM Endorsement Key" and then shorten it to EK.  I'd been 
using Attestation Key and AK interchangeably.   AIK (Attestation 
Identity Key) is a TPM-centric name for a post-deployment generated and 
enrolled attestation key.

I also suggested folk read about the TPM DAA model to understand one way 
of enrolling an attestation key for attestation that was privacy 
preserving, and didn't require the AK to be certified by the HSM vendor.

I actually expect that at least initially, an HSM will have device-wide 
attestation key pair that can be used by any one, that that attestation 
key pair will be bound into a certificate either signed by the HSM 
manufacturing root of trust (which may be different than the firmware 
root of trust for example), or by an intermediate CA under that root of 
trust.  That's would require less infrastructure to start this process.

Ultimately, I would expect that HSMs *might* add a TPM-like key pair and 
certificate chain to allow for enrollment of attestation keys via a 
privacy preserving protocol such as DAA.

In either case, the key attestation statement will be signed by a 
private key, locked to the HSM, and usable only to sign very 
specifically formatted attestation statements, internally originated in 
the HSM.


Later, Mike

>
>
> To people who aren't Mike or Michael: is this discussion useful, or just a waste of space? If I'm the only one who is confused and for everyone else this is super clear, then I'm happy to back out.
>
> ---
> Mike Ounsworth
>
> -----Original Message-----
> From: Michael StJohns <[e-mail]>
> Sent: Thursday, April 27, 2023 2:07 PM
> To: Mike Ounsworth <[e-mail]>; Michael Richardson <[e-mail]>; Christopher Meyer <[e-mail]>; JOHNSON Darren <[e-mail]>; Jethro Beekman <[e-mail]>; Chris Trufan <[e-mail]>; Russ Housley <[e-mail]>; Richard Kettlewell <[e-mail]>; Bruno Couillard <[e-mail]>; Jean-Pierre Fiset <[e-mail]>; Sander Temme <[e-mail]>; Rózsahegyi, Zsolt <[e-mail]>; Ferenc Pető <[e-mail]>; Mike Agrenius Kushner <[e-mail]>; Dieter Bong <[e-mail]>; Herman Slatman <[e-mail]>; Corey Bonnell <[e-mail]>; Carl Wallace <[e-mail]>; AMADOR Eric <[e-mail]>; tirumal reddy <[e-mail]>; Tomofumi Okubo <[e-mail]>; Uri Blumenthal <[e-mail]>; John Gray <[e-mail]>; Bruce Morton <[e-mail]>; Thomas Fossati <[e-mail]>; Tomas Gustavsson <[e-mail]>
> Cc: 'LAMPS' <[e-mail]>
> Subject: Re: [EXTERNAL] Re: FW: PKIX Attestation - Strawman proposal for an attestation statement format for HSMs
>
> On 4/27/2023 10:00 AM, Mike Ounsworth wrote:
>> As MCR suggests, I'm including the LAMPS list for public archival purposes.
>>
>> TL;DR: both Michaels seem adamant that "attestation chain certificates" are conceptually different from "attestation statements", but the keys in the chain are themselves just keys that may need to be reasoned about and proved, so why can I not think of their certificate as itself being an attestation?
> For the same reason you don't think of an S/Mime message as a certificate or vice versa.  Both are cryptographically signed objects, both "attest" to something or another, but the form of the objects follow function.
>
> A certificate (in our common usage) is a signed binding between a name and a public key with some additional mixins both in the body and in the extensions.
>
> An attestation (at least as we're trying to use the word) is a signed statement of the internal state of an HSM with respect to certain data at a certain point in time.
>
> A certificate has as its target a large, unknown set of relying parties.
>
> An attestation has as its target one entity for a specific purpose in a limited period of time.
>
> While you could express an attestation in the form of a certificate, why would you?  As mentioned at least three times previously, the only relevant X.509 certificate fields for the purpose of attestation are the subject public key, the extensions and the signature.  It may look like a certificate, but it certainly shouldn't be relied upon as being a certificate by normal relying parties.
>
>>
>> Consider this collection of keys that (I think?) comprises a valid -- I don't know what the right words are so I'll call it an "attestation turtle stack".
> Chain of trust usually.  Turtle stack implies infinite recursion.
>> manufactureTA, manufactureCA, deviceRootKey, devicePartitionKey, codeSigningKey.
>>
>> Let's say we cryptographically link them together in the following way:
>>
>> (0) manufactureTA --signs--> (1) x509Cert(manufactureCA} --signs--> (2) x509Cert{deviceRootKey} --signs--> (3)  x509Cert{devicePartitionKey} --signs--> (4) attstStmt{codeSigningKey}, where 'attstStmt' is some non-x509 ASN.1 object. Cool so far?
>>
>> I don't understand why the word "attestation" applies to object (4)
>> but not to objects (2) or (3)
> Because certificate (as used within the network community) is a more accurate and precise word for 1-3.
>
> One of the general definitions for certificate is "an official document attesting to a certain fact"; in our case a certificate attests to the binding of the name to the key.  If you wanted to be pedantic, what we're trying to build is a "key attestation statement" where a certificate would be an "identity attestation statement".
>
>> MSJ said:
>>     > While you could conflate "certify" with "attest", it's best we don't if we expect to make progress.
>>
>> MCR said:
>>     > Second, does this diagram from RFC9334, which is the RATS architecture help you?
>>     https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9334.html*dataflow__;Iw!!FJ-Y8qCqXTj2!Y64Iy8OpQThJjNi-B9uVf_qIApt-bwBCgMWdlBVdAmO5__FaSz9fR7ElZvt7GC085MUPdnqyVpaapmTFYFIYbw$
>>     > How about figures 5 and 6?
>>
>> Nope, those figures do not clarify why (4) is an "attestation" but (2) and (3) are not.
>> Say I'm trying to verify the authenticity of the device itself -- for example to verify its serial number and deviceRootKey for licensing purposes --, then why would object (2) x509Cert{deviceRootKey} not count as "Evidence" as per Figure 1?
>> Ergo isn't (2) x509Cert{deviceRootKey} serving as an attestation statement about deviceRootKey?
>>
>>
>> I don't understand why "attestation statements" and "attestation chain certificates" need to be thought about as separate and distinct things with separate and distinct structures. Why is it anathema to have a single piece of signed data that is BOTH itself an attestation statement about its own subject key AND it is part of the attestation "turtle stack" for attestation statements about other keys? Why can't it be both?
> Well, then the AK certificate would also need to be a CA certificate - and that would be a pain to get right.   As it stands, AK certificates, client certificates, email client certificates and server certificates are all generally issued as "end entity" certificate with the BasicConstraint extension either missing or tagged with cA == FALSE - basically encoded as an empty sequence.  If you expect the output of the attestation process to be a certificate, then the AK certificate needs to also be a CA certificate of some sort.
>
>> MSJ seems to have an assumption that attestation statements are short-lived and ephemeral. I could see that many attestation frameworks would want freshness and challenge-response nonces, and that would certainly exclude (2) x509Cert{deviceRootKey} from being considered an attestation statement. But why is freshness or ephemerality necessary for the general definition of "attestation"?
> Let's work on a specific example - the code signing key problem that brought us here.   The CA/BF wants not to issue code signing certificates unless the code signing key is adequately protected. That's its "price" or "requirement" for doing so.
>
> The CSR says "here is a public key, I can prove I own the private key associated with it, and I can further prove (assuming you trust the attestation chain information) that the private key is protected to the level required by the CA/BF.
>
> The certificate issued by a CA/BF member simply says, "I issued a code signing certificate to an entity known to me, and who has proved to me that the private key associated with the public key was protected to the level we required at the time the certificate was issued."
>
> The signed code says "I was signed by a key that the CA/BF considered appropriate at the time the certificate was issued and that the code signer considered valid at the time the code was signed"
>
> The relying party (an end device) at this point is going to verify the chain of trust on the CA/BF issued code signing certificate and mostly call it a day.
>
> Or do you expect this end device to also follow the chain of trust for an embedded attestation statement and basically redo all the work the CA/BF already did?   E.g. placing something like https://urldefense.com/v3/__https://trustedcomputinggroup.org/resource/infrastructure-work-group-subject-key-attestation-evidence-extension-version-1-0/__;!!FJ-Y8qCqXTj2!Y64Iy8OpQThJjNi-B9uVf_qIApt-bwBCgMWdlBVdAmO5__FaSz9fR7ElZvt7GC085MUPdnqyVpaapmQh8oU8Dw$
> in the CA/BF issued certificate?  AFAICT, that's not part of the current problem set.
>
> When the CA gets the CSR, it can verify a proof that the key was protected at some time before it received the CSR - that's all. It has to trust that a lot of things went right at that point, but it bases that trust on the chain of trust for the attestation key.  That's one of what - a half-dozen things the CA has to verify before it issues the key?  Key owned by known and valid entity, entity has agreed to the policies (contract wise), key is protected, CA was paid, proper use bits are requested and set in the certificate.
>
> Once the CA issues the cert, the attestation statement is obsolete ephemeral dross.  Binding the attestation statement into the certificate doesn't mean that the HSM will stand by it say 10 years later (or a minute latter, or even for a party not the CA), even if the certificate lasts that long.
>
>
>
>
>
>> ---
>> Mike Ounsworth
>>
>> -----Original Message-----
>> From: Michael StJohns <[e-mail]>
>> Sent: Wednesday, April 26, 2023 6:18 PM
>> To: Mike Ounsworth <[e-mail]>; Michael Richardson
>> <[e-mail]>; Christopher Meyer <[e-mail]>;
>> JOHNSON Darren <[e-mail]>; Jethro Beekman
>> <[e-mail]>; Chris Trufan <[e-mail]>; Russ
>> Housley <[e-mail]>; Richard Kettlewell
>> <[e-mail]>; Bruno Couillard
>> <[e-mail]>; Jean-Pierre Fiset <[e-mail]>; Sander
>> Temme <[e-mail]>; Rózsahegyi, Zsolt
>> <[e-mail]>; Ferenc Pető <[e-mail]>; Mike
>> Agrenius Kushner <[e-mail]>; Dieter Bong
>> <[e-mail]>; Herman Slatman <[e-mail]>;
>> Corey Bonnell <[e-mail]>; Carl Wallace
>> <[e-mail]>; AMADOR Eric
>> <[e-mail]>; tirumal reddy <[e-mail]>;
>> Tomofumi Okubo <[e-mail]>; Uri Blumenthal
>> <[e-mail]>; John Gray <[e-mail]>; Bruce Morton
>> <[e-mail]>; Thomas Fossati <[e-mail]>;
>> Tomas Gustavsson <[e-mail]>
>> Subject: Re: [EXTERNAL] Re: FW: PKIX Attestation - Strawman proposal
>> for an attestation statement format for HSMs
>>
>> On 4/26/2023 6:18 PM, Mike Ounsworth wrote:
>>> (Aside: this is where I struggle conceptually with a hard division
>>> between the "attestation statement" and the "attestation certificate
>>> chain"; is the manufacturing facility not attesting the device root
>>> key (via a certificate), who is then attesting the partition key (via
>>> a certificate), who is then attesting the end-use key (via an
>>> attestation statement, which might be a certificate)? At each of
>>> those levels don't you have attestation-y things to say about that
>>> key? So aren't the "attestation chain certificates" also themselves
>>> "attestation statements?  )
>> While you could conflate "certify" with "attest", it's best we don't if we expect to make progress.
>>
>> An attestation statement is about what a key (bound by policy) in the HSM has to say about other data (in this case a key) in the HSM.  By their nature, an HSM can't say anything meaningful about a certificate (or for that matter any other opaque data), especially one originated by a third party, so there is no reason to include that certificate under the HSMs attestation statement.   The most you could glean from a attestation signed certificate chain was "these signed objects existed at the same time i was doing this attestation".  It's hard to find that useful.  If you still want to bind the chain to the attestation, I'd recommend doing it as part of the "external data" hash input instead as that's where you really want to put things where the HSM has no real control over the content or use.
>>
>> A certificate has a statement that more closely tracks "A key and identity acceptable to the CA were presented to be bound together, and the CA did that binding along with expressing caveats for the use and acceptance of the key that the relying party may or may not honor"
>>
>> In the chain of certificates leading up to the attestation, you may have different markings on each link in the chain, each saying something important about that link.  Ideally, the last certificate says "the issuing CA was presented with this public key and enough evidence of the public key's bonafides that the CA marked the key as one that may be used to verify attestation statements of a particular form".  That certificate may or may not be the same as the HSM's identity certificate issued by the HSM manufacturer.  And the HSM identity certificate may not itself necessarily be marked to verify an attestation.
>>
>> I would expect an HSM manufacturer to create the equivalent of a TPM Endorsement Key pair and bind it into a certificate during the manufacturing process.  I would think that key and certificate would be required to persist even across a complete zeroize of the HSM.
>>
>> That EK could either be used directly to attest keys wherever within the HSM they reside, or as an ignition key to only attest/enroll per-user/token attestation keys for enrollment in Attestation Key certificates via a third party (e.g. the TPM DAA model).  In both of these the EK is a common asset which can be used by any party legitimately on the HSM with appropriate privileges.
>>
>> In the former model, you present the signed attestation statement along with the HSM certificate chain.  In the latter, you present the third party certificate chain for your AK.   In both, all you need to verify the attestation statement is a public key gleaned from one of those cert chains.
>>
>> Later, Mike
>>
>>
>>
>>
>>
>>
>> Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
>