idnits 2.17.1 draft-tschofenig-rats-psa-token-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 March 2022) is 781 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-12 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-15 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS H. Tschofenig 3 Internet-Draft S. Frost 4 Intended status: Informational M. Brossard 5 Expires: 8 September 2022 Arm Limited 6 A. Shaw 7 HP Labs 8 T. Fossati 9 Arm Limited 10 7 March 2022 12 Arm's Platform Security Architecture (PSA) Attestation Token 13 draft-tschofenig-rats-psa-token-09 15 Abstract 17 The Platform Security Architecture (PSA) is a family of hardware and 18 firmware security specifications, as well as open-source reference 19 implementations, to help device makers and chip manufacturers build 20 best-practice security into products. Devices that are PSA compliant 21 are able to produce attestation tokens as described in this memo, 22 which are the basis for a number of different protocols, including 23 secure provisioning and network access control. This document 24 specifies the PSA attestation token structure and semantics. 26 The PSA attestation token is a profiled Entity Attestation Token 27 (EAT). 29 This specification describes what claims are used in an attestation 30 token generated by PSA compliant systems, how these claims get 31 serialized to the wire, and how they are cryptographically protected. 33 Note to Readers 35 Source for this draft and an issue tracker can be found at 36 https://github.com/thomas-fossati/draft-psa-token 37 (https://github.com/thomas-fossati/draft-psa-token). 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on 8 September 2022. 56 Copyright Notice 58 Copyright (c) 2022 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 63 license-info) in effect on the date of publication of this document. 64 Please review these documents carefully, as they describe your rights 65 and restrictions with respect to this document. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 71 2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. PSA Claims . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3.1. Caller Claims . . . . . . . . . . . . . . . . . . . . . . 4 74 3.1.1. Nonce . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3.1.2. Client ID . . . . . . . . . . . . . . . . . . . . . . 5 76 3.2. Target Identification Claims . . . . . . . . . . . . . . 5 77 3.2.1. Instance ID . . . . . . . . . . . . . . . . . . . . 5 78 3.2.2. Implementation ID . . . . . . . . . . . . . . . . . . 6 79 3.2.3. Certification Reference . . . . . . . . . . . . . . . 6 80 3.3. Target State Claims . . . . . . . . . . . . . . . . . . . 7 81 3.3.1. Security Lifecycle . . . . . . . . . . . . . . . . . 7 82 3.3.2. Boot Seed . . . . . . . . . . . . . . . . . . . . . . 8 83 3.4. Software Inventory Claims . . . . . . . . . . . . . . . . 8 84 3.4.1. Software Components . . . . . . . . . . . . . . . . . 8 85 3.5. Verification Claims . . . . . . . . . . . . . . . . . . . 10 86 3.5.1. Verification Service Indicator . . . . . . . . . . . 10 87 3.5.2. Profile Definition . . . . . . . . . . . . . . . . . 11 88 4. Backwards Compatibility Considerations . . . . . . . . . . . 11 89 5. Token Encoding and Signing . . . . . . . . . . . . . . . . . 12 90 6. Freshness Model . . . . . . . . . . . . . . . . . . . . . . . 13 91 7. Collated CDDL . . . . . . . . . . . . . . . . . . . . . . . . 13 92 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 93 9. Security and Privacy Considerations . . . . . . . . . . . . . 16 94 10. Verification . . . . . . . . . . . . . . . . . . . . . . . . 16 95 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 96 11.1. CBOR Web Token Claims Registration . . . . . . . . . . . 17 97 11.1.1. Client ID Claim . . . . . . . . . . . . . . . . . . 17 98 11.1.2. Security Lifecycle Claim . . . . . . . . . . . . . 18 99 11.1.3. Implementation ID Claim . . . . . . . . . . . . . . 18 100 11.1.4. Boot Seed Claim . . . . . . . . . . . . . . . . . . 18 101 11.1.5. Certification Reference Claim . . . . . . . . . . . 19 102 11.1.6. Software Components Claim . . . . . . . . . . . . . 19 103 11.1.7. Verification Service Indicator Claim . . . . . . . 19 104 11.2. Media Type Registration . . . . . . . . . . . . . . . . 20 105 11.3. CoAP Content-Formats Registration . . . . . . . . . . . 21 106 11.3.1. Registry Contents . . . . . . . . . . . . . . . . . 21 107 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 108 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 109 12.2. Informative References . . . . . . . . . . . . . . . . . 22 110 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 23 111 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 25 112 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 115 1. Introduction 117 Trusted execution environments are now present in many devices, which 118 provide a safe environment to place security sensitive code such as 119 cryptography, secure boot, secure storage, and other essential 120 security functions. These security functions are typically exposed 121 through a narrow and well-defined interface, and can be used by 122 operating system libraries and applications. Various APIs have been 123 developed by Arm as part of the Platform Security Architecture [PSA] 124 framework. This document focuses on the output provided by PSA's 125 Initial Attestation API. Since the tokens are also consumed by 126 services outside the device, there is an actual need to ensure 127 interoperability. Interoperability needs are addressed here by 128 describing the exact syntax and semantics of the attestation claims, 129 and defining the way these claims are encoded and cryptographically 130 protected. 132 Further details on concepts expressed below can be found in the PSA 133 Security Model documentation [PSA-SM]. 135 2. Conventions and Definitions 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in 140 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 141 capitals, as shown here. 143 2.1. Glossary 145 RoT Root of Trust, the minimal set of software, hardware and data 146 that has to be implicitly trusted in the platform - there is no 147 software or hardware at a deeper level that can verify that the 148 Root of Trust is authentic and unmodified. An example of RoT is 149 an initial bootloader in ROM, which contains cryptographic 150 functions and credentials, running on a specific hardware 151 platform. 153 SPE Secure Processing Environment, a platform's processing 154 environment for software that provides confidentiality and 155 integrity for its runtime state, from software and hardware, 156 outside of the SPE. Contains trusted code and trusted hardware. 157 (Equivalent to Trusted Execution Environment (TEE), or "secure 158 world".) 160 NSPE Non Secure Processing Environment, the security domain outside 161 of the SPE, the Application domain, typically containing the 162 application firmware, operating systems, and general hardware. 163 (Equivalent to Rich Execution Environment (REE), or "normal 164 world".) 166 3. PSA Claims 168 This section describes the claims to be used in a PSA attestation 169 token. 171 CDDL [RFC8610] along with text descriptions is used to define each 172 claim independent of encoding. The following CDDL type(s) are reused 173 by different claims: 175 psa-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64 177 3.1. Caller Claims 179 3.1.1. Nonce 181 The Nonce claim is used to carry the challenge provided by the caller 182 to demonstrate freshness of the generated token. 184 The EAT [I-D.ietf-rats-eat] nonce (claim key 10) is used. The 185 following constraints apply to the nonce-type: 187 * The length MUST be either 32, 48, or 64 bytes. 189 * Only a single nonce value is conveyed. Per [I-D.ietf-rats-eat] 190 the array notation is not used for encoding the nonce value. 192 This claim MUST be present in a PSA attestation token. 194 psa-nonce = ( 195 nonce-label => psa-hash-type 196 ) 198 3.1.2. Client ID 200 The Client ID claim represents the security domain of the caller. 202 In PSA, a security domain is represented by a signed integer whereby 203 negative values represent callers from the NSPE and where positive 204 IDs represent callers from the SPE. The value 0 is not permitted. 206 For an example definition of client IDs, see the PSA Firmware 207 Framework [PSA-FF]. 209 It is essential that this claim is checked in the verification 210 process to ensure that a security domain, i.e., an attestation 211 endpoint, cannot spoof a report from another security domain. 213 This claim MUST be present in a PSA attestation token. 215 psa-client-id-nspe-type = -2147483648...0 216 psa-client-id-spe-type = 1..2147483647 218 psa-client-id-type = psa-client-id-nspe-type / psa-client-id-spe-type 220 psa-client-id = ( 221 psa-client-id-key => psa-client-id-type 222 ) 224 3.2. Target Identification Claims 226 3.2.1. Instance ID 228 The Instance ID claim represents the unique identifier of the Initial 229 Attestation Key (IAK). The full definition is in [PSA-SM]. 231 The EAT ueid (claim key 256) of type RAND is used. The following 232 constraints apply to the ueid-type: 234 * The length MUST be 33 bytes. 236 * The first byte MUST be 0x01 (RAND) followed by the 32-bytes key 237 hash. 239 This claim MUST be present in a PSA attestation token. 241 psa-instance-id-type = bytes .size 33 243 psa-instance-id = ( 244 ueid-label => psa-instance-id-type 245 ) 247 3.2.2. Implementation ID 249 The Implementation ID claim uniquely identifies the implementation of 250 the immutable PSA RoT. A verification service uses this claim to 251 locate the details of the PSA RoT implementation from an Endorser or 252 manufacturer. Such details are used by a verification service to 253 determine the security properties or certification status of the PSA 254 RoT implementation. 256 The value and format of the ID is decided by the manufacturer or a 257 particular certification scheme. For example, the ID could take the 258 form of a product serial number, database ID, or other appropriate 259 identifier. 261 This claim MUST be present in a PSA attestation token. 263 Note that this identifies the PSA RoT implementation, not a 264 particular instance. To uniquely identify an instance, see the 265 Instance ID claim Section 3.2.1. 267 psa-implementation-id-type = bytes .size 32 269 psa-implementation-id = ( 270 psa-implementation-id-key => psa-implementation-id-type 271 ) 273 3.2.3. Certification Reference 275 The Certification Reference claim is used to link the class of chip 276 and PSA RoT of the attesting device to an associated entry in the PSA 277 Certification database. It MUST be represented as a thirteen-digit 278 [EAN-13]. 280 Linking to the PSA Certification entry can still be achieved if this 281 claim is not present in the token by making an association at a 282 Verifier between the reference value and other token claim values - 283 for example, the Implementation ID. 285 psa-certification-reference-type = text .regexp "[0-9]{13}" 287 psa-certification-reference = ( 288 ? psa-certification-reference-key => 289 psa-certification-reference-type 290 ) 292 3.3. Target State Claims 294 3.3.1. Security Lifecycle 296 The Security Lifecycle claim represents the current lifecycle state 297 of the PSA RoT. The state is represented by an integer that is 298 divided to convey a major state and a minor state. A major state is 299 mandatory and defined by [PSA-SM]. A minor state is optional and 300 'IMPLEMENTATION DEFINED'. The PSA security lifecycle state and 301 implementation state are encoded as follows: 303 * version[15:8] - PSA security lifecycle state, and 305 * version[7:0] - IMPLEMENTATION DEFINED state. 307 The PSA lifecycle states are illustrated in Figure 1. For PSA, a 308 Verifier can only trust reports from the PSA RoT when it is in 309 SECURED or NON_PSA_ROT_DEBUG major states. 311 This claim MUST be present in a PSA attestation token. 313 .----------------------. 314 .--- Enrol ---+ Provisioning Lockdown | 315 | '-----------+----------' 316 | | .------------------. 317 | | | | 318 * v v | 319 .--------------. .---------. | 320 | Verifier | .---------+ Secured +-----------. | 321 '--------------' | '-+-------' | | 322 * | | ^ | | 323 | | v | v | 324 Blocklist | .------------+------. .----------+----. 325 | | | Non-PSA RoT Debug | | Recoverable | 326 | | '---------+---------' | PSA RoT Debug | 327 .-+-----------+-. | '------+--------' 328 | Terminate +------------+-------------------' 329 '------+--------' 330 | .----------------. 331 '------------>| Decommissioned | 332 '----------------' 334 Figure 1: PSA Lifecycle States 336 psa-lifecycle-unknown-type = 0x0000..0x00ff 337 psa-lifecycle-assembly-and-test-type = 0x1000..0x10ff 338 psa-lifecycle-psa-rot-provisioning-type = 0x2000..0x20ff 339 psa-lifecycle-secured-type = 0x3000..0x30ff 340 psa-lifecycle-non-psa-rot-debug-type = 0x4000..0x40ff 341 psa-lifecycle-recoverable-psa-rot-debug-type = 0x5000..0x50ff 342 psa-lifecycle-decommissioned-type = 0x6000..0x60ff 344 psa-lifecycle-type = 345 psa-lifecycle-unknown-type / 346 psa-lifecycle-assembly-and-test-type / 347 psa-lifecycle-psa-rot-provisioning-type / 348 psa-lifecycle-secured-type / 349 psa-lifecycle-non-psa-rot-debug-type / 350 psa-lifecycle-recoverable-psa-rot-debug-type / 351 psa-lifecycle-decommissioned-type 353 psa-lifecycle = ( 354 psa-lifecycle-key => psa-lifecycle-type 355 ) 357 3.3.2. Boot Seed 359 The Boot Seed claim represents a random value created at system boot 360 time that will allow differentiation of reports from different boot 361 sessions. 363 This claim MUST be present in a PSA attestation token. 365 psa-boot-seed-type = bytes .size 32 367 psa-boot-seed = ( 368 psa-boot-seed-key => psa-boot-seed-type 369 ) 371 3.4. Software Inventory Claims 373 3.4.1. Software Components 375 The Software Components claim is a list of software components that 376 includes all the software loaded by the PSA RoT. This claim SHALL be 377 included in attestation tokens produced by an implementation 378 conformant with [PSA-SM]. 380 Each entry in the Software Components list describes one software 381 component using the attributes described in the following 382 subsections. Unless explicitly stated, the presence of an attribute 383 is OPTIONAL. 385 Note that, as described in [I-D.ietf-rats-architecture], a relying 386 party will typically see the result of the verification process from 387 the Verifier in form of an attestation result, rather than the 388 "naked" PSA token from the attesting endpoint. Therefore, a relying 389 party is not expected to understand the Software Components claim. 390 Instead, it is for the Verifier to check this claim against the 391 available endorsements and provide an answer in form of an "high 392 level" attestation result, which may or may not include the original 393 Software Components claim. 395 psa-software-component = { 396 ? 1 => text, ; measurement type 397 2 => psa-hash-type, ; measurement value 398 ? 4 => text, ; version 399 5 => psa-hash-type, ; signer id 400 ? 6 => text, ; measurement description 401 } 403 psa-software-components = ( 404 psa-software-components-key => [ + psa-software-component ] 405 ) 407 3.4.1.1. Measurement Type 409 The Measurement Type attribute (key=1) is short string representing 410 the role of this software component. 412 The following measurement types MAY be used: 414 * "BL": a Boot Loader 416 * "PRoT": a component of the PSA Root of Trust 418 * "ARoT": a component of the Application Root of Trust 420 * "App": a component of the NSPE application 422 * "TS": a component of a Trusted Subsystem 424 3.4.1.2. Measurement Value 426 The Measurement Value attribute (key=2) represents a hash of the 427 invariant software component in memory at startup time. The value 428 MUST be a cryptographic hash of 256 bits or stronger. 430 This attribute MUST be present in a PSA software component. 432 3.4.1.3. Version 434 The Version attribute (key=4) is the issued software version in the 435 form of a text string. The value of this attribute will correspond 436 to the entry in the original signed manifest of the component. 438 3.4.1.4. Signer ID 440 The Signer ID attribute (key=5) is the hash of a signing authority 441 public key for the software component. The value of this attribute 442 will correspond to the entry in the original manifest for the 443 component. This can be used by a Verifier to ensure the components 444 were signed by an expected trusted source. 446 This attribute MUST be present in a PSA software component to be 447 compliant with [PSA-SM]. 449 3.4.1.5. Measurement Description 451 The Measurement Description attribute (key=6) contains a string 452 identifying the hash algorithm used to compute the corresponding 453 Measurement Value. The string SHOULD be encoded according to 454 [IANA-HashFunctionTextualNames]. 456 3.5. Verification Claims 458 3.5.1. Verification Service Indicator 460 The Verification Service Indicator claim is a hint used by a relying 461 party to locate a validation service for the token. The value is a 462 text string that can be used to locate the service or a URL 463 specifying the address of the service. A Verifier may choose to 464 ignore this claim in favor of other information. 466 psa-verification-service-indicator-type = text 468 psa-verification-service-indicator = ( 469 ? psa-verification-service-indicator-key => 470 psa-verification-service-indicator-type 471 ) 473 3.5.2. Profile Definition 475 The Profile Definition claim encodes the unique identifier that 476 corresponds to the EAT profile described by this document. This 477 allows a receiver to assign the intended semantics to the rest of the 478 claims found in the token. 480 The EAT profile (claim key 265) is used. The following constraints 481 apply to its type: 483 * The URI encoding MUST be used. 485 * The value MUST be http://arm.com/psa/2.0.0. 487 This claim MUST be present in a PSA attestation token. 489 See Section 4, for considerations about backwards compatibility with 490 previous versions of the PSA attestation token format. 492 psa-profile-type = "http://arm.com/psa/2.0.0" 494 psa-profile = ( 495 profile-label => psa-profile-type 496 ) 498 4. Backwards Compatibility Considerations 500 A previous version of this specification (identified by the 501 PSA_IOT_PROFILE_1 profile) used claim key values from the "private 502 use range" of the CWT Claims registry. These claim keys have now 503 been retired and their use is deprecated. 505 Table 1 provides the mappings between the deprecated and new claim 506 keys. 508 +====================+===================+==========================+ 509 | | PSA_IOT_PROFILE_1 | http://arm.com/psa/2.0.0 | 510 +====================+===================+==========================+ 511 | Nonce | -75008 | 10 (EAT nonce) | 512 +--------------------+-------------------+--------------------------+ 513 | Instance ID | -75009 | 256 (EAT euid) | 514 +--------------------+-------------------+--------------------------+ 515 | Profile | -75000 | 265 (EAT eat_profile) | 516 | Definition | | | 517 +--------------------+-------------------+--------------------------+ 518 | Client ID | -75001 | 2394 | 519 +--------------------+-------------------+--------------------------+ 520 | Security | -75002 | 2395 | 521 | Lifecycle | | | 522 +--------------------+-------------------+--------------------------+ 523 | Implementation ID | -75003 | 2396 | 524 +--------------------+-------------------+--------------------------+ 525 | Boot Seed | -75004 | 2397 | 526 +--------------------+-------------------+--------------------------+ 527 | Certification | -75005 | 2398 | 528 | Reference | | | 529 +--------------------+-------------------+--------------------------+ 530 | Software | -75006 | 2399 | 531 | Components | | | 532 +--------------------+-------------------+--------------------------+ 533 | Verification | -75010 | 2400 | 534 | Service Indicator | | | 535 +--------------------+-------------------+--------------------------+ 537 Table 1: Claim key mappings 539 Unless compatibility with existing infrastructure is a concern, 540 emitters (e.g., devices that implement the PSA Attestation API) 541 SHOULD produce tokens with the claim keys specified in this document. 543 To simplify the transition to the token format described in this 544 document it is RECOMMENDED that receivers (e.g., PSA Attestation 545 Verifiers) accept tokens encoded according to the old profile 546 (PSA_IOT_PROFILE_1) as well as to the new profile (http://arm.com/ 547 psa/2.0.0), at least for the time needed to their clients to upgrade. 549 5. Token Encoding and Signing 551 The PSA attestation token is encoded in CBOR [RFC8949] format. Only 552 definite-length string, arrays, and maps are allowed. 554 Cryptographic protection is obtained by wrapping the psa-token map in 555 a COSE Web Token (CWT) [RFC8392]. For asymmetric key algorithms, the 556 signature structure MUST be COSE_Sign1. For symmetric key 557 algorithms, the signature structure MUST be COSE_Mac0. 559 Acknowledging the variety of markets, regulations and use cases in 560 which the PSA attestation token can be used, this specification does 561 not impose any strong requirement on the cryptographic algorithms 562 that need to be supported by Attesters and Verifiers. It is assumed 563 that some form of out-of-band discovery and negotiation is in place 564 to allow interoperability between the involved parties, and that the 565 flexibility provided by the COSE format is sufficient to deal with 566 the level of cryptographic agility needed to adapt to specific use 567 cases. 569 The CWT CBOR tag (61) is not used. An application that needs to 570 exchange PSA attestation tokens can wrap the serialised COSE_Sign1 or 571 COSE_Mac0 in the media type defined in Section 11.2 or the CoAP 572 Content-Format defined in Section 11.3. 574 6. Freshness Model 576 The PSA Token supports the freshness models for attestation Evidence 577 based on nonces and epoch handles (Section 10.2 and 10.3 of 578 [I-D.ietf-rats-architecture]) using the nonce claim to convey the 579 nonce or epoch handle supplied by the Verifier. No further 580 assumption on the specific remote attestation protocol is made. 582 7. Collated CDDL 584 psa-token = { 585 psa-nonce, 586 psa-instance-id, 587 psa-verification-service-indicator, 588 psa-profile, 589 psa-implementation-id, 590 psa-client-id, 591 psa-lifecycle, 592 psa-certification-reference, 593 psa-boot-seed, 594 psa-software-components, 595 } 597 psa-client-id-key = 2394 598 psa-lifecycle-key = 2395 599 psa-implementation-id-key = 2396 600 psa-boot-seed-key = 2397 601 psa-certification-reference-key = 2398 602 psa-software-components-key = 2399 603 psa-verification-service-indicator-key = 2400 605 ; from EAT 606 nonce-label = 10 607 ueid-label = 256 608 profile-label = 265 610 psa-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64 612 psa-boot-seed-type = bytes .size 32 614 psa-boot-seed = ( 615 psa-boot-seed-key => psa-boot-seed-type 616 ) 618 psa-client-id-nspe-type = -2147483648...0 619 psa-client-id-spe-type = 1..2147483647 621 psa-client-id-type = psa-client-id-nspe-type / psa-client-id-spe-type 623 psa-client-id = ( 624 psa-client-id-key => psa-client-id-type 625 ) 627 psa-certification-reference-type = text .regexp "[0-9]{13}" 629 psa-certification-reference = ( 630 ? psa-certification-reference-key => 631 psa-certification-reference-type 632 ) 634 psa-implementation-id-type = bytes .size 32 636 psa-implementation-id = ( 637 psa-implementation-id-key => psa-implementation-id-type 638 ) 640 psa-instance-id-type = bytes .size 33 642 psa-instance-id = ( 643 ueid-label => psa-instance-id-type 644 ) 646 psa-nonce = ( 647 nonce-label => psa-hash-type 648 ) 649 psa-profile-type = "http://arm.com/psa/2.0.0" 651 psa-profile = ( 652 profile-label => psa-profile-type 653 ) 655 psa-lifecycle-unknown-type = 0x0000..0x00ff 656 psa-lifecycle-assembly-and-test-type = 0x1000..0x10ff 657 psa-lifecycle-psa-rot-provisioning-type = 0x2000..0x20ff 658 psa-lifecycle-secured-type = 0x3000..0x30ff 659 psa-lifecycle-non-psa-rot-debug-type = 0x4000..0x40ff 660 psa-lifecycle-recoverable-psa-rot-debug-type = 0x5000..0x50ff 661 psa-lifecycle-decommissioned-type = 0x6000..0x60ff 663 psa-lifecycle-type = 664 psa-lifecycle-unknown-type / 665 psa-lifecycle-assembly-and-test-type / 666 psa-lifecycle-psa-rot-provisioning-type / 667 psa-lifecycle-secured-type / 668 psa-lifecycle-non-psa-rot-debug-type / 669 psa-lifecycle-recoverable-psa-rot-debug-type / 670 psa-lifecycle-decommissioned-type 672 psa-lifecycle = ( 673 psa-lifecycle-key => psa-lifecycle-type 674 ) 676 psa-software-component = { 677 ? 1 => text, ; measurement type 678 2 => psa-hash-type, ; measurement value 679 ? 4 => text, ; version 680 5 => psa-hash-type, ; signer id 681 ? 6 => text, ; measurement description 682 } 684 psa-software-components = ( 685 psa-software-components-key => [ + psa-software-component ] 686 ) 688 psa-verification-service-indicator-type = text 690 psa-verification-service-indicator = ( 691 ? psa-verification-service-indicator-key => 692 psa-verification-service-indicator-type 693 ) 695 8. Implementation Status 697 Independent implementations of this specification are provided by the 698 Trusted Firmware project [TF-M], the Veraison project [Veraison], and 699 Xclaim [Xclaim]. All three implementations are released as open- 700 source software. 702 9. Security and Privacy Considerations 704 This specification re-uses the CWT and the EAT specification. Hence, 705 the security and privacy considerations of those specifications apply 706 here as well. 708 Since CWTs offer different ways to protect the token, this 709 specification profiles those options and allows signatures based on 710 use of public key cryptography as well as MAC authentication. The 711 token MUST be signed following the structure of the COSE 712 specification [RFC8152]. The COSE type MUST be COSE_Sign1 for public 713 key signatures or COSE_Mac0 for MAC authentication. Note however 714 that use of MAC authentication is NOT RECOMMENDED due to the 715 associated infrastructure costs for key management and protocol 716 complexities. It may also restrict the ability to interoperate with 717 third parties. 719 Attestation tokens contain information that may be unique to a device 720 and therefore they may allow to single out an individual device for 721 tracking purposes. Implementations that have privacy requirements 722 must take appropriate measures to ensure that the token is only used 723 to provision anonymous/pseudonym keys. 725 10. Verification 727 To verify the token, the primary need is to check correct encoding 728 and signing as detailed in Section 5. In particular, the Instance ID 729 claim is used (together with the kid in the COSE header, if present) 730 to assist in locating the public key used to verify the signature 731 covering the CWT token. The key used for verification is supplied to 732 the Verifier by an authorized Endorser along with the corresponding 733 Attester's Instance ID. 735 In addition, the Verifier will typically operate a policy where 736 values of some of the claims in this profile can be compared to 737 reference values, registered with the Verifier for a given 738 deployment, in order to confirm that the device is endorsed by the 739 manufacturer supply chain. The policy may require that the relevant 740 claims must have a match to a registered reference value. All claims 741 may be worthy of additional appraisal. It is likely that most 742 deployments would include a policy with appraisal for the following 743 claims: 745 * Implementation ID - the value of the Implementation ID can be used 746 to identify the verification requirements of the deployment. 748 * Software Component, Measurement Value - this value can uniquely 749 identify a firmware release from the supply chain. In some cases, 750 a Verifier may maintain a record for a series of firmware 751 releases, being patches to an original baseline release. A 752 verification policy may then allow this value to match any point 753 on that release sequence or expect some minimum level of maturity 754 related to the sequence. 756 * Software Component, Signer ID - where present in a deployment, 757 this could allow a Verifier to operate a more general policy than 758 that for Measurement Value as above, by allowing a token to 759 contain any firmware entries signed by a known Signer ID, without 760 checking for a uniquely registered version. 762 * Certification Reference - if present, this value could be used as 763 a hint to locate security certification information associated 764 with the attesting device. An example could be a reference to a 765 [PSACertified] certificate. 767 The protocol used to convey Endorsements and Reference Values to the 768 Verifier is not in scope for this document. 770 11. IANA Considerations 772 11.1. CBOR Web Token Claims Registration 774 This specification requests IANA to register the following claims in 775 the "CBOR Web Token (CWT) Claims" registry [IANA-CWT]. 777 11.1.1. Client ID Claim 779 * Claim Name: psa-client-id 781 * Claim Description: PSA Client ID 782 * JWT Claim Name: N/A 784 * Claim Key: TBD (requested value: 2394) 786 * Claim Value Type(s): signed integer 788 * Change Controller: [[Authors of this RFC]] 790 * Specification Document(s): Section 3.1.2 of [[this RFC]] 792 11.1.2. Security Lifecycle Claim 794 * Claim Name: psa-security-lifecycle 796 * Claim Description: PSA Security Lifecycle 798 * JWT Claim Name: N/A 800 * Claim Key: TBD (requested value: 2395) 802 * Claim Value Type(s): unsigned integer 804 * Change Controller: [[Authors of this RFC]] 806 * Specification Document(s): Section 3.3.1 of [[this RFC]] 808 11.1.3. Implementation ID Claim 810 * Claim Name: psa-implementation-id 812 * Claim Description: PSA Implementation ID 814 * JWT Claim Name: N/A 816 * Claim Key: TBD (requested value: 2396) 818 * Claim Value Type(s): byte string 820 * Change Controller: [[Authors of this RFC]] 822 * Specification Document(s): Section 3.2.2 of [[this RFC]] 824 11.1.4. Boot Seed Claim 826 * Claim Name: psa-boot-seed 828 * Claim Description: PSA Boot Seed 829 * JWT Claim Name: N/A 831 * Claim Key: TBD (requested value: 2397) 833 * Claim Value Type(s): byte string 835 * Change Controller: [[Authors of this RFC]] 837 * Specification Document(s): Section 3.3.2 of [[this RFC]] 839 11.1.5. Certification Reference Claim 841 * Claim Name: psa-certification-reference 843 * Claim Description: PSA Certification Reference 845 * JWT Claim Name: N/A 847 * Claim Key: TBD (requested value: 2398) 849 * Claim Value Type(s): text string 851 * Change Controller: [[Authors of this RFC]] 853 * Specification Document(s): Section 3.2.3 of [[this RFC]] 855 11.1.6. Software Components Claim 857 * Claim Name: psa-software-components 859 * Claim Description: PSA Software Components 861 * JWT Claim Name: N/A 863 * Claim Key: TBD (requested value: 2399) 865 * Claim Value Type(s): array 867 * Change Controller: [[Authors of this RFC]] 869 * Specification Document(s): Section 3.4.1 of [[this RFC]] 871 11.1.7. Verification Service Indicator Claim 873 * Claim Name: psa-verification-service-indicator 875 * Claim Description: PSA Verification Service Indicator 876 * JWT Claim Name: N/A 878 * Claim Key: TBD (requested value: 2400) 880 * Claim Value Type(s): text string 882 * Change Controller: [[Authors of this RFC]] 884 * Specification Document(s): Section 3.5.1 of [[this RFC]] 886 11.2. Media Type Registration 888 IANA is requested to register the "application/psa-attestation-token" 889 media type [RFC2046] in the "Media Types" registry [IANA-MediaTypes] 890 in the manner described in RFC 6838 [RFC6838], which can be used to 891 indicate that the content is a PSA Attestation Token. 893 * Type name: application 895 * Subtype name: psa-attestation-token 897 * Required parameters: n/a 899 * Optional parameters: n/a 901 * Encoding considerations: binary 903 * Security considerations: See the Security Considerations section 904 of [[this RFC]] 906 * Interoperability considerations: n/a 908 * Published specification: [[this RFC]] 910 * Applications that use this media type: Attesters and Relying 911 Parties sending PSA attestation tokens over HTTP(S), CoAP(S), and 912 other transports. 914 * Fragment identifier considerations: n/a 916 * Additional information: 918 - Magic number(s): n/a 920 - File extension(s): n/a 922 - Macintosh file type code(s): n/a 924 * Person & email address to contact for further information: Hannes 925 Tschofenig, Hannes.Tschofenig@arm.com 927 * Intended usage: COMMON 929 * Restrictions on usage: none 931 * Author: Hannes Tschofenig, Hannes.Tschofenig@arm.com 933 * Change controller: IESG 935 * Provisional registration? No 937 11.3. CoAP Content-Formats Registration 939 IANA is requested to register the CoAP Content-Format ID for the 940 "application/psa-attestation-token" media type in the "CoAP Content- 941 Formats" registry [IANA-CoAP-Content-Formats]. 943 11.3.1. Registry Contents 945 * Media Type: application/psa-attestation-token 947 * Encoding: - 949 * Id: [[To-be-assigned by IANA]] 951 * Reference: [[this RFC]] 953 12. References 955 12.1. Normative References 957 [EAN-13] GS1, "International Article Number - EAN/UPC barcodes", 958 2019, . 960 [I-D.ietf-rats-eat] 961 Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity 962 Attestation Token (EAT)", Work in Progress, Internet- 963 Draft, draft-ietf-rats-eat-12, 24 February 2022, 964 . 967 [PSA-FF] Arm, "Platform Security Architecture Firmware Framework 968 1.0 (PSA-FF)", February 2019, . 972 [PSA-SM] Arm, "Platform Security Architecture Security Model 1.0 973 (PSA-SM)", February 2019, . 977 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 978 Extensions (MIME) Part Two: Media Types", RFC 2046, 979 DOI 10.17487/RFC2046, November 1996, 980 . 982 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 983 Requirement Levels", BCP 14, RFC 2119, 984 DOI 10.17487/RFC2119, March 1997, 985 . 987 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 988 Specifications and Registration Procedures", BCP 13, 989 RFC 6838, DOI 10.17487/RFC6838, January 2013, 990 . 992 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 993 RFC 8152, DOI 10.17487/RFC8152, July 2017, 994 . 996 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 997 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 998 May 2017, . 1000 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1001 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 1002 May 2018, . 1004 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1005 Definition Language (CDDL): A Notational Convention to 1006 Express Concise Binary Object Representation (CBOR) and 1007 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1008 June 2019, . 1010 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1011 Representation (CBOR)", STD 94, RFC 8949, 1012 DOI 10.17487/RFC8949, December 2020, 1013 . 1015 12.2. Informative References 1017 [I-D.ietf-rats-architecture] 1018 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 1019 W. Pan, "Remote Attestation Procedures Architecture", Work 1020 in Progress, Internet-Draft, draft-ietf-rats-architecture- 1021 15, 8 February 2022, 1022 . 1025 [IANA-CoAP-Content-Formats] 1026 IANA, "CoAP Content-Formats", 2022, 1027 . 1029 [IANA-CWT] IANA, "CBOR Web Token (CWT) Claims", 2022, 1030 . 1033 [IANA-HashFunctionTextualNames] 1034 IANA, "Hash Function Textual Names", 2022, 1035 . 1038 [IANA-MediaTypes] 1039 IANA, "Media Types", 2022, 1040 . 1042 [PSA] Arm, "Platform Security Architecture Resources", 2022, 1043 . 1047 [PSACertified] 1048 PSA Certified, "PSA Certified IoT Security Framework", 1049 2022, . 1051 [TF-M] Linaro, "Trusted Firmware-M", 2022, 1052 . 1054 [Veraison] The Veraison Project, "Veraison psatoken package", 2022, 1055 . 1057 [Xclaim] Lundblade, L., "Xclaim", 2022, 1058 . 1060 Appendix A. Example 1062 The following example shows a PSA attestation token for an 1063 hypothetical system comprising two measured software components (a 1064 boot loader and a trusted RTOS). The attesting device is in a 1065 lifecycle state Section 3.3.1 of SECURED. The attestation has been 1066 requested from a client residing in the SPE: 1068 { 1069 / eat_profile / 265: "http://arm.com/psa/2.0.0", 1070 / psa-client-id / 2394: 1, 1071 / psa-lifecycle / 2395: 12288, 1072 / psa-implementation-id / 2396: h'50515253545556575051 1073 52535455565750515253545556575051525354555657', 1074 / psa-boot-seed / 2397: h'DEADBEEFDEADBEEFDEAD 1075 BEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEF', 1076 / psa-certification-reference / 2398: "1234567890123", 1077 / psa-software-components / 2399: [ 1078 { 1079 / measurement type / 1: "BL", 1080 / measurement value / 2: h'0001020400010204000102040001020 1081 400010204000102040001020400010204', 1082 / signer ID / 5: h'519200FF519200FF519200FF519200F 1083 F519200FF519200FF519200FF519200FF' 1084 }, 1085 { 1086 / measurement type / 1: "PRoT", 1087 / measurement value / 2: h'0506070805060708050607080506070 1088 805060708050607080506070805060708', 1089 / signer ID / 5: h'519200FF519200FF519200FF519200F 1090 F519200FF519200FF519200FF519200FF' 1091 } 1092 ], 1093 / nonce / 10: h'00010203000102030001020300010203 1094 00010203000102030001020300010203', 1095 / ueid / 256: h'01A0A1A2A3A0A1A2A3A0A1A2A3A0A1A2 1096 A3A0A1A2A3A0A1A2A3A0A1A2A3A0A1A2A3', 1097 / psa-verification-service-indicator / 2400: "https://psa-ve 1098 rifier.org" 1099 } 1101 The JWK representation of the IAK used for creating the COSE Sign1 1102 signature over the PSA token is: 1104 { 1105 "kty": "EC", 1106 "crv": "P-256", 1107 "x": "MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4", 1108 "y": "4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM", 1109 "d": "870MB6gfuTJ4HtUnUvYMyJpr5eUZNP4Bk43bVdj3eAE", 1110 "use": "enc", 1111 "kid": "1" 1112 } 1114 The resulting COSE object is: 1116 18( 1117 [ 1118 / protected / h'A10126', 1119 / unprotected / {}, 1120 / payload / h'AA1901097818687474703A2F2F61726D2E636F6D2F 1121 7073612F322E302E3019095A0119095B19300019095C58205051525354555657 1122 50515253545556575051525354555657505152535455565719095D5820DEADBE 1123 EFDEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEF19095E 1124 6D3132333435363738393031323319095F82A30162424C025820000102040001 1125 0204000102040001020400010204000102040001020400010204055820519200 1126 FF519200FF519200FF519200FF519200FF519200FF519200FF519200FFA30164 1127 50526F5402582005060708050607080506070805060708050607080506070805 1128 06070805060708055820519200FF519200FF519200FF519200FF519200FF5192 1129 00FF519200FF519200FF0A582000010203000102030001020300010203000102 1130 03000102030001020300010203190100582101A0A1A2A3A0A1A2A3A0A1A2A3A0 1131 A1A2A3A0A1A2A3A0A1A2A3A0A1A2A3A0A1A2A3190960781868747470733A2F2F 1132 7073612D76657269666965722E6F7267', 1133 / signature / h'E3B80C143403ECB744B1D6EF732872A1A3E682783E 1134 939F72A3CEF6BF74EF4BC5E7065725FF5C948770B673C5896D3F796F55D144FC 1135 B456BEA832EB13E8258DB8' 1136 ] 1137 ) 1139 Contributors 1141 We would like to thank the following colleagues for their 1142 contributions: 1144 * Laurence Lundblade 1145 Security Theory LLC 1146 lgl@securitytheory.com 1148 * Tamas Ban 1149 Arm Limited 1150 Tamas.Ban@arm.com 1152 * Sergei Trofimov 1153 Arm Limited 1154 Sergei.Trofimov@arm.com 1156 Acknowledgments 1158 Thanks to Carsten Bormann for help with the CDDL and Nicholas Wood 1159 for ideas and comments. 1161 Authors' Addresses 1162 Hannes Tschofenig 1163 Arm Limited 1164 Email: Hannes.Tschofenig@arm.com 1166 Simon Frost 1167 Arm Limited 1168 Email: Simon.Frost@arm.com 1170 Mathias Brossard 1171 Arm Limited 1172 Email: Mathias.Brossard@arm.com 1174 Adrian Shaw 1175 HP Labs 1176 Email: Adrian.Shaw@hp.com 1178 Thomas Fossati 1179 Arm Limited 1180 Email: Thomas.Fossati@arm.com