]> Linaro

thomas.fossati@linaro.org

Arm Ltd

yogesh.deshpande@arm.com

Fraunhofer SIT

henk.birkholz@sit.fraunhofer.de

Security Remote ATtestation ProcedureS PSA Endorsements comprise reference values, endorsed values, cryptographic key material and certification status information that a Verifier needs in order to appraise Attestation Evidence produced by a PSA device. This memo defines PSA Endorsements as a profile of the CoRIM data model. Discussion Venues Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (rats@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction PSA Endorsements include reference values, endorsed values, cryptographic key material and certification status information that a Verifier needs in order to appraise attestation Evidence produced by a PSA device . This memo defines PSA 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. An understanding of the data model is a prerequisite. The reader is also assumed to be familiar with the terms defined in and in .

PSA Endorsements PSA Endorsements describe an attesting device in terms of the hardware and firmware components that make up its PSA Root of Trust (RoT). This includes the identification and expected state of the device as well as the cryptographic key material needed to verify Evidence signed by the device's PSA RoT. Additionally, PSA Endorsements can include information related to the certification status of the attesting device. There are three basic types of PSA Endorsements:

• Reference Values (), i.e., measurements of the PSA RoT firmware;
• Attestation Verification Keys (), i.e., cryptographic keys that are used to verify signed Evidence produced by the PSA RoT, along with the identifiers that bind the keys to their device instances;
• Certification Claims (), i.e., metadata that describe the certification status associated with a PSA device;

There is a fourth PSA Endorsement type that aims at covering more advanced Verifier use cases (e.g., the one described in ):

• Software Relations (), used to model upgrade and patch relationships between software components.

PSA Endorsement Profile PSA Endorsements are carried in one or more CoMIDs inside a CoRIM. The profile attribute in the CoRIM MUST be present and MUST be the URI tag:arm.com,2025:psa#1.0.0 as shown in .

CoRIM profile for PSA Endorsements version 1.0.0

PSA Endorsements to PSA RoT Linkage Each PSA Endorsement - be it a Reference Value, Attestation Verification Key or Certification Claim - is associated with an immutable PSA RoT. The linkage between a PSA Endorsement and its PSA RoT is made by means of the unique PSA RoT identifier known as Implementation ID (see ). 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.

PSA Platform Implementation ID encoding

Besides, a PSA Endorsement can be associated with a specific instance of a certain PSA RoT - as is the case for Attestation Verification Keys. The Instance ID (see ) provides a unique identifier for a given PSA RoT. 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.

PSA RoT Instance ID encoding

PSA Attestation Verification Keys are associated with a PSA RoT 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 PSA RoT Identification

Reference Values Reference Values carry measurements and other metadata associated with the updatable firmware in a PSA RoT. When appraising Evidence, the Verifier compares Reference Values against the values found in the Software Components of the PSA 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 PSA RoT identified in the subject of the triple. A single reference-triple-record can completely describe the PSA RoT measurements. Each PSA Software Component (i.e., the psa-software-component defined in ) is encoded in a measurement-values-map as defined in .

PSA Software Component encoding psa-swcomp-version-map &(digests: 2) => psa-swcomp-digests-type ? &(name: 11) => psa-swcomp-name &(cryptokeys: 13) => [ psa-swcomp-signer-id ] } psa-swcomp-version-map = { &(version: 0) => text } psa-swcomp-digests-type = [ + psa-digest ] psa-digest = [ alg: text val: psa-hash-type ] psa-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64 psa-swcomp-name = text psa-swcomp-signer-id = #6.560(psa-hash-type) ]]>

version (key 0):

A version-map with its version field containing the version (key 4) of the psa-software-component. The version-scheme field of the version-map MUST NOT be present. The version field is optional.

digests (key 2):

Each array element encodes the "measurement value" (key 2) and "measurement-desc" (key 6) of the psa-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. The digests field is mandatory.

name (key 11):

A text value containing the "measurement-type" (key 1) of the psa-sw-component. The name 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 psa-sw-component. The cryptokeys field is mandatory.

Each measurement-values-map for a PSA RoT 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 "psa.software-component". The authorized-by field of the measurement-map MUST NOT be present. See for the related CDDL definitions.

PSA RoT Software Component measurement-map "psa.software-component" &(mval: 1) => psa-swcomp-measurement-values-map } ]]>

The complete example of a Reference Value CoMID Triple that encodes multiple psa-sw-component is given .

Example Reference Value

Attestation Verification Keys An Attestation Verification Key carries the verification key associated with the Initial Attestation Key (IAK) of a PSA device. When appraising Evidence, the Verifier can use the Implementation ID and Instance ID claims (see ) to look up the verification key that it SHALL use to check the signature on the Evidence. This allows the Verifier to prove (or disprove) the Attester's claimed identity. Each verification key is provided alongside the corresponding device Instance and Implementation IDs (and, possibly, a product identifier) in an attest-key-triple-record. Specifically:

