List of Figures

List of Tables

Acknowledgements

The Contributors of this Specification would like to acknowledge the following:

• Fabrizio D Amato (AMD)
• Steven Bellock (NVIDIA)
• Jeff Andersen (Google)
• Brett Henning (Broadcom)

Terminology

• PKI: Public-key infrastructure. Consists of a root key that is trusted by relying parties and infrastructure that manages the issuing of certificates.
• PKI owner: An entity that owns a PKI and issues device identity certificates that chain back to that PKI’s root key.
• PKI anchor point: In the context of this specification, this is the key in a device’s internal identity key hierarchy for which a PKI owner issues an identity certificate.
• Certificate deactivation: In the context of this specification, this occurs when a device identity certificate subject key’s derivation input changes, which causes the identity keypair to change.

Introduction

In a data center environment, hardware roots of trust leverage device identity keys to attest to their current configuration. Verifiers ensure that the device emitting the attestation is authentic, before going on to evaluate the attested claims against a policy.

In a simple case, such as the one illustrated in Figure 1, a device ships with an identity keypair that is endorsed by the device vendor. Verifiers ensure that the key which signed a given attestation chains back to a known vendor PKI root key.

Note: see Appendix 2.1 for clarification on DICE terminology in this and later diagrams.

A separate PKI owner may elect to issue their own certificate for the device’s identity upon receipt of the device. This identity certificate chains back to the PKI owner’s root key, rather than the vendor’s. Verifiers can verify attestations against the PKI owner’s root key, rather than the vendor’s.

Figure 2 illustrates the case of a data center operator acting as a PKI owner and issuing a certificate for the device’s identity.

There are several reasons an operator may wish to issue their own identity certificate for devices in their possession:

Consistent attestation verification

An operator’s fleet may be heterogeneous, with devices from a number of different vendors, each with their own distinct PKI. By issuing an identity certificate for devices based on the operator’s PKI, attestation verification within the operator’s fleet can be rendered more consistent and simple, as attestation can rely on a single PKI root key.

Insulation from potential vendor PKI compromise

A verifier that relies on a vendor PKI root key is relying on the ongoing security of the vendor’s PKI. Figure 4 illustrates the risk of a vendor PKI compromise, and how that risk is mitigated by way of the operator’s PKI.

Note that the act of issuing an identity certificate via an operator PKI necessarily involves relying on the trustworthiness of the vendor’s PKI. This necessary trust in the vendor’s PKI is point-in-time and does not extend past the time at which the certificate was issued. In the event that a vendor PKI becomes compromised, verifiers that trust the operator’s PKI can continue to rely on attestations emitted from existing devices that have already been deployed to the operator’s fleet. Furthermore, during identity certificate issuance, an operator may be able to rely on other signals in addition to the vendor’s PKI to establish the authenticity of devices. See Section 1.4 for more details.

Insulation from potential supply-chain compromise

Devices often support a hierarchy of identity keys, derived from a number of inputs. Figure 5 illustrates how identity keys are derived in Caliptra [1]. Other devices may have different identity layering schemes.

In Caliptra, the LDevID keypair is derived not only from UDS, but also field entropy, which is typically held in fuses and may be programmed into the device upon initial ingestion. By choosing the LDevID keypair as the PKI anchor point for the operator’s device identity certificate, the operator insulates themselves from supply-chain attackers that may have invasively exfiltrated the device’s UDS. See the Caliptra specification for additional commentary on the utility of LDevID and field entropy.

Implicit attestation

The PKI owner may select various keys in the identity hierarchy for which to issue a certificate. Each key will have different measurements contribute to that key’s derivation. By issuing a device identity certificate for a given key, the PKI owner is implicitly blessing the measurements which contribute to that key’s derivation. Any attestations endorsed via that identity certificate carry implicit assurance that the measurements which contribute to that identity key are the same as when the identity certificate was issued.

Consider the case of a data center operator that deploys a device, and a tenant that leases the device. This arrangement is illustrated in Figure 6.

