]> A CoRIM Profile for Arm's Confidential Computing Architecture (CCA) Endorsements Arm Ltd
yogesh.deshpande@arm.com
Linaro
thomas.fossati@linaro.org
Security RATS Arm Confidential Computing Architecture (CCA) Endorsements comprise reference values and cryptographic key material that a Verifier needs to appraise Attestation Evidence produced by an Arm CCA system. This memo defines CCA Endorsements as a profile of the CoRIM data model. Discussion Venues Source for this draft and an issue tracker can be found at .
Introduction Arm Confidential Computing Architecture (CCA) Endorsements comprise reference values and cryptographic key material that a Verifier needs to appraise Attestation Evidence produced by an Arm CCA system . This memo defines CCA Endorsements as a profile of the CoRIM data model .
Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The reader is assumed to be familiar with the terms and concepts introduced in and in .
Arm CCA Endorsements The Arm CCA Attester is a layered Attester comprising separate yet linked Platform and Realm Attesters. For the details, see . Appraising Arm CCA Evidence requires Endorsements for both the Platform and Realm. This document outlines the Platform and Realm Endorsements in and , respectively.
Arm CCA Platform Endorsements There are two types of CCA Platform Endorsements:
  • Reference Values (), i.e., measurements of the CCA Platform firmware.
  • Attestation Verification Keys (), i.e., cryptographic keys that can be used to verify Evidence produced by the CCA Platform, along with the identifiers that link the keys to their platform instances.
Arm CCA Platform Endorsement Profile Arm CCA Platform Endorsements are carried in one or more CoMIDs within a CoRIM. The profile attribute in the CoRIM MUST be present and MUST be the URI tag:arm.com,2025:cca_platform#1.0.0, as shown in .
CoRIM profile for CCA Platform Endorsements version 1.0.0
Arm CCA Platform Endorsements linkage to CCA Platform Each CCA Platform Endorsement, be it a Reference Value or an Attestation Verification Key, is associated with a unique identifier known as CCA Platform Implementation ID (see ). The Implementation ID uniquely identifies a given implementation of a CCA Platform and it is used by the Endorser or Reference Value Provider as an anchor to which Reference Values and Attestation Verification Keys for a CCA Platform are linked. To encode an Implementation ID, the tagged-bytes variant of the $class-id-type-choice is used, as described in . The length of the byte string MUST be exactly 32.
CCA Platform Implementation ID encoding
Besides, a CCA Endorsement can be associated with a specific instance of a certain CCA Platform implementation - as is the case of Attestation Verification Keys. The Instance ID (see ) provides a unique identifier for a given CCA Platform instance. To encode an Instance ID, the tagged-ueid-type variant of the $instance-id-type-choice is used, as described in . The first byte MUST be 0x01 (RAND) followed by the 32-byte unique instance identifier.
CCA Platform Instance ID encoding
CCA Attestation Verification Keys are associated with a CCA Platform instance by means of the Instance ID and the corresponding Implementation ID. These identifiers are typically found in the subject of a CoMID triple, encoded in an environment-map as shown in .
Example CCA Platform Identification
Together, they are interpreted as a unique identifier of the CCA Platform.
Reference Values Reference Values carry measurements and other metadata associated with the updatable firmware of the CCA Platform. CCA Platform is a collective term used to identify all the hardware and firmware components that comprise a CCA system. Specifically these include the following:
  • CCA system security domain
  • Monitor security domain
  • Realm Management Security domain
When appraising Evidence, the Verifier compares Reference Values against:
  • The values found in the Software Components of the CCA Platform token (see ).
  • The value set in the platform configuration of the CCA Platform token (see ).