• The Instance and Implementation IDs are encoded in the environment-map as shown in ;
• The IAK public key uses the tagged-pkix-base64-key-type variant of the $crypto-key-type-choice.

The IAK 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 PSA Endorsement of type Attestation Verification Key carrying a secp256r1 EC public IAK associated with Instance ID 4ca3...d296.

Example Attestation Verification Key

Certification Claims PSA Certified defines a certification scheme for the PSA ecosystem. A product - either a hardware component, a software component, or an entire device - that is verified to meet the security criteria established by the PSA Certified scheme is warranted a PSA Certified Security Assurance Certificate (SAC). A SAC contains information about the certification of a certain product (e.g., the target system, the attained certification level, the test lab that conducted the evaluation, etc.), and has a unique Certificate Number. The linkage between a PSA RoT -- comprising the immutable part as well as zero or more of the mutable components -- and the associated SAC is provided by a Certification Claim, which binds the PSA RoT Implementation ID and the software component identifiers with the SAC unique Certificate Number. When appraising Evidence, the Verifier can use the Certification Claims associated with the identified Attester as ancillary input to the Appraisal Policy, or to enrich the produced Attestation Result. A Certification Claim is encoded as a conditional-endorsement-triple-record. The SAC is encoded in a psa-cert-num that extends the measurement-values-map. See .

Example Certification Triple psa-cert-num-type ) psa-cert-num-type = text .regexp "[0-9]{13} - [0-9]{5}" ]]>

The conditional-endorsement-triple-record is constructed as follows:

• The Implementation ID of the immutable PSA RoT to which the SAC applies is encoded as a tagged-bytes in the environment-map of the stateful-environment-record; as shown in
• Any software component that is part of the certified PSA RoT is encoded as a reference value (see ) in the measurement-map of the stateful-environment-record;
• The unique SAC Certificate Number is encoded as psa-cert-num (key 100) in the measurement-values-map.

The example in shows a Certification Claim that associates Certificate Number 1234567890123 - 12345 to Implementation ID acme-implementation-id-000000001 and a single "PRoT" software component with version "1.3.5".

Example Certification Claim

Software Upgrades and Patches In order to model software lifecycle events such as updates and patches, this profile defines a new triple that conveys the following semantics:

• SUBJECT: a software component
• PREDICATE: (non-critically / critically) (updates / patches)
• OBJECT: another software component

The triple is reified and used as the object of another triple, psa-swrel-triple-record, whose subject is the embedding environment. [ + psa-swrel-triple-record ] ) psa.updates = 1 psa.patches = 2 psa-swrel-rel = [ type: psa.updates / psa.patches security-critical: bool ; true means it's a fix for a security bug ] sw-rel = [ new: comid.measurement-map ; the "new" firmware rel: psa-swrel-rel ; patches/updates and the security flag old: comid.measurement-map ; the "old" firmware ] psa-swrel-triple-record = [ environment-map sw-rel ] ]]> An example of a security critical update involving versions "1.2.5" and "1.3.0" of software component "PRoT" within the target environment associated with Implementation ID acme-implementation-id-000000001 is shown in .

Example Critical Software Upgrade

Security Considerations TODO

IANA Considerations

CoMID Codepoints

CoMID Triples Map Extension IANA is requested to register the following codepoints to the "CoMID Triples Map" registry. PSA CoMID Triples

Index	Item Name	Specification
50	comid.psa-swrel-triples	RFCthis

CoMID Measurement Values Map Extension Measurement Values Map Extensions

Key	Item Name	Item Type	Specification
100	comid.psa-cert-num	psa-cert-num	of RFCthis

Acknowledgements TODO

References Normative References Arm's Platform Security Architecture (PSA) is a family of hardware and firmware security specifications, along with open-source reference implementations, aimed at helping device makers and chip manufacturers integrate best-practice security into their products. Devices that comply with PSA can generate attestation tokens as described in this document, which serve as the foundation for various protocols, including secure provisioning and network access control. This document specifies the structure and semantics of the PSA attestation token. The PSA attestation token is a profile of the Entity Attestation Token (EAT). This specification describes the claims used in an attestation token generated by PSA-compliant systems, how these claims are serialized for transmission, 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. 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. 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] 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. 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. 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 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. A Trusted Execution Environment (TEE) is an environment that enforces the following: any code within the environment cannot be tampered with, and any data used by such code cannot be read or tampered with by any code outside the environment. This architecture document discusses the motivation for designing and standardizing a protocol for managing the lifecycle of Trusted Applications running inside such a TEE.