RATS Y. Deshpande Internet-Draft Arm Ltd Intended status: Informational T. Fossati Expires: 6 January 2025 Linaro 5 July 2024 Arm's Confidential Computing Architecture (Arm CCA) Attestation Verifier Endorsements draft-ydb-rats-cca-endorsements-00 Abstract Arm Confidential Computing Architecture (CCA) Endorsements comprise of reference values and cryptographic key material that a Verifier needs in order to appraise Attestation Evidence produced by an Arm CCA system. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 January 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Deshpande & Fossati Expires 6 January 2025 [Page 1] Internet-Draft Arm CCA Endorsements July 2024 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 3. Arm CCA Endorsements . . . . . . . . . . . . . . . . . . . . 3 3.1. Arm CCA Platform Endorsements . . . . . . . . . . . . . . 3 3.1.1. Arm CCA Platform Endorsement Profile . . . . . . . . 3 3.1.2. Arm CCA Platform Endorsements linkage to CCA Platform . . . . . . . . . . . . . . . . . . . . . . 3 3.1.3. Reference Values . . . . . . . . . . . . . . . . . . 5 3.1.4. Attestation Verification Claims . . . . . . . . . . . 8 3.2. Arm CCA Realm Endorsements . . . . . . . . . . . . . . . 10 3.2.1. Realm Endorsements linkage to Realm . . . . . . . . . 11 3.2.2. Arm CCA Realm Endorsement Profile . . . . . . . . . . 12 3.2.3. Reference Values . . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5.1. CBOR Tag Registrations . . . . . . . . . . . . . . . . . 15 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . 16 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction Arm CCA Endorsements include reference values and cryptographic key material information that a Verifier needs in order to appraise attestation Evidence produced by a CCA System [CCA-TOKEN]. This memo defines such CCA Endorsements as a profile of the CoRIM data model [CoRIM]. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The reader is assumed to be familiar with the terms defined in Section A7.2.1 of [CCA-TOKEN] and in Section 4 of [RATS-ARCH]. Deshpande & Fossati Expires 6 January 2025 [Page 2] Internet-Draft Arm CCA Endorsements July 2024 3. Arm CCA Endorsements Arm CCA attestation scheme is a composite attestation scheme which comprises a CCA Platform Attestation & a Realm Attestation[CCA-ARCH]. Hence appraisal of Arm CCA attestation needs endorsements for both CCA Platform and CCA Realm. This draft documents both the CCA platform and realm endorsements. 3.1. Arm CCA Platform Endorsements There are two types of CCA Platform Endorsements: * Reference Values (Section 3.1.3), i.e., measurements of the CCA Platform firmware. * Attestation Verification Claims (Section 3.1.4), i.e., cryptographic keys that can be used to verify signed attestation token produced by the CCA platform, along with the identifiers that bind the keys to their platform instances. 3.1.1. Arm CCA Platform Endorsement Profile Arm CCA platform endorsements are carried in one or more CoMIDs inside a CoRIM. The profile attribute in the CoRIM MUST be present and MUST have a single entry set to the uri http://arm.com/cca/ssd/1 as shown in Figure 1. / corim-map / { / corim.profile / 3: [ 32("http://arm.com/cca/ssd/1") ] / ... / } Figure 1: CCA platform profile version 1, CoRIM profile 3.1.2. Arm CCA Platform Endorsements linkage to CCA Platform Each CCA Platform Endorsement - be it a Reference Value or Attestation Verification Claim is associated with a unique CCA platform identifier. A CCA platform identifier known as CCA Platform Implementation ID (see Section A7.2.3.2.3 of [CCA-TOKEN]) uniquely identifies a class of CCA platform to which the manufacturer/endorser links the supplied Endorsements (Reference Values & Attestation Verification Keys) for a CCA platform. Deshpande & Fossati Expires 6 January 2025 [Page 3] Internet-Draft Arm CCA Endorsements July 2024 In order to support CCA Implementation IDs, the CoMID type $class-id- type-choice is extended as follows Figure 2: cca-implementation-id-type = bytes .size 32 tagged-implementation-id-type = #6.600(implementation-id-type) $class-id-type-choice /= tagged-implementation-id-type Figure 2: Example CCA Platform Implementation ID Besides, a CCA Endorsement can be associated with a specific instance of a certain CCA Platform implementation - as is the case of Attestation Verification Claims. A CCA Attestation Verification Claims are associated with a CCA platform instance by means of the Instance ID (see Section A7.2.3.2.4 of [CCA-TOKEN]) and its platform Implementation ID. These identifiers are typically found in the subject of a CoMID triple, encoded in an environment-map as shown in Figure 3. / environment-map / { / comid.class / 0 : { / comid.class-id / 0 : / tagged-impl-id-type / 600( h'61636d652d696d706c656d656e746174 696f6e2d69642d303030303030303031' ), / comid.vendor / 1 : "ACME Ltd.", / comid.model / 2 : "Roadrunner 1.0" }, / comid.instance / 1 : / tagged-ueid-type / 550( h'01 4ca3e4f50bf248c39787020d68ffd05c 88767751bf2645ca923f57a98becd296' ) } Figure 3: Example CCA Platform Identification Optional vendor and model can be specified as well. Together, they are interpreted as a unique identifier of the CCA platform. Consistently providing a product identifier is RECOMMENDED. Deshpande & Fossati Expires 6 January 2025 [Page 4] Internet-Draft Arm CCA Endorsements July 2024 3.1.3. Reference Values Reference Values carry measurements and other metadata associated with the updatable firmware of CCA platform. The 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 Section A7.2.3.2.7 of [CCA-TOKEN]). * The value set in the platform configuration of the CCA platform token (see Section A7.2.3.2.5 of [CCA-TOKEN]). 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 "reference value" triple. A single reference-triple-record SHALL completely describe the CCA platform measurements. 3.1.3.1. CCA Platform Software Components For the Reference Values of CCA platform software components the identifier of a measured software component is encoded in a arm- swcomp-id object as follows Figure 4: arm-swcomp-id = { arm.measurement-type => text arm.version => text arm.signer-id => arm.hash-type } arm.hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64 arm.measurement-type = 1 arm.version = 4 arm.signer-id = 5 Deshpande & Fossati Expires 6 January 2025 [Page 5] Internet-Draft Arm CCA Endorsements July 2024 Figure 4: Example SW Component ID The semantics of the codepoints in the arm-swcomp-id map are equivalent to those in the cca-platform-sw-component map defined in Section A7.2.3.2.7 of [CCA-TOKEN]. The arm-swcomp-id MUST uniquely identify a given software component within the CCA platform / product. In order to support CCA Reference Value identifiers, the CoMID type $measured-element-type-choice is extended as followsFigure 5: tagged-arm-swcomp-id = #6.601(arm-swcomp-id) $measured-element-type-choice /= tagged-arm-swcomp-id Figure 5: Example SW Component ID Extension and automatically bound to the comid.mkey in the measurement-map. The raw measurement is encoded in a digests-type object in the measurement-values-map. The digests-type array MUST contain at least one entry. The digests-type array MAY contain more than one entry if multiple digests (obtained with different hash algorithms) of the same measured component exist. Refer below Figure 6. 3.1.3.2. CCA Platform Configuration A Reference value for CCA platform configuration describes the set of chosen implementation options of the CCA platform. As an example, these may include a description of the level of physical memory protection which is provided. CCA platform configuration reference value represent vendor specific variable length data. As a result, in the CCA platform CoRIM profile, it is represented in a measurement-values-map using raw- values set to tagged-bytes to express a variable length byte string, representing platform configuration data. $raw-value-type-choice /= tagged-bytes 3.1.3.3. Complete Representation The complete representation of CCA Platform Reference Values is given in Figure 6 & Figure 7. Deshpande & Fossati Expires 6 January 2025 [Page 6] Internet-Draft Arm CCA Endorsements July 2024 / concise-mid-tag / { / comid.tag-identity / 1 : { / comid.tag-id / 0 : h'3f06af63a93c11e4979700505690773f' }, / comid.triples / 4 : { / comid.reference-triples / 0 : [ [ / environment-map / { / comid.class / 0 : { / comid.class-id / 0 : / tagged-impl-id-type / 600( h'61636d652d696d706c656d656e746174 696f6e2d69642d303030303030303031' ), / comid.vendor / 1 : "ACME Ltd.", / comid.model / 2 : "Roadrunner 1.0" } }, [ / measurement-map / { / comid.mkey / 0 : 601({ / arm.measurement-type / 1 : "PRoT", / arm.version / 4 : "1.3.5", / arm.signer-id / 5 : h'acbb11c7e4da217205523ce4ce 1a245ae1a239ae3c6bfd9e7871 f7e5d8bae86b' }), / comid.mval / 1 : { / comid.digests / 2 : [ / hash-alg-id / 1, / sha256 / / hash-value / h'44aa336af4cb14a879432e53dd6571c7 fa9bccafb75f488259262d6ea3a4d91b' ] } } ] ] ] } } Figure 6: Example CCA SW Component Reference Value Deshpande & Fossati Expires 6 January 2025 [Page 7] Internet-Draft Arm CCA Endorsements July 2024 / concise-mid-tag / { / comid.tag-identity / 1 : { / comid.tag-id / 0 : h'3f06af63a93c11e4979700505690773f' }, / comid.triples / 4 : { / comid.reference-triples / 0 : [ [ / environment-map / { / comid.class / 0 : { / comid.class-id / 0 : / tagged-impl-id-type / 600( h'61636d652d696d706c656d656e746174 696f6e2d69642d303030303030303031' ), / comid.vendor / 1 : "ACME Ltd.", / comid.model / 2 : "Roadrunner 1.0" } }, [ / measurement-map / { / comid.mkey / 0 : 602({ / "cca.platform-config-id" / 1 : "any-value" }), / comid.mval / 1 : { / comid.raw-value / 4 : { / tagged-bytes / 560( h'67b28b6c39cc40a19117ab5b05911e37' ) } } } ] ] ] } } Figure 7: Example CCA Platform Configuration Reference Values 3.1.4. Attestation Verification Claims Attestation Verification Claim carries the verification key associated with the Initial Attestation Key (IAK) of a CCA platform. When appraising Evidence, the Verifier uses the Implementation ID and Instance ID claims (see Section 3.1.2) to retrieve the verification key that it SHALL use to check the signature on the CCA platform token. This allows the Verifier to prove (or disprove) the Attester's claimed identity. Deshpande & Fossati Expires 6 January 2025 [Page 8] Internet-Draft Arm CCA Endorsements July 2024 Each verification key is provided alongside the corresponding CCA platform Instance and Implementation IDs (and, possibly, a CCA platform product identifier) in an attest-key-triple-record. Specifically: * The Instance and Implementation IDs are encoded in the environment-map as shown in Figure 3 * The IAK public key is set using $crypto-key-type-choice set to tagged-pkix-base64-key-type. The IAK public key is a PEM-encoded SubjectPublicKeyInfo [RFC5280]. There MUST be only one key in an attest-key-triple-record; The example in Figure 8 shows the CCA Endorsement of type Attestation Verification Key carrying a secp256r1 EC public IAK associated with Instance ID 4ca3...d296. Deshpande & Fossati Expires 6 January 2025 [Page 9] Internet-Draft Arm CCA Endorsements July 2024 / concise-mid-tag / { / comid.tag-identity / 1 : { / comid.tag-id / 0 : h'3f06af63a93c11e4979700505690773f' }, / comid.triples / 4 : { / comid.attest-key-triples / 3 : [ [ / environment-map / { / comid.class / 0 : { / comid.class-id / 0 : / tagged-impl-id-type / 600( h'61636d652d696d706c656d656e746174 696f6e2d69642d303030303030303031' ), / comid.vendor / 1 : "ACME Ltd.", / comid.model / 2 : "Roadrunner 1.0" }, / comid.instance / 1 : / tagged-ueid-type / 550( h'01 4ca3e4f50bf248c39787020d68ffd05c 88767751bf2645ca923f57a98becd296' ) }, [ / tagged-pkix-base64-key-type / 554( "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgA ETl4iCZ47zrRbRG0TVf0dw7VFlHtv18HInY hnmMNybo+A1wuECyVqrDSmLt4QQzZPBECV8 ANHS5HgGCCSr7E/Lg==" ) ] ] ] } } Figure 8: Example CCA Platform Attestation Verification Key 3.2. Arm CCA Realm Endorsements Arm CCA Realm provides a protected execution environment for applications executing within a Realm. A Realm Endorsements comprise of: Deshpande & Fossati Expires 6 January 2025 [Page 10] Internet-Draft Arm CCA Endorsements July 2024 * Reference Values (Section 3.2.3), i.e., measurements of the configuration and contents of a Realm at the time of its activation along with measurements of software running inside Realm, which can be extended during the lifetime of a Realm. Please note that there are no Realm Trust Anchor Endorsements needed from supply chain as they are present inline in the Attestation Evidence. 3.2.1. Realm Endorsements linkage to Realm Each Realm has a unique execution context and hence a unique Realm instance. Each Realm is uniquely identified in the Arm CCA system. For a Realm its Endorsements are associated to this unique instance. The Realm instance is a vendor defined variable length identifier. Hence in this profile, it is represented in a CoMID inside an environment-map with $instance-id-type-choice set to tagged-bytes, i.e. an opaque, variable-length byte string. In this profile of CCA Endorsements, the Realm Initial Measurements are set in tagged-bytes to represent Realm instance. When supplying Realm Endorsements, a supplier of one or more Realms may wish to identify itself. Hence the following class related elements in the environment-map of a comid can be used. See Figure 9 In the class-map select vendor name and/or class-id set as UUID representing unique identity of the Realm owner. $class-id-type-choice /= tagged-uuid-type vendor => tstr to represent vendor name / environment-map / { / comid.class / 0 : { / comid.class-id / 0 : / tagged-uuid-type / 37( h'67b28b6c34cc40a19117ab5b05911e37' ), / comid.vendor / 1 : "Workload Client Ltd", }, / comid.instance / 1 : / tagged-bytes / 560( h'67b28b6c39cc40a19117ab5b05911e37' ) } Figure 9: CCA realm identifiers Deshpande & Fossati Expires 6 January 2025 [Page 11] Internet-Draft Arm CCA Endorsements July 2024 3.2.2. Arm CCA Realm Endorsement Profile Arm CCA Realm Endorsements are carried in a CoMID inside a CoRIM. The profile attribute in the CoRIM MUST be present and MUST have a single entry set to the uri http://arm.com/cca/realm/1 as shown in Figure 10. / corim-map / { / corim.profile / 3: [ 32("http://arm.com/cca/realm/1") ] / ... / } Figure 10: CCA realm profile version 1, CoRIM profile 3.2.3. Reference Values Reference Values carry measurements and other metadata associated with the CCA Realm. Realm reference values comprise of: 1. Realm Initial Measurements (RIM) 2. Realm Extended Measurements (REMs) 3. Realm Personalization Value (RPV) RIM and REMs are encoded in a measurement-values-map (in a measurement-map) of a CoMID reference-triple-record. Inside measurement-values-map these measurements are carried as integrity- registers map. Integrity Registers map is used to group together one or more measured objects pertaining to an environment. Please refer [CoRIM] for details about Integrity Register map. All the measured objects in an Integrity Registers map are explicitly named. In the context of Realms, the measured objects are RIM and REMs. Inside Integrity Register map, RIM is uniquely identified by the name "rim", while REMs which is an array of measurements from 1..4 are uniquely identified by the coresponding name "rem0".."rem3". Deshpande & Fossati Expires 6 January 2025 [Page 12] Internet-Draft Arm CCA Endorsements July 2024 Realm Personalization Value, (RPV) is an optional identity used by a Realm endorser to uniquely identify multiple Realms which all have the same RIM. RPV if provided is a fixed length 64 bytes identifier. In this profile, RPV is represented using Raw Value Measurements in a measurement-values-map, with raw value type choice set to tagged- bytes. See Figure 11 $raw-value-type-choice /= tagged-bytes Given below is the complete example of a Realm Endorsements. / concise-mid-tag / { / comid.tag-identity / 1 : { / comid.tag-id / 0 : h'3f06af63a93c11e4979700505690773f' }, / comid.triples / 4 : { / comid.reference-triples / 0 : [ [ / environment-map / { / comid.class / 0 : { / comid.class-id / 0 : / tagged-uuid-type / 37( h'67b28b6c34cc40a19117ab5b05911e37' ), / comid.vendor / 1 : "Workload Client Ltd" }, / comid.instance / 1 : / tagged-bytes / 560( h'67b28b6c39cc40a19117ab5b05911e37' ) }, [ / measurement-map / { / comid.mval / 1 : { / comid.raw-value / 4 : { / tagged-bytes / 560( h'ABABABABABABABABABABABABABABABABABABABABABABABABA BABABABABABABABABABABABABABABABABABABABABABABABAB ABABABABABABABABABABABABABABAB', ) }, / comid.integrity-registers / 14 : { "rim": [ [ / hash-alg-id / 1, / sha256 / / hash-value / h'44aa336af4cb14a879432e53dd6571c7 fa9bccafb75f488259262d6ea3a4d91b' ] Deshpande & Fossati Expires 6 January 2025 [Page 13] Internet-Draft Arm CCA Endorsements July 2024 ], "rem0": [ [ / hash-alg-id / 1, / sha256 / / hash-value / h'50aa341af9cb20a879440e58dd6581c1 4fa14bccafb75f488259262d6ea3a4d9' ] ], "rem1": [ [ / hash-alg-id / 1, / sha256 / / hash-value / h'50aa341af9cb20a879440e59dd6581c1 4fa14bccafb75f488259262d6ea3a4d9' ] ], "rem2": [ [ / hash-alg-id / 1, / sha256 / / hash-value / h'50aa341af9cb20a879440e5add6581c1 4fa14bccafb75f488259262d6ea3a4d9' ] ], "rem3": [ [ / hash-alg-id / 1, / sha256 / / hash-value / h'50aa341af9cb20a879440e5bdd6581c1 4fa14bccafb75f488259262d6ea3a4d9' ] ] } } } ] ] ] } } Figure 11: CCA realm identifiers 4. Security Considerations // TODO Deshpande & Fossati Expires 6 January 2025 [Page 14] Internet-Draft Arm CCA Endorsements July 2024 5. IANA Considerations 5.1. CBOR Tag Registrations IANA is requested to allocate the following tags in the "CBOR Tags" registry [IANA.cbor-tags], preferably with the specified value: +=====+==============+===================================+ | Tag | Data Item | Semantics | +=====+==============+===================================+ | 600 | tagged bytes | CCA Implementation ID | | | | (Section 3.1.2 of RFCTHIS) | +-----+--------------+-----------------------------------+ | 601 | tagged map | CCA Software Component Identifier | | | | (Section 3.1.3 of RFCTHIS) | +-----+--------------+-----------------------------------+ Table 1: CoRIM CBOR Tags 6. Acknowledgements // TODO 7. References 7.1. Normative References [CCA-ARCH] Arm, "Learn the architecture - Introducing Arm Confidential Compute Architecture", May 2023, . [CoRIM] Birkholz, H., Fossati, T., Deshpande, Y., Smith, N., and W. Pan, "Concise Reference Integrity Manifest", Work in Progress, Internet-Draft, draft-ietf-rats-corim-04, 4 March 2024, . [IANA.cbor-tags] IANA, "Concise Binary Object Representation (CBOR) Tags", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Deshpande & Fossati Expires 6 January 2025 [Page 15] Internet-Draft Arm CCA Endorsements July 2024 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [CCA-TOKEN] "Arm's Confidential Compute Architecture Reference Attestation Token", 2022, . [RATS-ARCH] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . Contributors Simon Frost Arm Limited Email: Simon.Frost@arm.com Sergei Trofimov Arm Limited Email: Sergei.Trofimov@arm.com Authors' Addresses Yogesh Deshpande Arm Ltd Email: yogesh.deshpande@arm.com Thomas Fossati Linaro Email: thomas.fossati@linaro.org Deshpande & Fossati Expires 6 January 2025 [Page 16]