Each measurement is encoded in a measurement-map of a CoMID reference-triple-record. Since a measurement-map can encode one or more measurements, a single reference-triple-record can carry as many measurements as needed, provided they belong to the same CCA Platform identified in the subject of the triple. A single reference-triple-record MUST completely describe the CCA Platform measurements.
CCA Platform Software Components Each CCA Platform software component (called arm-platform-sw-component in ) is encoded in a measurement-values-map as defined in .
CCA Platform Software Component encoding cca-swcomp-version-map &(digests: 2) => cca-swcomp-digests-type ? &(name: 11) => cca-swcomp-name &(cryptokeys: 13) => [ cca-swcomp-signer-id ] } cca-swcomp-version-map = { &(version: 0) => text } cca-swcomp-digests-type = [ + cca-digest ] cca-digest = [ alg: text val: cca-hash-type ] cca-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64 cca-swcomp-name = text cca-swcomp-signer-id = #6.560(cca-hash-type) ]]>
version (key 0):
A version-map with its version field containing the version (key 4) of the arm-platform-sw-component. The version-scheme field of the version-map MUST NOT be present. This field is optional.
digests (key 2):
Each array element encodes the "measurement value" (key 2) and "hash algorithm identifier" (key 6) of the arm-platform-sw-component in the val and alg entries, respectively. The alg entry MUST use the text encoding. The digests array MUST contain at least one entry and MAY contain more than one entry if multiple digests (obtained with different hash algorithms) of the same measured component exist. If multiple entries exist, they MUST have different alg values. This field is mandatory.
name (key 11):
A text value containing the "component type" (key 1) of the arm-platform-sw-component. This field is optional.
cryptokeys (key 13):
An array with only one entry using the tagged-bytes variant of the $crypto-key-type-choice. The entry contains the "signer id" (key 5) of the arm-platform-sw-component. This field is mandatory.
Each measurement-values-map for a CCA Platform software component is wrapped in a measurement-map with an mkey using the text variant of the $measured-element-type-choice. The value of the mkey MUST be "cca.software-component". The authorized-by field of the measurement-map MUST NOT be present. Find the related CDDL definitions in .
CCA Platform Software Component measurement-map "cca.software-component" &(mval: 1) => cca-swcomp-measurement-values-map } ]]>
CCA Platform Configuration The CCA Platform configuration describes the set of chosen implementation options of the CCA Platform. For example, this may include a description of the level of physical memory protection provided. CCA Platform configuration is vendor-specific variable-length data. Only some of the data may be security-relevant. For these reasons, it is represented in a raw-value of the measurement-values-map, using the tagged-masked-raw-value variant of the $raw-values-type-choice. Refer to for the details about the comparison algorithm.
CCA Platform Configuration measurement-map cca-tagged-masked-raw-value } cca-config-tagged-masked-raw-value = #6.563([ value: bytes mask: bytes ]) ]]>
The measurement-values-map for a CCA Platform configuration is wrapped in a measurement-map with an mkey using the text variant of the $measured-element-type-choice. The value of the mkey MUST be "cca.platform-config". There MUST be only one measurement-map with mkey "cca.platform-config" in the triple. The authorized-by field of the measurement-map MUST NOT be present. Find the related CDDL definitions in .
CCA Platform Software Component measurement-map "cca.platform-config" &(mval: 1) => cca-config-measurement-values-map } ]]>
CoMID Example An example CoMID containing one Reference Values triple with the expected values for both software components and platform configuration is given in .
Example CCA Platform Reference Values
Attestation Verification Keys An Attestation Verification Key contains the public key associated with the CCA Platform Attestation Key (CPAK). When appraising Platform Evidence, the Verifier uses the Implementation ID and Instance ID claims found in the Platform Token to identify the key that it shall use to verify the signature on the CCA Platform token. This allows the Verifier to prove (or disprove) the Attester's claimed identity. Each verification key is provided with the corresponding CCA Platform Instance and Implementation IDs in an attest-key-triple-record. Specifically:
  • The Instance and Implementation IDs are encoded in the environment-map as described in ;
  • The CPAK public key uses the tagged-pkix-base64-key-type variant of the $crypto-key-type-choice.
