Definition of Key Attestation

[hannestschofenig]

See this discussion: https://mailarchive.ietf.org/arch/msg/rats/aYeAOmAsqas4WomxImwXW8R63Mc/

[aj-stein-nist]

Given today's conversation, is the PKI Consortium definition I posted relevant, as a starting point, or must it be something specific to the LAMPS or RATS WGs in IETF?

Hat tip to @frumioj for this issue and cross-org visibility in https://github.com/pkic/remote-key-attestation/issues/22.

[nedmsmith]

Is this issue asking to do something? Assuming there is general agreement on a definition of key attestation. The salient part is whether or not an AE (cryptographic token) can assert properties of keys. The basic building block of such a statement are (a) naming the key in question (b) describing its properties.

The PKI Consortium suggests that the property that is most important is: "key pair was generated and is managed inside a hardware security module"

The entity making the claim, i.e. the "hardware security module" a.k.a., AE also needs to be named.

The statement semantics would be: HSM_A says KEY_X has the property "key pair was generated and is managed inside a hardware security module"

RATS Evidence might rely on a signed object such as JWT/CWT/CSR where the signing key speaks on behalf of the AE. The assumption is the AE (HSM) has been endorsed by a trustworthy entity (e.g., its vendor) usually in the form of an endorsement certificate issued by the vendor CA that identifies the AE. Typically, this is in the form of a device ID certificate where the device ID key is embedded in the AE at manufacturing time (or by a secure process) such that the HSM and HSM key are considered to be the same entity.

Since KEY_A is under the control of the HSM, the HSM key can sign statements about KEY_A. Such as: "key pair was generated and is managed inside the HSM_A hardware security module".

If the signed object is the CSR (as that is what's relevant to this I-D), then there needs to be a way to encode the identity of KEY_A (e.g., key-id) and the statement above. There are lots of ways to encode the statement, text string, OID, a single bit.

The lamps/csr-attestation I-D has focused on providing a way to include Evidence in a CSR but stops short of defining specific statements. For that, there is a RATS draft https://datatracker.ietf.org/doc/draft-ounsworth-rats-x509-evidence/

It seems this draft is the logical place to define an evidence statement for: HSM_A says KEY_X has the property "key pair was generated and is managed inside the HSM_A hardware security module"

Scanning this I-D it seems to have some building block "Claims" that could be used to construct the above statement. For example, the HSM might be given an OEMID, HWMODEL, HWVERSION etc. It might contain some firmware (SOFTWARE-COMPONENT) and it might have some operational characteristics (DBGSTAT). The HSM might be evaluated, such that an Endorser might want to assert (FIPS_CONF or CC_CONF).

However, these properties seem to describe the HSM and not the key. For example, there is not discussion on how to identify a key (key-id).

There is no attention to encoding the properties of a key.

There is no attention to how a device ID key (aka endorsement key) might be bound to an HSM such that it can "speak for" the objects the HSM controls (such as KEY_A).

A TPM (as a form of HSM) does have the above capabilities and https://datatracker.ietf.org/doc/draft-ietf-rats-yang-tpm-charra/ documents how that works for TPMs.

It seems draft-ounsworth-rats-x509-evidence could do a better job of describing key attestation by filling the gaps I've pointed out.

[ounsworth]

Given the word count of the RATS email thread and of Ned's comment here, I think that this LAMPS document is also not the correct place to attempt a formal definition of "attestation" or "key attestation".

Can we just say something hand-wavy?

[ounsworth]

NIST has a definition that is maybe sufficiently hand-wavy? https://csrc.nist.gov/glossary/term/attestation

[muhammad-usama-sardar]

NIST has a definition that is maybe sufficiently hand-wavy? https://csrc.nist.gov/glossary/term/attestation

Repeating from the meeting chat: NIST has 2 definitions. The first definition is the most relevant to the draft.

However, I do have concerns with the first definition. It does not necessarily have to be digital signatures and only measurements. Also note the glossary wrongly attributed the definition to NIST SP 1800-19B but actually it comes from Bartock et al., Trusted Geolocation in the Cloud: Proof of Concept Implementation, NISTIR 7904, 2015. For instance, there is local attestation which is based on MAC rather than digital signatures. And it needs freshness in addition to measurements.

[nedmsmith]

Also note the glossary wrongly attributed the definition to NIST SP 1800-19B but actually it comes from Bartock et al., Trusted Geolocation in the Cloud: Proof of Concept Implementation, NISTIR 7904, 2015.

The NISTIR7904 definition is highly TPM specific while the SP1800-19B definition is more generally applicable.

[nedmsmith]

In terms of this draft, the terminology might use "evidence" instead of "attestation" since the goal isn't to define attestation but to describe how to convey evidence. Using RFC9334 terminology, the target environment is a key (or at least a key contained in a TA). The Evidence supplied applies to the key object specifically.

[aj-stein-nist]

Also note the glossary wrongly attributed the definition to NIST SP 1800-19B but actually it comes from Bartock et al., Trusted Geolocation in the Cloud: Proof of Concept Implementation, NISTIR 7904, 2015.

The NISTIR7904 definition is highly TPM specific while the SP1800-19B definition is more generally applicable.

Since we are in pick and choose mode, the glossary retrieves from all documents registered, they are not official definitions how external consumers perceive them. For the record, the SP 1800 series is not for normative standards-based definitions like it seems, unlike FIPS and SP 800 series, are meant for demonstrations of technologies and howto guides. Too bad NISTIR 8320B doesn't define it explicitly, but NISTRs aren't meant for normative definitions either.

[muhammad-usama-sardar]

The NISTIR7904 definition is highly TPM specific while the SP1800-19B definition is more generally applicable.

That's actually not correct. SP1800-19B never defines attestation by itself. It just reproduced the definition from NISTIR7904 for the convenience of readers.

Appendix C in NIST SP 1800-19B (page 67) clearly states that:

All significant technical terms used within this document are defined in other key documents, particularly NISTIR 7904, Trusted Geolocation in the Cloud: Proof of Concept Implementation [1]. As a convenience to the reader, terms critical to understanding this volume are provided in this glossary.``

[muhammad-usama-sardar]

Since we are in pick and choose mode, the glossary retrieves from all documents registered, they are not official definitions how external consumers perceive them.

In any case, I think the glossary should point to the document that actually defines it rather than the one that just uses it.

[muhammad-usama-sardar]

@ounsworth Could you please add some concluding remarks? What view do editors take in the draft?