In this example, a device wielding an identity key endorsed by the tenant-issued identity certificate implicitly attests that its owner configuration and FMC hash are the same as was present on the device when the tenant issued the identity certificate. The certificate will be implicitly deactivated if the owner configuration or FMC hash change.

Note: “certificate deactivation” is not the same as certificate revocation or expiration. A certificate that was deactivated by virtue of an identity key derivation input changing will become re-activated if that input reverts to its prior value. PKI owners wishing to permanently revoke an identity certificate must therefore use a separate mechansim, such as a CRL.

Each PKI owner may have their own desired implicit attestation properties, and can select their PKI anchor point accordingly.

Support for multiple PKI owners

A device may have multiple simultaneous PKI owners, and serve attestations to multiple verifiers, each with their own configured PKI root key.

While each identity certificate issued by a given PKI owner could be distributed to the relevant attestation verifiers through a number of means, the most tractable method in many cases is for the device to cache each of its PKI owner’s identity certificates locally, and serve a selected identity certificate along with each attestation statement. Each attestation requester must be able to request a PKI anchor point on a per-attestation-request basis.

Note: there may be intermediate certificates between a given PKI owner’s root key and the identity certificate issued for a device. This specification does not impose an upper-limit on the number of intermediate certificates that may exist for a given PKI owner. Devices typically have limited internal storage capacity. As a result, this specification does not require that the device’s attestation responses include any intermediate certificates beyond the identity certificate issued by a PKI owner. These intermediate certificates should be communicated to the verifier out-of-band. Such communication is outside the scope of this specification.

Specification scope

This specification describes the following aspects of device identity endorsement and provisioning:

• Discovering the set of identity keypairs supported by a device, along with each keypair’s respective derivation inputs.
• Establishing trust in a selected identity keypair from the device.
• Issuing and provisioning an identity certificate to the device.
• Requesting a given identity certificate when obtaining an attestation statement from the device.

The following items are out of scope:

• Certificate revocation
• General attestation verification

Discovering device identity keypairs

TODO: fill in

Establishing trust in a selected identity keypair

To allow a remote party to establish trust in a selected keypair, the device can emit a Certification Signing Request (CSR) [2]. This is supported in SPDM 1.3 [3] via the GET_CSR command. However, there is a drawback to GET_CSR as it is currently defined: the CSR is signed only by the subject key, and does not include a way to attest that the CSR was emitted from a given device.

To allow a device to attest that a given key is trustworthy, the device should issue its own signature over the public key, which can include a freshness nonce and additional metadata, such as the key’s derivation attribute OIDs.

The CSR is included as a claim in an Entity Attestation Token (EAT) [4].

Metadata such as the key’s derivation attribute OIDs can also be embedded in a CoRIM. The mechanism for this is out of scope of this specification.

Some devices may not support the generation of self-signed CSRs for certain keys in their identity key hierarchy, such as LDevID. To support such devices, this specification defines a “non-self-signed CSR”, which includes the subject public key but an all-zeroes signature field. The non-self-signed CSR is still itself signed, by way of the EAT.

This specification provides a definition for a vendor-defined SPDM command, utilizing VENDOR_DEFINED_REQUEST from SPDM 1.3, which can be used to surface these envelope-signed CSRs.

GET_ENVELOPE_SIGNED_CSR request and ENVELOPE_SIGNED_CSR response messages are transported as follows:

• The Requester must use the SPDM VENDOR_DEFINED_REQUEST format
• The Responder must use the SPDM VENDOR_DEFINED_RESPONSE format
• The StandardID field of VENDOR_DEFINED_REQUEST and VENDOR_DEFINED_RESPONSE message must contain 4 (the value assigned in SPDM to identify IANA).
• The VendorID field of VENDOR_DEFINED_REQUEST and VENDOR_DEFINED_RESPONSE message must contain 42623 (the value assigned in IANA to identify Open Compute Project).
• The first byte of the VendorDefinedReqPayload/VendorDefinedRespPayload is the Command Code, and must contain the value 01h to indicate GET_ENVELOPE_SIGNED_CSR / ENVELOPE_SIGNED_CSR.
• The GET_ENVELOPE_SIGNED_CSR request and ENVELOPE_SIGNED_CSR response forms the payload in the VendorDefinedReqPayload and VendorDefinedRespPayload respectively, defined in Tables 1 and 2.