The CPAK public key is a SubjectPublicKeyInfo using the encoding defined in . There MUST be only one key in an attest-key-triple-record. The example in shows the CCA Endorsement of type Attestation Verification Key carrying a secp256r1 EC public CPAK associated with Instance ID 4ca3...d296.
Example CCA Platform Attestation Verification Key
Arm CCA Realm Endorsements Arm CCA provides confidential computing environments, known as Realms, that enable application workloads requiring confidential execution to operate in isolation from the host hypervisor and any other concurrent workload. Arm CCA allows the initial and run-time state of a Realm to be attested (). Realm Endorsements consist of Reference Values (), which are measurements of the configuration and contents of a Realm at the time of its activation, along with measurements of the software operating within the Realm, which can be extended throughout the Realm's lifetime. Unlike the Platform, Realm Attestation Verification Key Endorsements are not necessary as the key material needed to verify the Realm Evidence is inline in the CCA Token ().
Realm Endorsements linkage to Realm Realms do not have explicit class or instance identifiers. However, the Realm Initial Measurement (RIM) is unique and stable enough to serve as an identifier for the Realm Target Environment. Therefore, this profile employs an environment map with a class identifier that uses the tagged bytes variant of the $class-id-type-choice to encode the RIM value ().
CCA Realm Identification
Arm CCA Realm Endorsement Profile Arm CCA Realm Endorsements are carried in a CoMID within a CoRIM. The profile attribute in the CoRIM MUST be present and MUST be the URI tag:arm.com,2025:cca_realm#1.0.0 as shown in .
CoRIM profile for CCA Realm endorsements version 1.0.0
Reference Values Reference Values carry measurements and other metadata associated with the CCA Realm. Realm Reference Values comprise:
  1. Realm Initial Measurements (RIM)
  2. Realm Extended Measurements (REMs)
  3. Realm Personalization Value (RPV)
All Realm Reference Values are carried in a reference-triple-record whose environment-map is as described in The triple includes as many measurement-maps as needed to fully describe the Realm. The measurement-map contents depend on the type of Reference Value. For all, the mkey uses the text variant of the $measured-element-type-choice. The value of the mkey MUST be "cca.rim" for the RIM measurement, "cca.rpv" for the RPV measurement, and "cca.rem0".."cca.rem3" for the REM measurements. The authorized-by field of the measurement-map MUST NOT be present. RIM and REMs are encoded as digests (key 2). RPV is encoded using a raw-value (key 4) using the tagged bytes variant of the $raw-value-type-choice. All the Realm Reference Values are optional except RIM, which is mandatory.
CoMID Example An example CoMID containing one Reference Values triple with the expected values for a Realm is given in .
CCA realm identifiers
Security Considerations TODO
IANA Considerations This document makes no requests to IANA.
Acknowledgements TODO
References Normative References Concise Reference Integrity Manifest Fraunhofer SIT Linaro arm Independent Huawei Technologies Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether or not to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format. Arm's Confidential Compute Architecture Reference Attestation Token Arm Limited Linaro Mediatek Inc The Arm Confidential Compute Architecture (CCA) is series of hardware and software innovations that enhance Arm’s support for Confidential Computing for large, compute-intensive workloads. Devices that implement CCA can produce attestation tokens as described in this memo, which are the basis for trustworthiness assessment of the Confidential Compute environment. This document specifies the CCA attestation token structure and semantics. The CCA attestation token is a profile of the Entity Attestation Token (EAT). This specification describes what claims are used in an attestation token generated by CCA compliant systems, how these claims get serialized to the wire, and how they are cryptographically protected. This informational document is published as an independent submission to improve interoperability with Arm's architecture. It is not a standard nor a product of the IETF. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] Textual Encodings of PKIX, PKCS, and CMS Structures This document describes and discusses the textual encodings of the Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography Standards (PKCS), and Cryptographic Message Syntax (CMS). The textual encodings are well-known, are implemented by several applications and libraries, and are widely deployed. This document articulates the de facto rules by which existing implementations operate and defines them so that future implementations can interoperate. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Remote ATtestation procedureS (RATS) Architecture In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. Learn the architecture - Introducing Arm Confidential Compute Architecture Arm
Contributors Arm Limited
Simon.Frost@arm.com
Arm Limited
Sergei.Trofimov@arm.com