| RFC 9783 | Arm's PSA Attestation Token | June 2025 |
| Tschofenig, et al. | Informational | [Page] |
Arm's Platform Security Architecture (PSA) is a family of hardware andfirmware security specifications, along with open-source referenceimplementations, aimed at helping device makers and chip manufacturersintegrate best-practice security into their products. Devices thatcomply with PSA can generate attestation tokens as described in thisdocument, which serve as the foundation for various protocols, includingsecure provisioning and network access control. This document specifiesthe 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 attestationtoken generated by PSA-compliant systems, how these claims areserialized for transmission, and how they are cryptographicallyprotected.¶
This Informational document is published as an Independent Submission to improveinteroperability with Arm's architecture. It is not a standard nora product of the IETF.¶
This document is not an Internet Standards Track specification; it is published for informational purposes.¶
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9783.¶
Copyright (c) 2025 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.¶
The Platform Security Architecture (PSA)[PSA] is a set of hardware and firmwarespecifications backed by reference implementations and a securitycertification program[PSACertified]. The security specifications have been published by Arm,while the certification program and reference implementations are the result ofa collaborative effort by companies from multiple sectors, including evaluationlaboratories, IP semiconductor vendors, and security consultancies. The main objective ofthe PSA initiative is to assist device manufacturers and chip makers inincorporating best-practice security measures into their products.¶
Many devices now have Trusted Execution Environments (TEEs) that provide a safespace for security-sensitive code, such as cryptography, secure boot, securestorage, and other essential security functions. These securityfunctions are typically exposed through a narrow and well-defined interface,and can be used by operating system libraries and applications.¶
As outlined in the Remote ATtestation procedureS (RATS) Architecture[RFC9334], an Attester produces a signed collection of Claims that constitutes Evidence about its Target Environment. This document focuses on the output provided by PSA's Initial Attestation API[PSA-API]. This output corresponds to Evidence in[RFC9334] and, as a design decision, the PSA attestation token is a profile of the Entity Attestation Token (EAT)[EAT]. Note that there are other profiles of EAT available for use with different use cases and by different attestation technologies, such as[RATS-TDX] and[RATS-QWESTOKEN].¶
Since the PSA tokens are also consumed by services outside the device, there is an actualneed to ensure interoperability. Interoperability needs are addressed here bydescribing the exact syntax and semantics of the attestation claims, anddefining the way these claims are encoded and cryptographically protected.¶
Further details on concepts expressed below can be found in the PSA SecurityModel documentation[PSA-SM].¶
As mentioned in the abstract, this memo documents a vendor extensionto the RATS architecture and is not a standard.¶
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 terms Attester, Relying Party, Verifier, Attestation Result, Target Environment, Attesting Environment, and Evidenceare defined in[RFC9334]. We use the term "receiver" to refer to Relying Partiesand Verifiers.¶
We use the terms Evidence, "PSA attestation token", and "PSA token" interchangeably.The terms "sender" and Attester are used interchangeably. Likewise, we use the termsVerifier and "verification service" interchangeably.¶
In this document, the structure of data is specified in Concise Data Definition Language (CDDL)[RFC8610].¶
Figure 1 outlines the structure of the PSA Attester according tothe conceptual model described inSection 3.1 of [RFC9334].¶
The PSA Attester is a relatively straightforward embodiment of the RATSAttester with exactly one Attesting Environment and one or more Target Environments.¶
The Attesting Environment is responsible for collecting the information to be represented in PSA claims and to assemble them into Evidence. The Attesting Environment is made of two cooperating components:¶
Executing at boot-time, the Main Bootloader measures the Target Environments (i.e., loaded softwarecomponents and all the relevant PSA RoT parameters) and stores the recordedinformation in secure memory (Main Boot State). SeeFigure 2.¶
The word "Initial" in "Initial Attestation Service" refers to a limited set ofTarget Environments, namely those representing the first foundational stagesestablishing the chain of trust of a PSA device.Collecting measurements from Target Environments after this initial phase is outside the scope of this specification. Extensions of this specification could collect up-to-date measurements from additional Target Environments and define additional claims for use within those environments, but these are, by definition, custom.¶
The Target Environments can be of four types, some ofwhich may or may not be present depending on the device architecture:¶
A reference implementation of the PSA Attester is provided by[TF-M].¶
This section describes the claims to be used in a PSA attestation token.A more comprehensive treatment of the EAT profiles defined by PSA is found inSection 5.¶
CDDL[RFC8610] along with text descriptions is used to define each claimindependent of encoding. The following CDDL types are reused by differentclaims:¶
psa-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64¶
Two conventions are used to encode the Right-Hand-Side (RHS) of a claim. The postfix-label is used for EAT-defined claims and the postfix-key is used for PSA-originated claims.¶
The EAT[EAT] "nonce" (claim key 10) is used to carry the challenge provided by the caller to demonstrate freshness of the generated token.¶
Since the EAT nonce claim offers flexibility for differentattestation technologies, this specification applies the following constraints to thenonce-type:¶
This claimMUST be present in a PSA attestation token.¶
psa-nonce = ( nonce-label => psa-hash-type)¶
The Client ID claim represents the security domain of the caller.¶
In PSA, a security domain is represented by a signedinteger whereby negative values represent callers from the NSPE and wherepositive IDs represent callers from the SPE. The value 0 is not permitted.¶
For an example definition of client IDs, see the PSA Firmware Framework[PSA-FF].¶
It is essential that this claim is checked in the verification process toensure that a security domain, i.e., an attestation endpoint, cannot spoof areport from another security domain.¶
This claimMUST be present in a PSA attestation token.¶
psa-client-id-nspe-type = -2147483648...0psa-client-id-spe-type = 1..2147483647psa-client-id-type = psa-client-id-nspe-type / psa-client-id-spe-typepsa-client-id = ( psa-client-id-key => psa-client-id-type)¶
The Instance ID claim represents the unique identifier of the IAK. The full definition is in[PSA-SM].¶
The EATueid (claim key 256) of type RAND is used. The following constraintsapply to theueid-type:¶
This claimMUST be present in a PSA attestation token.¶
psa-instance-id-type = bytes .size 33psa-instance-id = ( ueid-label => psa-instance-id-type)¶
The Implementation ID claim uniquely identifies the hardware assembly of theimmutable PSA RoT. A verification service uses this claim to locate thedetails of the PSA RoT implementation from an Endorser or manufacturer.Such details are used by a verification service to determine the security propertiesor certification status of the PSA RoT implementation.¶
The value and format of the ID is decided bythe manufacturer or a particular certification scheme. For example, the IDcould take the form of a product serial number,database ID, or other appropriate identifier.¶
This claimMUST be present in a PSA attestation token.¶
Note that this identifies the PSA RoT implementation, not a particular instance.To uniquely identify an instance, see the Instance ID claimSection 4.2.1.¶
psa-implementation-id-type = bytes .size 32psa-implementation-id = ( psa-implementation-id-key => psa-implementation-id-type)¶
The Certification Reference claim is used to link the class of chip and PSA RoTof the attesting device to an associated entry in the PSA Certificationdatabase. The Certification Reference claimMUST be represented as astring made of nineteen numeric characters: a thirteen-digit EAN-13[EAN-13] followed by a dash "-" and the five-digit versioninginformation described in[PSA-Cert-Guide].¶
Linking to the PSA Certification entry can still be achieved if this claim isnot present in the token by making an association at a Verifier between thereference value and other token claim values, for example, the ImplementationID.¶
This claimMAY be present in a PSA attestation token.¶
psa-certification-reference-type = text .regexp "[0-9]{13}-[0-9]{5}"psa-certification-reference = ( ? psa-certification-reference-key => psa-certification-reference-type)¶The Security Lifecycle claim represents the current lifecycle state of the PSARoT. The state is represented by an integer that is divided to convey a majorstate and a minor state. A major state is mandatory and defined by[PSA-SM].A minor state is optional and 'IMPLEMENTATION DEFINED'. The PSA securitylifecycle state and implementation state are encoded as follows:¶
The PSA lifecycle states are illustrated inFigure 4. For PSA,a Verifier can only trust reports from the PSA RoT when it is in SECURED orNON_PSA_ROT_DEBUG major states.¶
This claimMUST be present in a PSA attestation token.¶
The CDDL representation is shown below.Table 1 provides the mappings betweenFigure 4 and the data model.¶
psa-lifecycle-unknown-type = 0x0000..0x00ffpsa-lifecycle-assembly-and-test-type = 0x1000..0x10ffpsa-lifecycle-psa-rot-provisioning-type = 0x2000..0x20ffpsa-lifecycle-secured-type = 0x3000..0x30ffpsa-lifecycle-non-psa-rot-debug-type = 0x4000..0x40ffpsa-lifecycle-recoverable-psa-rot-debug-type = 0x5000..0x50ffpsa-lifecycle-decommissioned-type = 0x6000..0x60ffpsa-lifecycle-type = psa-lifecycle-unknown-type / psa-lifecycle-assembly-and-test-type / psa-lifecycle-psa-rot-provisioning-type / psa-lifecycle-secured-type / psa-lifecycle-non-psa-rot-debug-type / psa-lifecycle-recoverable-psa-rot-debug-type / psa-lifecycle-decommissioned-typepsa-lifecycle = ( psa-lifecycle-key => psa-lifecycle-type)¶
psa-lifecycle-unknown-type is not shown inFigure 4; it represents an invalid state that must not occur in a system.¶
| CDDL | Lifecycle States |
|---|---|
psa-lifecycle-unknown-type | |
psa-lifecycle-assembly-and-test-type | Assembly and Test |
psa-lifecycle-psa-rot-provisioning-type | PSA RoT Provisioning |
psa-lifecycle-secured-type | Secured |
psa-lifecycle-non-psa-rot-debug-type | Non-Recoverable PSA RoT Debug |
psa-lifecycle-recoverable-psa-rot-debug-type | Recoverable PSA RoT Debug |
psa-lifecycle-decommissioned-type | Decommissioned |
The "bootseed" claim contains a value created at system boot timethat allows differentiation of attestation reports from differentboot sessions of a particular entity (i.e., a certain Instance ID).¶
The EAT "bootseed" (claim key 268) is used.The following constraints apply to thebinary-data type:¶
This claimMAY be present in a PSA attestation token.¶
psa-boot-seed-type = bytes .size (8..32)psa-boot-seed = ( boot-seed-label => psa-boot-seed-type)¶
The Software Components claim is a list of software components that includesall the software (both code and configuration) loaded by the PSA RoT. ThisclaimMUST be included in attestation tokens produced by an implementationconformant with[PSA-SM].¶
Each entry in the Software Components list describes one software componentusing the attributes described in the following subsections. Unless explicitlystated, the presence of an attribute isOPTIONAL.¶
Note that a Relying Party will typically see theresult of the appraisal process from the Verifier in form of an AttestationResult rather than the PSA token from the attesting endpoint as described in[RFC9334].Therefore, a Relying Party is not expected to understand the SoftwareComponents claim. Instead, it is for the Verifier to check this claim againstthe available Reference Values and provide an answer in form of a "high-level"Attestation Result, which may or may not include the original SoftwareComponents claim.¶
psa-software-component = { ? &(measurement-type: 1) => text &(measurement-value: 2) => psa-hash-type ? &(version: 4) => text &(signer-id: 5) => psa-hash-type ? &(measurement-desc: 6) => text}psa-software-components = ( psa-software-components-key => [ + psa-software-component ])¶The Measurement Type attribute (key=1) is a short string representing the role ofthis software component.¶
The following measurement typesMAY be used for code measurements:¶
The same labels with a "_CONFIG" postfix (e.g., "PRoT_CONFIG")MAY be used forconfiguration measurements.¶
This attributeSHOULD be present in a PSA software component unlessthere is a very good reason to leave it out, for example, in networkswith severely constrained bandwidth where sparing a few bytes reallymakes a difference.¶
The Measurement Value attribute (key=2) represents a hash of the invariantsoftware component in memory at startup time. The valueMUST be a cryptographichash of 256 bits or stronger.¶
This attributeMUST be present in a PSA software component.¶
The Version attribute (key=4) is the issued software version in the form of atext string. The value of this attribute will correspond to the entry in theoriginal signed manifest of the component.¶
The Signer ID attribute (key=5) uniquely identifies the signer of the software component. The identification is typically accomplished by hashing the signer's public key.The value of this attribute will correspond to theentry in the original manifest for the component. This can be used by aVerifier to ensure the components were signed by an expected trusted source.¶
This attributeMUST be present in a PSA software component to be compliant with[PSA-SM].¶
The Measurement Description attribute (key=6) contains a string identifying thehash algorithm used to compute the corresponding Measurement Value. The stringSHOULD be encoded according to "Hash Name String" in the "Named Information Hash Algorithm Registry"[NAMED-INFO].¶
The following claims, although part of Evidence, do not reflect the internal state of the Attester. Instead, they aim to help receivers, including Relying Parties, in processing the received attestation Evidence.¶
The Verification Service Indicator claim is a hint used by a Relying Party tolocate a verification service for the token. The value is a text string thatcan be used to locate the service (typically, a URL specifying the address ofthe verification service API). A Relying Party may choose to ignore this claimin favor of other information.¶
psa-verification-service-indicator-type = textpsa-verification-service-indicator = ( ? psa-verification-service-indicator-key => psa-verification-service-indicator-type)¶
It is assumed that the Relying Party is pre-configured with a list of trustedverification services and that the contents of this hint can be used to lookup the correct one. Under no circumstances must the Relying Party be trickedinto contacting an unknown and untrusted verification service since thereturned Attestation Result cannot be relied on.¶
Note: This hint requires the Relying Party to parse the content of thePSA token. Since the Relying Party may not be in possession of a trustanchor to verify the digital signature, it uses the hint in the same wayas it would treat any other information provided by an external party,which includes attacker-provided data.¶
The Profile Definition claim encodes the unique identifier that corresponds tothe EAT profile described by this document. This allows a receiver to assignthe intended semantics to the rest of the claims found in the token.¶
The EATeat_profile (claim key 265) is used.¶
The URI encodingMUST be used.¶
The valueMUST betag:psacertified.org,2023:psa#tfm for the profile defined inSection 5.2.¶
Future profiles derived from the baseline PSA profileSHALL create their unique value as described inSection 4.5.2.1.¶
This claimMUST be present in a PSA attestation token.¶
SeeSection 4.6 for considerations about backwards compatibilitywith previous versions of the PSA attestation token format.¶
psa-profile-type = "tag:psacertified.org,2023:psa#tfm"psa-profile = ( profile-label => psa-profile-type)¶
A new profile is associated with a unique string.¶
The stringMUST use the URI fragment syntax defined inSection 3.5 of [RFC3986].¶
The stringSHOULD be short to avoid unnecessary overhead.¶
To avoid collisions, profile authorsSHOULD communicate their intent upfront to use a certain string that uses the inquiry form on the website[PSACertified].¶
To derive the value to be used for theeat_profile claim, the string is added as a fragment to thetag:psacertified.org,2023:psa tag URI[RFC4151].¶
For example, a hypothetical profile using only COSE_Mac0 with the AES Message Authentication Code (AES-MAC) may decide to use the string "aes-mac". Theeat_profile value would then betag:psacertified.org,2023:psa#aes-mac.¶
An earlier draft of this document[PSA-OLD] identified by thePSA_IOT_PROFILE_1profile, used claim key values from the "private use range" of the CWT Claimsregistry. These claim keys have now been deprecated.¶
Table 2 provides the mappings between the deprecated and new claimkeys.¶
| PSA_IOT_PROFILE_1 | tag:psacertified.org,2023:psa#tfm | |
|---|---|---|
| Nonce | -75008 | 10 (EAT nonce) |
| Instance ID | -75009 | 256 (EAT euid) |
| Profile Definition | -75000 | 265 (EAT eat_profile) |
| Client ID | -75001 | 2394 |
| Security Lifecycle | -75002 | 2395 |
| Implementation ID | -75003 | 2396 |
| Boot Seed | -75004 | 268 (EAT bootseed) |
| Certification Reference | -75005 | 2398 |
| Software Components | -75006 | 2399 |
| Verification Service Indicator | -75010 | 2400 |
The new profile introduces three further changes:¶
To simplify the transition to the token format described in thisdocument, it isRECOMMENDED that Verifiersaccept tokens encoded according to the old profile (PSA_IOT_PROFILE_1) as well asto the profile defined in this document (tag:psacertified.org,2023:psa#tfm), at least for the time needed totheir devices to upgrade.¶
This document defines a baseline with common requirements that all PSA profiles must satisfy.(Note that this does not apply to[PSA-OLD].)¶
This document also defines a "TFM" profile (Section 5.2) that builds on the baseline while constraining the use of COSE algorithms to improve interoperability between Attesters and Verifiers.¶
Baseline and TFM are what the EAT calls a "partial" and "full" profile, respectively. SeeSection 6.2 of [EAT] for further details regarding profiles.¶
The PSA attestation token is encoded in CBOR[STD94] format.The CBOR representation of a PSA tokenMUST be "valid" according to the definition in Section1.2 of RFC 8949[STD94].Besides, only definite-length string, arrays, and maps are allowed.Given that a PSA Attester is typically found in a constrained device, itMAYNOT emit CBOR preferred serializations (Section4.1 of RFC 8949[STD94]).Therefore, the VerifierMUST be a variation-tolerant CBOR decoder.¶
Cryptographic protection is obtained by wrapping thepsa-token claims set in a COSEWeb Token (CWT)[RFC8392]. For asymmetric key algorithms, the signaturestructureMUST be a tagged (18) COSE_Sign1. For symmetric key algorithms, the signaturestructureMUST be a tagged (17) COSE_Mac0.¶
Acknowledging the variety of markets, regulations, and use cases in which thePSA attestation token can be used, the baseline profile does not impose anystrong requirement on the cryptographic algorithms that need to be supported byAttesters and Verifiers. The flexibility provided by the COSE format should besufficient to deal with the level of cryptographic agility needed to adapt tospecific use cases. It isRECOMMENDED that commonly adopted algorithms areused, such as those discussed in[COSE-ALGS]. It is expected that receiverswill accept a wider range of algorithms while Attesters would produce PSA tokensusing only one such algorithm.¶
The CWT CBOR tag (61) is not used. An application that needs to exchange PSAattestation tokens can wrap the serialized COSE_Sign1 or COSE_Mac0 in the mediatype defined inSection 10.2 or the CoAP Content-Format defined inSection 10.3.¶
A PSA token is always directly signed by the PSA RoT. Therefore, a PSA-token claims set (Section 4) is never carried in a Detached EAT bundle (Section 5 of [EAT]).¶
The PSA token supports the freshness models for attestation Evidence based onnonces and epoch handles (Section10.2 and Section10.3 of[RFC9334]) usingthe "nonce" claim to convey the nonce or epoch handle supplied by the Verifier.No further assumption on the specific remote attestation protocol is made.¶
Note that use of epoch handles is constrained by the type restrictions imposed by theeat_nonce syntax.For use in PSA tokens, it must be possible to encode the epoch handle as an opaque binary string between 8 and 64 octets.¶
Table 3 presents a concise view of the requirements described in the preceding sections.¶
| Issue | Profile Definition |
|---|---|
| CBOR/JSON | CBORMUST be used. |
| CBOR Encoding | Definite length maps and arraysMUST be used. |
| CBOR Encoding | Definite length stringsMUST be used. |
| CBOR Serialization | Variant serializationMAY be used. |
| COSE Protection | COSE_Sign1 and/or COSE_Mac0MUST be used. |
| Algorithms | [COSE-ALGS]SHOULD be used. |
| Detached EAT Bundle Usage | Detached EAT bundlesMUST NOT be sent. |
| Verification Key Identification | Any identification method listed inAppendix F.1 of [EAT]. |
| Endorsements | SeeSection 8.2. |
| Freshness | Nonce or epoch ID-based. |
| Claims | Those defined inSection 4. As per general EAT rules, the receiverMUST NOT error out on claims it does not understand. |
The TFM profile is appropriate for the code base implemented in[TF-M] and should apply for most derivative implementations. If an implementation changes the requirements described below, then a different profile value should be used (Section 4.5.2.1) to ensure interoperability. This includes a restriction of the profile to a subset of the COSE Protection scheme requirements.¶
Table 4 presents a concise view of the requirements.¶
The value of theeat_profileMUST betag:psacertified.org,2023:psa#tfm.¶
| Issue | Profile Definition |
|---|---|
| CBOR/JSON | SeeSection 5.1. |
| CBOR Encoding | SeeSection 5.1. |
| CBOR Encoding | SeeSection 5.1. |
| CBOR Serialization | SeeSection 5.1. |
| COSE Protection | COSE_Sign1 or COSE_Mac0MUST be used. |
| Algorithms | The receiverMUST accept ES256, ES384, and ES512 with COSE_Sign1 and HMAC256/256, HMAC384/384, and HMAC512/512 with COSE_Mac0; the senderMUST send one of these. |
| Detached EAT Bundle Usage | SeeSection 5.1. |
| Verification Key Identification | Claim-Based Key Identification (Appendix F.1.4 of [EAT]) using Instance ID. |
| Endorsements | SeeSection 8.2. |
| Freshness | SeeSection 5.1. |
| Claims | SeeSection 5.1. |
psa-token = { psa-nonce psa-instance-id psa-verification-service-indicator psa-profile psa-implementation-id psa-client-id psa-lifecycle psa-certification-reference ? psa-boot-seed psa-software-components}psa-client-id-key = 2394psa-lifecycle-key = 2395psa-implementation-id-key = 2396psa-certification-reference-key = 2398psa-software-components-key = 2399psa-verification-service-indicator-key = 2400nonce-label = 10ueid-label = 256boot-seed-label = 268profile-label = 265psa-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64psa-boot-seed-type = bytes .size (8..32)psa-boot-seed = ( boot-seed-label => psa-boot-seed-type)psa-client-id-nspe-type = -2147483648...0psa-client-id-spe-type = 1..2147483647psa-client-id-type = psa-client-id-nspe-type / psa-client-id-spe-typepsa-client-id = ( psa-client-id-key => psa-client-id-type)psa-certification-reference-type = text .regexp "[0-9]{13}-[0-9]{5}"psa-certification-reference = ( ? psa-certification-reference-key => psa-certification-reference-type)psa-implementation-id-type = bytes .size 32psa-implementation-id = ( psa-implementation-id-key => psa-implementation-id-type)psa-instance-id-type = bytes .size 33psa-instance-id = ( ueid-label => psa-instance-id-type)psa-nonce = ( nonce-label => psa-hash-type)psa-profile-type = "tag:psacertified.org,2023:psa#tfm"psa-profile = ( profile-label => psa-profile-type)psa-lifecycle-unknown-type = 0x0000..0x00ffpsa-lifecycle-assembly-and-test-type = 0x1000..0x10ffpsa-lifecycle-psa-rot-provisioning-type = 0x2000..0x20ffpsa-lifecycle-secured-type = 0x3000..0x30ffpsa-lifecycle-non-psa-rot-debug-type = 0x4000..0x40ffpsa-lifecycle-recoverable-psa-rot-debug-type = 0x5000..0x50ffpsa-lifecycle-decommissioned-type = 0x6000..0x60ffpsa-lifecycle-type = psa-lifecycle-unknown-type / psa-lifecycle-assembly-and-test-type / psa-lifecycle-psa-rot-provisioning-type / psa-lifecycle-secured-type / psa-lifecycle-non-psa-rot-debug-type / psa-lifecycle-recoverable-psa-rot-debug-type / psa-lifecycle-decommissioned-typepsa-lifecycle = ( psa-lifecycle-key => psa-lifecycle-type)psa-software-component = { ? &(measurement-type: 1) => text &(measurement-value: 2) => psa-hash-type ? &(version: 4) => text &(signer-id: 5) => psa-hash-type ? &(measurement-desc: 6) => text}psa-software-components = ( psa-software-components-key => [ + psa-software-component ])psa-verification-service-indicator-type = textpsa-verification-service-indicator = ( ? psa-verification-service-indicator-key => psa-verification-service-indicator-type)¶IAKs (seeSection 3) can be either raw public keys or certified public keys.¶
Certified public keys require the manufacturer to run the certificationauthority (CA) that issues X.509 certificates for the IAKs. (Note that operating a CAis a complex and expensive task that may be unaffordable to certainmanufacturers.)¶
Using certified public keys offers better scalability properties when compared to using raw public keys, namely:¶
Furthermore, existing and well-understood revocation mechanisms can be readily used.¶
The IAK's X.509 certificates can be inlined in the PSA token using thex5chain COSEheader parameter[COSE-X509] at the cost of an increase in the PSA tokensize.Section 4.4 of [TLS12-IoT] andSection 15 of [TLS13-IoT] provideguidance for profiling X.509 certificates used in IoT deployments.Note that the exact split between pre-provisioned and inlined certificates may varydepending on the specific deployment. In that respect,x5chain is quiteflexible. It can contain the end entity (EE) certification only, the EE and a partialchain, or the EE and the full chain up to the trust anchor (seeSection 2 of [COSE-X509] for the details).Constraints around network bandwidth and computing resources available to endpoints, such as network buffers, may dictate a reasonable split point.¶
To verify the token, the primary need is to check correct encoding and signingas detailed inSection 5.1.1.The key used for verification is either supplied to the Verifier by anauthorized Endorser along with the corresponding Attester's Instance ID orinlined in the token using thex5chain header parameter as described inSection 7.If the IAK is a raw public key and the Instance ID claim isused to assist inlocating the key used to verify the signature covering the CWT token.If the IAK is a certified public key, X.509 path construction and validation(Section 6 of [X509]) up to a trusted CAMUST be successful before the key isused to verify the token signature. This also includes revocation checking.¶
The Verifier typically has a policy where it compares some claims in this profile to reference values registered with it for a given deployment. This verification process serves to confirm that the device is endorsed by the manufacturer supply chain. The policy may require that therelevant claims must have a match to a registered reference value. All claimsmay be worthy of additional appraisal. It is likely that most deploymentswould include a policy with appraisal for the following claims:¶
[RATS-AR4SI] defines an information model that Verifiers can employ toproduce Attestation Results.AR4SI provides a set of standardized appraisal categories and tiers thatgreatly simplifies the task of writing Relying Party policies in Multi-Attesterenvironments.¶
The contents ofTable 5 are intended as guidance for implementing aPSA Verifier that computes its results using AR4SI.The table describes which PSA Evidence claims (if any) are related to whichAR4SI trustworthiness claim, and therefore what the Verifier must consider whendeciding if and how to appraise a certain feature associated with the PSAAttester.¶
| Trustworthiness Vector claims | Related PSA claims |
|---|---|
| "configuration" | Software Components (Section 4.4.1) |
| "executables" | ditto |
| "file-system" | N/A |
| "hardware" | Implementation ID (Section 4.2.2) |
| "instance-identity" | Instance ID (Section 4.2.1). The Security Lifecycle (Section 4.3.1) can also impact the derived identity. |
| "runtime-opaque" | Indirectly derived from "executables", "hardware", and "instance-identity". The Security Lifecycle (Section 4.3.1) can also be relevant, e.g., any debug state will expose otherwise protected memory. |
| "sourced-data" | N/A |
| "storage-opaque" | Indirectly derived from "executables", "hardware", and "instance-identity". |
This document does not prescribe what value must be chosen based on eachpossible situation. When assigning specific Trustworthiness Claim values, animplementation is expected to follow the algorithm described inSection 2.3.3 of [RATS-AR4SI].¶
[PSA-Endorsements] defines a protocol based on the[RATS-CoRIM] data modelthat can be used to convey PSA Endorsements, Reference Values, and verificationkey material to the Verifier.¶
This specification reuses the EAT specification and therefore the CWT specification.Hence, the security and privacy considerations of those specifications apply here as well.¶
Since CWTs offer different ways to protect the token, this specificationprofiles those options and allows signatures using public key cryptography aswell as message authentication codes (MACs). COSE_Sign1 is used for digitalsignatures and COSE_Mac0 for MACs as defined in the COSE specification[STD96].Note, however, that the use of MAC authentication isNOT RECOMMENDED due to the associatedinfrastructure costs for key management and protocol complexities.¶
A PSA AttesterMUST NOT provide Evidence to an untrustedchallenger, as it may allow attackers to interpose and trick the Verifier intobelieving the attacker is a legitimate Attester.This is especially relevant to protocols that use PSA attestation tokens to authenticate the attester to a Relying Party.¶
Attestation tokens contain information that may be unique to a device. Therefore, they may allow to single out an individual device for trackingpurposes. Deployments that have privacy requirements must take appropriatemeasures to ensure that the token is only used to provision anonymous/pseudonymkeys.¶
IANA has registered the following claims in the "CBOR Web Token (CWT) Claims" registry[CWT].¶
This document does not register any new media types. To indicate that the transmitted content is a PSA attestation token,applications can use theapplication/eat+cwt media type defined in[EAT-MEDIATYPES] with theeat_profile parameter set totag:psacertified.org,2023:psa#tfm (ortag:psacertified.org,2019:psa#legacy if the token is encodedaccording to the old profile; seeSection 4.6).¶
IANA has registered two CoAP Content-Format IDs in the First Come First Served range of the "CoAPContent-Formats" registry[Content-Formats]:¶
The following examples show PSA attestation tokens for a hypothetical systemcomprising a single measured software component.The attesting device is in a lifecycle state (Section 4.3.1) ofSECURED. The attestation has been requested from a client residing in theSPE.¶
The example inAppendix A.1 illustrates the case where the IAK is an asymmetric key. A COSE Sign1 envelope is used to wrap the PSA-token claims set.¶
Appendix A.2 illustrates the case where the IAK is a symmetric key and a COSE Mac0 envelope is used instead.¶
The claims sets are identical, except for the Instance ID which is synthesized from the key material.¶
The examples have been created using theiat-verifier tool[IAT-VERIFIER].¶
{ / ueid / 256: h'010202020202020202020202020202020202020202020202020202020202020202', / psa-implementation-id / 2396: h'0000000000000000000000000000000000000000000000000000000000000000', / eat_nonce / 10: h'0101010101010101010101010101010101010101010101010101010101010101', / psa-client-id / 2394: 2147483647, / psa-security-lifecycle / 2395: 12288, / eat_profile / 265: "tag:psacertified.org,2023:psa#tfm", / bootseed / 268: h'0000000000000000', / psa-software-components / 2399: [ { / signer ID / 5: h'0404040404040404040404040404040404040404040404040404040404040404', / measurement value / 2: h'0303030303030303030303030303030303030303030303030303030303030303', / measurement type / 1: "PRoT" } ]}¶The JWK representation of the IAK used for creating the COSE Sign1 signatureover the PSA token is:¶
{ "kty": "EC", "crv": "P-256", "alg": "ES256", "x": "Tl4iCZ47zrRbRG0TVf0dw7VFlHtv18HInYhnmMNybo8", "y": "gNcLhAslaqw0pi7eEEM2TwRAlfADR0uR4Bggkq-xPy4", "d": "Q__-y5X4CFp8QOHT6nkL7063jN131YUDpkwWAPkbM-c"}¶The resulting COSE object is:¶
18([ h'A10126', {}, h'A8190100582101020202020202020202020202020202020202020202020202020202020202020219095C582000000000000000000000000000000000000000000000000000000000000000000A5820010101010101010101010101010101010101010101010101010101010101010119095A1A7FFFFFFF19095B19300019010978217461673A7073616365727469666965642E6F72672C323032333A7073612374666D19010C48000000000000000019095F81A305582004040404040404040404040404040404040404040404040404040404040404040258200303030303030303030303030303030303030303030303030303030303030303016450526F54', h'786E937A4C42667AF3847399319CA95C7E7DBABDC9B50FDB8DE3F6BFF4AB82FF80C42140E2A488000219E3E10663193DA69C75F52B798EA10B2F7041A90E8E5A'])¶which has the following base16 encoding:¶
d28443a10126a0590100a8190100582101020202020202020202020202020202020202020202020202020202020202020219095c582000000000000000000000000000000000000000000000000000000000000000000a5820010101010101010101010101010101010101010101010101010101010101010119095a1a7fffffff19095b19300019010978217461673a7073616365727469666965642e6f72672c323032333a7073612374666d19010c48000000000000000019095f81a305582004040404040404040404040404040404040404040404040404040404040404040258200303030303030303030303030303030303030303030303030303030303030303016450526f545840786e937a4c42667af3847399319ca95c7e7dbabdc9b50fdb8de3f6bff4ab82ff80c42140e2a488000219e3e10663193da69c75f52b798ea10b2f7041a90e8e5a¶
{ / ueid / 256: h'01C557BD4FADC83F756FCA2CD5EA2DCC8B82159BB4E7453D6A744D4EECD6D0AC60', / psa-implementation-id / 2396: h'0000000000000000000000000000000000000000000000000000000000000000', / eat_nonce / 10: h'0101010101010101010101010101010101010101010101010101010101010101', / psa-client-id / 2394: 2147483647, / psa-security-lifecycle / 2395: 12288, / eat_profile / 265: "tag:psacertified.org,2023:psa#tfm", / psa-boot-seed / 268: h'0000000000000000', / psa-software-components / 2399: [ { / signer ID / 5: h'0404040404040404040404040404040404040404040404040404040404040404', / measurement value / 2: h'0303030303030303030303030303030303030303030303030303030303030303', / measurement type / 1: "PRoT" } ]}¶The JWK representation of the IAK used for creating the COSE Mac0 signatureover the PSA token is:¶
========== NOTE: '\\' line wrapping per RFC 8792 =========={ "kty": "oct", "alg": "HS256", "k": "3gOLNKyhJXaMXjNXq40Gs2e5qw1-i-Ek7cpH_gM6W7epPTB_8imqNv8k\ \bBKVlk-s9xq3qm7E_WECt7OYMlWtkg"}¶The resulting COSE object is:¶
17([ h'A10105', {}, h'A8190100582101C557BD4FADC83F756FCA2CD5EA2DCC8B82159BB4E7453D6A744D4EECD6D0AC6019095C582000000000000000000000000000000000000000000000000000000000000000000A5820010101010101010101010101010101010101010101010101010101010101010119095A1A7FFFFFFF19095B19300019010978217461673A7073616365727469666965642E6F72672C323032333A7073612374666D19010C48000000000000000019095F81A305582004040404040404040404040404040404040404040404040404040404040404040258200303030303030303030303030303030303030303030303030303030303030303016450526F54', h'CF88D330E7A5366A95CF744A4DBF0D50304D405EDD8B2530E243EDDBD3177820'])¶which has the following base16 encoding:¶
d18443a10105a0590100a8190100582101c557bd4fadc83f756fca2cd5ea2dcc8b82159bb4e7453d6a744d4eecd6d0ac6019095c582000000000000000000000000000000000000000000000000000000000000000000a5820010101010101010101010101010101010101010101010101010101010101010119095a1a7fffffff19095b19300019010978217461673a7073616365727469666965642e6f72672c323032333a7073612374666d19010c48000000000000000019095f81a305582004040404040404040404040404040404040404040404040404040404040404040258200303030303030303030303030303030303030303030303030303030303030303016450526f545820cf88d330e7a5366a95cf744a4dbf0d50304d405edd8b2530e243eddbd3177820¶
Thank youCarsten Bormann for help with the CDDL. Thanks toNicholas Wood,Eliot Lear,Yaron Sheffer,Kathleen Moriarty, andNed Smith for ideas, comments, and suggestions.¶