The following fields should be treated identically as in GET_CSR from SPDM 1.3:

• Param1
• Param2
• RequesterInfoLength
• OpaqueDataLength
• RequesterInfo
• OpaqueData

The following fields present in this command are not present in GET_CSR:

• SignerSlotIDParam - defines which key signs the CSR envelope.
• Nonce - provides freshness.

The EnvelopeSignedCSRdata shall adhere to the following requirements:

• The payload SHALL be an EAT encoded as a CBOR Web Token (CWT) [5].
• The EAT SHALL conform to the OCP Envelope-Signed CSR EAT profile (see Section 1.4.1 for the defined OID).
• The EAT SHALL include standard claims for issuer identification and nonce for freshness verification.
• The EAT SHALL include private claims¹ containing:
  • The CSR as a byte string
  • An array of OIDs representing the key’s derivation attributes (see Section 1.4.1 for defined OIDs)
• The CSR included in the EAT SHALL be DER-encoded and may be either self-signed or non-self-signed depending on device capabilities. For non-self-signed CSRs, the signature field SHALL contain all zeroes and be the same size as would be required for a valid signature using the subject key’s algorithm.
• The nonce claim SHALL match the nonce value provided in the GET_ENVELOPE_SIGNED_CSR request to ensure freshness.
• If SignerSlotIDParam indicates a signed envelope, the CWT SHALL be signed by an Attestation Key endorsed by the certificate chain corresponding to the specified SlotID. In addition, the unprotected header of the CWT SHALL contain the Attestation Key’s certificate chain, including at least all certificates from the Attestation Key up to the identity certificate issued by the slot’s PKI owner.
  • E.g., Slot 0’s certificate chain would extend at least to the vendor-endorsed certificate over IDevID. A separate slot’s certificate chain would extend at least to the certificate issued by the slot’s configured PKI owner.
  • A device may report intermediate certificates for the slot’s PKI owner if it is configured to do so.

Defined OIDs

OCP Security Branch: ocp-security OBJECT IDENTIFIER ::= {1 3 6 1 4 1 42623 1}

Envelope-signed EAT profile OID: ocp-security-dip-eat-profile OBJECT IDENTIFIER ::= {ocp-security 1}

Key Derivation Attribute OID Branch: ocp-security-dip-kda OBJECT IDENTIFIER ::= {ocp-security 2}

The following OIDs are defined for key derivation attributes:

• Derived from Owner Entropy Fuse: ocp-security-dip-kda-OwnerEntropyFuse ::= {ocp-security-dip-kda 1}
• Derived from First Mutable Code: ocp-security-dip-kda-FirstMutableCode ::= {ocp-security-dip-kda 2}
• Derived from Non-First Mutable Code: ocp-security-dip-kda-NonFirstMutableCode ::= {ocp-security-dip-kda 3}
• Derived from Owner Provisioned Key: ocp-security-dip-kda-OwnerProvisionedKey ::= {ocp-security-dip-kda 4}

These OIDs indicate which inputs contribute to the derivation of the identity key for which the CSR is being requested.

Subsequent versions of this specification may be expanded with additional key derivation attribute OIDs.

Issuing and provisioning an identity certificate

This will be accomplished via the SET_CERTIFICATE SPDM command.

TODO: fill in additional details.

Requesting an identity certificate during attestation

This will be accomplished by selecting the correct SlotIDParam when invoking SPDM commands.

TODO: fill in additional details.

Confidential compute considerations

TODO: fill in

Appendix

Clarification of DICE Terminology

In this specification, several example device identity key hierarchies use the term “FMC”. In this context, FMC stands for “First Mutable Code”.

In TCG’s DICE Hardware Requirements [6], FMC is defined as “First Measured Code”, and is “the code and/or configuration information that is executed and/or takes effect immediately following the Device Identifier Composition Engine”. First Measured Code is synonymous with Layer 0 in the DICE Layering Architecture [7].

The difference between First Measured Code and First Mutable Code is subtle but important. In Caliptra, the First Measured Code corresponds with the Caliptra ROM layer. As such, Caliptra’s Device ID or IDevID keypair is wielded by ROM, rather than Caliptra’s FMC.

Envelope-signed CSR EAT CDDL

cwt-envelope-signed-csr-eat = {  
  ; The EAT Profile for Envelope-Signed CSR OCP will register
  &(eat-profile : 265 ) => ~oid ; "1.3.6.1.4.1.42623.1" - note: `~` strips CBOR tag #6.111(oid) from `oid`

  ; Issuer claim is StringOrURI (tstr)
  &(iss : 1) => tstr

  ; Nonce claim is nonce-type = bstr .size (8..64)
  ? &(nonce : 10) => bstr
  
  ; Private Claims (they have to be < -65536 for rfc8392)
  
  ; CSR bytestring
  &(csr: -70001) => bstr

  ; Attribute List of OIDs
  &(attrib: -70002) => [+ $key-attributes-type]
}

$key-attributes-type = tagged-oid-type

signed-cwt = #6.18(COSE-Sign1-envelope-signed-csr)

COSE-Sign1-envelope-signed-csr = [
  protected: bstr .cbor protected-esc-header-map
  unprotected: unprotected-esc-header-map
  payload: bstr .cbor cwt-envelope-signed-csr-eat 
  signature: bstr
]

protected-esc-header-map {
  ; Well-defined header fields
  &(alg-id: 1) => int
  &(content-type: 3) => tstr / int
  &(issuer-key-id: 4) => bstr
  ; User-defined fields
  * cose-label => cose-value
}

unprotected-esc-header-map = {
  ? &(x5-chain: 33) => bstr / [ 2*certs: bstr ]
  * cose-label => cose-value
}

Envelope-signed CSR EAT example CDDL diag

signed-cwt / 18([
  / protected / <<{
    / alg-id / 1 : 7,
    / content-type / 3 : "application/eat+cbor",
    / kid / 4 : 'Example OCP Envelope-Signed CSR CWT'
  }>>,
/ unprotected / {/ x5-chain / 33 : h'59025630820252308201d9a003020102021431a4ef62e5244e4d952ea485976098090d5f242f300a06082a8648ce3d040303307b310b30090603550406130255533113301106035504080c0a43616c69666f726e69613116301406035504070c0d53616e204672616e636973636f311d301b060355040a0c144578616d706c65204f7267616e697a6174696f6e3120301e06035504030c174578616d706c652043575420456e646f7273656d656e74301e170d3235303231333139303230345a170d3236303231343139303230345a307b310b30090603550406130255533113301106035504080c0a43616c69666f726e69613116301406035504070c0d53616e204672616e636973636f311d301b060355040a0c144578616d706c65204f7267616e697a6174696f6e3120301e06035504030c174578616d706c652043575420456e646f7273656d656e743076301006072a8648ce3d020106052b8104002203620004fcd3fad48575addceee9638583aa7054f71a402f35993901923cc0ee9763b85b1e729c740331f4e91079559bce17d5c3b706748333faeb192120e32d815f88f7310ae05df55060f96fbdb2d0acb19e710d25ec27cfa8945fe5dda73332813feda31e301c301a0603551d1104133011820f7777772e6578616d706c652e636f6d300a06082a8648ce3d040303036700306402306e1166a8a3132d4a20e0200a26d1eba0937fec54fdb7547eb7c5ccca0370170853294cdd6b3a1eb0fe649f12446d8b17023071219daf2b7c1aa6f7727d053e1027309594fd8cab9f820fa89d8f88fc7e551c0d30781b12aea48b53fde200e6cf082b' },
/ payload / <<{
      / eat-profile / 265 : h'88378952',
      / iss / 1 : "RT Alias Key",
      / nonce / 10: h'AAAABBBBAAAABBBBAAAABBBB', 
      / csr / -70001 :  h'59025630820252308201d9a003020102021431a4e0',
      / attrib / -70002: [
      / tagged-oid-type / 111(h'6086480186F84D010F046301')
      ]
  }>>,
  / signature / h'FA45AAB345AB4988' 
])

References