idnits 2.17.1 draft-tschofenig-rats-psa-token-08.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 (24 March 2021) is 1122 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IANA-CWT' is defined on line 869, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-06 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-08 Summary: 3 errors (**), 0 flaws (~~), 4 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: 25 September 2021 A. Shaw 6 T. Fossati 7 Arm Limited 8 24 March 2021 10 Arm's Platform Security Architecture (PSA) Attestation Token 11 draft-tschofenig-rats-psa-token-08 13 Abstract 15 The Platform Security Architecture (PSA) is a family of hardware and 16 firmware security specifications, as well as open-source reference 17 implementations, to help device makers and chip manufacturers build 18 best-practice security into products. Devices that are PSA compliant 19 are able to produce attestation tokens as described in this memo, 20 which are the basis for a number of different protocols, including 21 secure provisioning and network access control. This document 22 specifies the PSA attestation token structure and semantics. 24 The PSA attestation token is a profiled Entity Attestation Token 25 (EAT). 27 This specification describes what claims are used in an attestation 28 token generated by PSA compliant systems, how these claims get 29 serialized to the wire, and how they are cryptographically protected. 31 Note to Readers 33 Source for this draft and an issue tracker can be found at 34 https://github.com/thomas-fossati/draft-psa-token 35 (https://github.com/thomas-fossati/draft-psa-token). 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on 25 September 2021. 54 Copyright Notice 56 Copyright (c) 2021 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 61 license-info) in effect on the date of publication of this document. 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. Code Components 64 extracted from this document must include Simplified BSD License text 65 as described in Section 4.e of the Trust Legal Provisions and are 66 provided without warranty as described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 72 2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 3 73 3. PSA Claims . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3.1. Caller Claims . . . . . . . . . . . . . . . . . . . . . . 4 75 3.1.1. Nonce . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3.1.2. Client ID . . . . . . . . . . . . . . . . . . . . . . 5 77 3.2. Target Identification Claims . . . . . . . . . . . . . . 5 78 3.2.1. Instance ID . . . . . . . . . . . . . . . . . . . . . 5 79 3.2.2. Implementation ID . . . . . . . . . . . . . . . . . . 6 80 3.2.3. Certification Reference . . . . . . . . . . . . . . . 6 81 3.3. Target State Claims . . . . . . . . . . . . . . . . . . . 6 82 3.3.1. Security Lifecycle . . . . . . . . . . . . . . . . . 7 83 3.3.2. Boot Seed . . . . . . . . . . . . . . . . . . . . . . 8 84 3.4. Software Inventory Claims . . . . . . . . . . . . . . . . 8 85 3.4.1. Software Components . . . . . . . . . . . . . . . . . 8 86 3.4.2. No Software Measurements . . . . . . . . . . . . . . 10 87 3.5. Verification Claims . . . . . . . . . . . . . . . . . . . 11 88 3.5.1. Verification Service Indicator . . . . . . . . . . . 11 89 3.5.2. Profile Definition . . . . . . . . . . . . . . . . . 11 90 4. Backwards Compatibility Considerations . . . . . . . . . . . 12 91 5. Token Encoding and Signing . . . . . . . . . . . . . . . . . 12 92 6. Freshness Model . . . . . . . . . . . . . . . . . . . . . . . 12 93 7. Collated CDDL . . . . . . . . . . . . . . . . . . . . . . . . 13 94 8. Security and Privacy Considerations . . . . . . . . . . . . . 15 95 9. Verification . . . . . . . . . . . . . . . . . . . . . . . . 16 96 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 97 10.1. Media Type Registration . . . . . . . . . . . . . . . . 16 98 10.2. CoAP Content-Formats Registration . . . . . . . . . . . 17 99 10.2.1. Registry Contents . . . . . . . . . . . . . . . . . 17 100 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 101 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 102 11.2. Informative References . . . . . . . . . . . . . . . . . 19 103 Appendix A. Reference Implementation . . . . . . . . . . . . . . 20 104 Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 20 105 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 21 106 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 109 1. Introduction 111 Trusted execution environments are now present in many devices, which 112 provide a safe environment to place security sensitive code such as 113 cryptography, secure boot, secure storage, and other essential 114 security functions. These security functions are typically exposed 115 through a narrow and well-defined interface, and can be used by 116 operating system libraries and applications. Various APIs have been 117 developed by Arm as part of the Platform Security Architecture [PSA] 118 framework. This document focuses on the output provided by PSA's 119 Initial Attestation API. Since the tokens are also consumed by 120 services outside the device, there is an actual need to ensure 121 interoperability. Interoperability needs are addressed here by 122 describing the exact syntax and semantics of the attestation claims, 123 and defining the way these claims are encoded and cryptographically 124 protected. 126 Further details on concepts expressed below can be found in the PSA 127 Security Model documentation [PSA-SM]. 129 2. Conventions and Definitions 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in 134 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 135 capitals, as shown here. 137 2.1. Glossary 139 RoT Root of Trust, the minimal set of software, hardware and data 140 that has to be implicitly trusted in the platform - there is no 141 software or hardware at a deeper level that can verify that the 142 Root of Trust is authentic and unmodified. An example of RoT is 143 an initial bootloader in ROM, which contains cryptographic 144 functions and credentials, running on a specific hardware 145 platform. 147 SPE Secure Processing Environment, a platform's processing 148 environment for software that provides confidentiality and 149 integrity for its runtime state, from software and hardware, 150 outside of the SPE. Contains trusted code and trusted hardware. 151 (Equivalent to Trusted Execution Environment (TEE), or "secure 152 world".) 154 NSPE Non Secure Processing Environment, the security domain outside 155 of the SPE, the Application domain, typically containing the 156 application firmware, operating systems, and general hardware. 157 (Equivalent to Rich Execution Environment (REE), or "normal 158 world".) 160 3. PSA Claims 162 This section describes the claims to be used in a PSA attestation 163 token. 165 CDDL [RFC8610] along with text descriptions is used to define each 166 claim independent of encoding. The following CDDL type(s) are reused 167 by different claims: 169 psa-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64 171 3.1. Caller Claims 173 3.1.1. Nonce 175 The Nonce claim is used to carry the challenge provided by the caller 176 to demonstrate freshness of the generated token. 178 The EAT [I-D.ietf-rats-eat] "nonce" (claim key 10) is used. The 179 following constraints apply to the "nonce-type": 181 * The length MUST be either 32, 48, or 64 bytes. 183 * Only a single nonce value is conveyed. Per [I-D.ietf-rats-eat] 184 the array notation is not used for encoding the nonce value. 186 This claim MUST be present in a PSA attestation token. 188 psa-nonce = ( 189 10 => psa-hash-type 190 ) 192 3.1.2. Client ID 194 The Client ID claim represents the security domain of the caller. 196 In PSA, a security domain is represented by a signed integer whereby 197 negative values represent callers from the NSPE and where positive 198 IDs represent callers from the SPE. The value 0 is not permitted. 200 For an example definition of client IDs, see the PSA Firmware 201 Framework [PSA-FF]. 203 It is essential that this claim is checked in the verification 204 process to ensure that a security domain, i.e., an attestation 205 endpoint, cannot spoof a report from another security domain. 207 This claim MUST be present in a PSA attestation token. 209 Note that the CDDL label used to be called arm_psa_partition_id. 211 psa-client-id-nspe-type = -2147483648...0 212 psa-client-id-spe-type = 1..2147483647 214 psa-client-id-type = psa-client-id-nspe-type / psa-client-id-spe-type 216 psa-client-id = ( 217 psa-client-id-key => psa-client-id-type 218 ) 220 3.2. Target Identification Claims 222 3.2.1. Instance ID 224 The Instance ID claim represents the unique identifier of the Initial 225 Attestation Key (IAK). The full definition is in [PSA-SM]. 227 The EAT "ueid" (claim key 11) of type RAND is used. The following 228 constraints apply to the "ueid-type": 230 * The length MUST be 33 bytes. 232 * The first byte MUST be 0x01 (RAND) followed by the 32-bytes key 233 hash. 235 This claim MUST be present in a PSA attestation token. 237 psa-instance-id-type = bytes .size 33 239 psa-instance-id = ( 240 11 => psa-instance-id-type 241 ) 243 3.2.2. Implementation ID 245 The Implementation ID claim uniquely identifies the underlying 246 immutable PSA RoT. A verification service can use this claim to 247 locate the details of the verification process. Such details include 248 the implementation's origin and associated certification state. The 249 full definition is in [PSA-SM]. 251 This claim MUST be present in a PSA attestation token. 253 psa-implementation-id-type = bytes .size 32 255 psa-implementation-id = ( 256 psa-implementation-id-key => psa-implementation-id-type 257 ) 259 3.2.3. Certification Reference 261 The Certification Reference claim is used to link the class of chip 262 and PSA RoT of the attesting device to an associated entry in the PSA 263 Certification database. It MUST be represented as a thirteen-digit 264 [EAN-13]. 266 Linking to the PSA Certification entry can still be achieved if this 267 claim is not present in the token by making an association at a 268 Verifier between the reference value and other token claim values - 269 for example, the Implementation ID. 271 psa-certification-reference-type = text .regexp "[0-9]{13}" 273 psa-certification-reference = ( 274 ? psa-certification-reference-key => 275 psa-certification-reference-type 276 ) 278 3.3. Target State Claims 279 3.3.1. Security Lifecycle 281 The Security Lifecycle claim represents the current lifecycle state 282 of the PSA RoT. The state is represented by an integer that is 283 divided to convey a major state and a minor state. A major state is 284 mandatory and defined by [PSA-SM]. A minor state is optional and 285 'IMPLEMENTATION DEFINED'. The PSA security lifecycle state and 286 implementation state are encoded as follows: 288 * version[15:8] - PSA security lifecycle state, and 290 * version[7:0] - IMPLEMENTATION DEFINED state. 292 The PSA lifecycle states are illustrated in Figure 1. For PSA, a 293 remote verifier can only trust reports from the PSA RoT when it is in 294 SECURED or NON_PSA_ROT_DEBUG major states. 296 This claim MUST be present in a PSA attestation token. 298 .----------------------. 299 .--- Enrol ---+ Provisioning Lockdown | 300 | '-----------+----------' 301 | | .------------------. 302 | | | | 303 * v v | 304 .--------------. .---------. | 305 | Verifier | .---------+ Secured +-----------. | 306 '--------------' | '-+-------' | | 307 * | | ^ | | 308 | | v | v | 309 Blacklist | .------------+------. .----------+----. 310 | | | Non-PSA RoT Debug | | Recoverable | 311 | | '---------+---------' | PSA RoT Debug | 312 .-+-----------+-. | '------+--------' 313 | Terminate +------------+-------------------' 314 '------+--------' 315 | .----------------. 316 '------------>| Decommissioned | 317 '----------------' 319 Figure 1: PSA Lifecycle States 321 psa-lifecycle-unknown-type = 0x0000..0x00ff 322 psa-lifecycle-assembly-and-test-type = 0x1000..0x10ff 323 psa-lifecycle-psa-rot-provisioning-type = 0x2000..0x20ff 324 psa-lifecycle-secured-type = 0x3000..0x30ff 325 psa-lifecycle-non-psa-rot-debug-type = 0x4000..0x40ff 326 psa-lifecycle-recoverable-psa-rot-debug-type = 0x5000..0x50ff 327 psa-lifecycle-decommissioned-type = 0x6000..0x60ff 329 psa-lifecycle-type = 330 psa-lifecycle-unknown-type / 331 psa-lifecycle-assembly-and-test-type / 332 psa-lifecycle-psa-rot-provisioning-type / 333 psa-lifecycle-secured-type / 334 psa-lifecycle-non-psa-rot-debug-type / 335 psa-lifecycle-recoverable-psa-rot-debug-type / 336 psa-lifecycle-decommissioned-type 338 psa-lifecycle = ( 339 psa-lifecycle-key => psa-lifecycle-type 340 ) 342 3.3.2. Boot Seed 344 The Boot Seed claim represents a random value created at system boot 345 time that will allow differentiation of reports from different boot 346 sessions. 348 This claim MUST be present in a PSA attestation token. 350 psa-boot-seed-type = bytes .size 32 352 psa-boot-seed = ( 353 psa-boot-seed-key => psa-boot-seed-type 354 ) 356 3.4. Software Inventory Claims 358 3.4.1. Software Components 360 The Software Components claim is a list of software components that 361 includes all the software loaded by the PSA RoT. This claim SHALL be 362 included in attestation tokens produced by an implementation 363 conformant with [PSA-SM]. If the Software Components claim is 364 present, then the No Software Measurement claim (Section 3.4.2) MUST 365 NOT be present. 367 Each entry in the Software Components list describes one software 368 component using the attributes described in the following 369 subsections. Unless explicitly stated, the presence of an attribute 370 is OPTIONAL. 372 Note that, as described in [I-D.ietf-rats-architecture], a relying 373 party will typically see the result of the verification process from 374 the Verifier in form of an attestation result, rather than the 375 "naked" PSA token from the attesting endpoint. Therefore, a relying 376 party is not expected to understand the Software Components claim. 377 Instead, it is for the Verifier to check this claim against the 378 available endorsements and provide an answer in form of an "high 379 level" attestation result, which may or may not include the original 380 Software Components claim. 382 psa-software-component = { 383 ? 1 => text, ; measurement type 384 2 => psa-hash-type, ; measurement value 385 ? 4 => text, ; version 386 5 => psa-hash-type, ; signer id 387 ? 6 => text, ; measurement description 388 } 390 psa-software-components = ( 391 psa-software-components-key => [ + psa-software-component ] 392 ) 394 3.4.1.1. Measurement Type 396 The Measurement Type attribute (key=1) is short string representing 397 the role of this software component. 399 The following measurement types MAY be used: 401 * "BL": a Boot Loader 403 * "PRoT": a component of the PSA Root of Trust 405 * "ARoT": a component of the Application Root of Trust 407 * "App": a component of the NSPE application 409 * "TS": a component of a Trusted Subsystem 411 3.4.1.2. Measurement Value 413 The Measurement Value attribute (key=2) represents a hash of the 414 invariant software component in memory at startup time. The value 415 MUST be a cryptographic hash of 256 bits or stronger. 417 This attribute MUST be present in a PSA software component. 419 3.4.1.3. Version 421 The Version attribute (key=4) is the issued software version in the 422 form of a text string. The value of this attribute will correspond 423 to the entry in the original signed manifest of the component. 425 3.4.1.4. Signer ID 427 The Signer ID attribute (key=5) is the hash of a signing authority 428 public key for the software component. The value of this attribute 429 will correspond to the entry in the original manifest for the 430 component. This can be used by a verifier to ensure the components 431 were signed by an expected trusted source. 433 This attribute MUST be present in a PSA software component to be 434 compliant with [PSA-SM]. 436 3.4.1.5. Measurement Description 438 The Measurement Description attribute (key=6) is the description of 439 the way in which the measurement value of the software component is 440 computed. The value will be a text string containing an abbreviated 441 description (or name) of the measurement method which can be used to 442 lookup the details of the method in a profile document. This 443 attribute will normally be excluded, unless there was an exception to 444 the default measurement described in the profile for a specific 445 component. 447 3.4.2. No Software Measurements 449 In the event that the implementation does not contain any software 450 measurements then the Software Components claim Section 3.4.1 can be 451 omitted but instead the token MUST include this claim to indicate 452 this is a deliberate state. The value SHOULD be 1. This claim is 453 intended for devices that are not compliant with [PSA-SM]. 455 psa-no-sw-measurements-type = 1 457 psa-no-sw-measurement = ( 458 psa-no-sw-measurement-key => psa-no-sw-measurements-type 459 ) 461 3.5. Verification Claims 463 3.5.1. Verification Service Indicator 465 The Verification Service Indicator claim is a hint used by a relying 466 party to locate a validation service for the token. The value is a 467 text string that can be used to locate the service or a URL 468 specifying the address of the service. A verifier may choose to 469 ignore this claim in favor of other information. 471 psa-verification-service-indicator-type = text 473 psa-verification-service-indicator = ( 474 ? psa-verification-service-indicator-key => 475 psa-verification-service-indicator-type 476 ) 478 3.5.2. Profile Definition 480 The Profile Definition claim encodes the unique identifier that 481 corresponds to the EAT profile described by this document. This 482 allows a receiver to assign the intended semantics to the rest of the 483 claims found in the token. 485 The EAT "profile" (claim key 18) is used. The following constraints 486 apply to its type: 488 * The URI encoding MUST be used. 490 * The value MUST be "http://arm.com/psa/2.0.0". 492 This claim MUST be present in a PSA attestation token. 494 See Section 4, for considerations about backwards compatibility with 495 previous versions of the PSA attestation token format. 497 psa-profile-type = "http://arm.com/psa/2.0.0" 499 psa-profile = ( 500 18 => psa-profile-type 501 ) 503 4. Backwards Compatibility Considerations 505 Previous versions of this specification used different claim key 506 values for the following claims: 508 * Nonce (claim key -75008); 510 * Instance ID (claim key -75009); 512 * Profile Description (claim key -75000 and value 513 "PSA_IOT_PROFILE_1"). 515 These claim keys have been retired and their use is deprecated. 517 Unless compatibility with existing infrastructure is a concern, 518 emitters (e.g., devices that implement the PSA Attestation API) 519 SHOULD produce tokens with their standard equivalent instead, as 520 described in Section 3.1.1, Section 3.2.1 and Section 3.5.2 521 respectively. 523 To simplify the transition to the token format described in this 524 document it is RECOMMENDED that receivers (e.g., PSA Attestation 525 Verifiers) accept tokens encoded according to the old profile 526 ("PROFILE_IOT_1") as well as to the new profile ("http://arm.com/ 527 psa/2.0.0"), at least for the time needed to their clients to 528 upgrade. 530 5. Token Encoding and Signing 532 The PSA attestation token is encoded in CBOR [RFC7049] format. Only 533 definite-length string, arrays, and maps are allowed. 535 Cryptographic protection is obtained by wrapping the "psa-token" map 536 in a COSE Web Token (CWT) [RFC8392]. For asymmetric key algorithms, 537 the signature structure MUST be COSE_Sign1. For symmetric key 538 algorithms, the signature structure MUST be COSE_Mac0. 540 The CWT CBOR tag (61) is not used. An application that needs to 541 exchange PSA attestation tokens can use the media type defined in 542 Section 10.1 or the CoAP Content-Format defined in Section 10.2. 544 6. Freshness Model 546 The PSA Token supports the freshness models for attestation Evidence 547 based on nonces and epoch handles (Section 10.2 and 10.3 of 548 [I-D.ietf-rats-architecture]) using the "nonce" claim to convey the 549 nonce or epoch handle supplied by the Verifier. No further 550 assumption on the specific remote attestation protocol is made. 552 7. Collated CDDL 554 psa-token = { 555 psa-nonce, 556 psa-instance-id, 557 psa-verification-service-indicator, 558 psa-profile, 559 psa-implementation-id, 560 psa-client-id, 561 psa-lifecycle, 562 psa-certification-reference, 563 psa-boot-seed, 564 ( psa-software-components // psa-no-sw-measurement ), 565 } 567 psa-profile-key = -75000 568 psa-client-id-key = -75001 569 psa-lifecycle-key = -75002 570 psa-implementation-id-key = -75003 571 psa-boot-seed-key = -75004 572 psa-certification-reference-key = -75005 573 psa-software-components-key = -75006 574 psa-no-sw-measurement-key = -75007 575 psa-nonce-key = -75008 576 psa-instance-id-key = -75009 577 psa-verification-service-indicator-key = -75010 579 psa-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64 581 psa-boot-seed-type = bytes .size 32 583 psa-boot-seed = ( 584 psa-boot-seed-key => psa-boot-seed-type 585 ) 587 psa-client-id-nspe-type = -2147483648...0 588 psa-client-id-spe-type = 1..2147483647 590 psa-client-id-type = psa-client-id-nspe-type / psa-client-id-spe-type 592 psa-client-id = ( 593 psa-client-id-key => psa-client-id-type 594 ) 596 psa-certification-reference-type = text .regexp "[0-9]{13}" 598 psa-certification-reference = ( 599 ? psa-certification-reference-key => 600 psa-certification-reference-type 601 ) 603 psa-implementation-id-type = bytes .size 32 605 psa-implementation-id = ( 606 psa-implementation-id-key => psa-implementation-id-type 607 ) 609 psa-instance-id-type = bytes .size 33 611 psa-instance-id = ( 612 11 => psa-instance-id-type 613 ) 615 psa-no-sw-measurements-type = 1 617 psa-no-sw-measurement = ( 618 psa-no-sw-measurement-key => psa-no-sw-measurements-type 619 ) 621 psa-nonce = ( 622 10 => psa-hash-type 623 ) 625 psa-profile-type = "http://arm.com/psa/2.0.0" 627 psa-profile = ( 628 18 => psa-profile-type 629 ) 631 psa-lifecycle-unknown-type = 0x0000..0x00ff 632 psa-lifecycle-assembly-and-test-type = 0x1000..0x10ff 633 psa-lifecycle-psa-rot-provisioning-type = 0x2000..0x20ff 634 psa-lifecycle-secured-type = 0x3000..0x30ff 635 psa-lifecycle-non-psa-rot-debug-type = 0x4000..0x40ff 636 psa-lifecycle-recoverable-psa-rot-debug-type = 0x5000..0x50ff 637 psa-lifecycle-decommissioned-type = 0x6000..0x60ff 639 psa-lifecycle-type = 640 psa-lifecycle-unknown-type / 641 psa-lifecycle-assembly-and-test-type / 642 psa-lifecycle-psa-rot-provisioning-type / 643 psa-lifecycle-secured-type / 644 psa-lifecycle-non-psa-rot-debug-type / 645 psa-lifecycle-recoverable-psa-rot-debug-type / 646 psa-lifecycle-decommissioned-type 648 psa-lifecycle = ( 649 psa-lifecycle-key => psa-lifecycle-type 650 ) 652 psa-software-component = { 653 ? 1 => text, ; measurement type 654 2 => psa-hash-type, ; measurement value 655 ? 4 => text, ; version 656 5 => psa-hash-type, ; signer id 657 ? 6 => text, ; measurement description 658 } 660 psa-software-components = ( 661 psa-software-components-key => [ + psa-software-component ] 662 ) 664 psa-verification-service-indicator-type = text 666 psa-verification-service-indicator = ( 667 ? psa-verification-service-indicator-key => 668 psa-verification-service-indicator-type 669 ) 671 8. Security and Privacy Considerations 673 This specification re-uses the CWT and the EAT specification. Hence, 674 the security and privacy considerations of those specifications apply 675 here as well. 677 Since CWTs offer different ways to protect the token, this 678 specification profiles those options and allows signatures based on 679 use of public key cryptography as well as MAC authentication. The 680 token MUST be signed following the structure of the COSE 681 specification [RFC8152]. The COSE type MUST be COSE_Sign1 for public 682 key signatures or COSE_Mac0 for MAC authentication. Note however 683 that use of MAC authentication is NOT RECOMMENDED due to the 684 associated infrastructure costs for key management and protocol 685 complexities. It may also restrict the ability to interoperate with 686 third parties. 688 Attestation tokens contain information that may be unique to a device 689 and therefore they may allow to single out an individual device for 690 tracking purposes. Implementations that have privacy requirements 691 must take appropriate measures to ensure that the token is only used 692 to provision anonymous/pseudonym keys. 694 9. Verification 696 To verify the token, the primary need is to check correct formation 697 and signing as for any CWT token. In addition though, the verifier 698 can operate a policy where values of some of the claims in this 699 profile can be compared to reference values, registered with the 700 verifier for a given deployment, in order to confirm that the device 701 is endorsed by the manufacturer supply chain. The policy may require 702 that the relevant claims must have a match to a registered reference 703 value. All claims may be worthy of additional appraisal. It is 704 likely that most deployments would include a policy with appraisal 705 for the following claims: 707 * Instance ID - the value of the Instance ID can be used (together 708 with the kid in the token COSE header, if present) to assist in 709 locating the public key used to verify the token signature. 711 * Implementation ID - the value of the Implementation ID can be used 712 to identify the verification requirements of the deployment. 714 * Software Component, Measurement Value - this value can uniquely 715 identify a firmware release from the supply chain. In some cases, 716 a verifier may maintain a record for a series of firmware 717 releases, being patches to an original baseline release. A 718 verification policy may then allow this value to match any point 719 on that release sequence or expect some minimum level of maturity 720 related to the sequence. 722 * Software Component, Signer ID - where present in a deployment, 723 this could allow a verifier to operate a more general policy than 724 that for Measurement Value as above, by allowing a token to 725 contain any firmware entries signed by a known Signer ID, without 726 checking for a uniquely registered version. 728 10. IANA Considerations 730 10.1. Media Type Registration 732 IANA is requested to register the "application/psa-attestation-token" 733 media type [RFC2046] in the "Media Types" registry [IANA-MediaTypes] 734 in the manner described in RFC 6838 [RFC6838], which can be used to 735 indicate that the content is a PSA Attestation Token. 737 * Type name: application 739 * Subtype name: psa-attestation-token 741 * Required parameters: n/a 742 * Optional parameters: n/a 744 * Encoding considerations: binary 746 * Security considerations: See the Security Considerations section 747 of [[this RFC]] 749 * Interoperability considerations: n/a 751 * Published specification: [[this RFC]] 753 * Applications that use this media type: Attesters and Relying 754 Parties sending PSA attestation tokens over HTTP(S), CoAP(S), and 755 other transports. 757 * Fragment identifier considerations: n/a 759 * Additional information: 761 - Magic number(s): n/a 763 - File extension(s): n/a 765 - Macintosh file type code(s): n/a 767 * Person & email address to contact for further information: Hannes 768 Tschofenig, Hannes.Tschofenig@arm.com 770 * Intended usage: COMMON 772 * Restrictions on usage: none 774 * Author: Hannes Tschofenig, Hannes.Tschofenig@arm.com 776 * Change controller: IESG 778 * Provisional registration? No 780 10.2. CoAP Content-Formats Registration 782 IANA is requested to register the CoAP Content-Format ID for the 783 "application/psa-attestation-token" media type in the "CoAP Content- 784 Formats" registry [IANA-CoAP-Content-Formats]. 786 10.2.1. Registry Contents 788 * Media Type: application/psa-attestation-token 789 * Encoding: - 791 * Id: [[To-be-assigned by IANA]] 793 * Reference: [[this RFC]] 795 11. References 797 11.1. Normative References 799 [EAN-13] GS1, "International Article Number - EAN/UPC barcodes", 800 2019, . 802 [I-D.ietf-rats-eat] 803 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 804 O'Donoghue, "The Entity Attestation Token (EAT)", Work in 805 Progress, Internet-Draft, draft-ietf-rats-eat-06, 2 806 December 2020, . 809 [PSA-FF] Arm, "Platform Security Architecture Firmware Framework 810 1.0 (PSA-FF)", February 2019, . 814 [PSA-SM] Arm, "Platform Security Architecture Security Model 1.0 815 (PSA-SM)", February 2019, . 819 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 820 Extensions (MIME) Part Two: Media Types", RFC 2046, 821 DOI 10.17487/RFC2046, November 1996, 822 . 824 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 825 Requirement Levels", BCP 14, RFC 2119, 826 DOI 10.17487/RFC2119, March 1997, 827 . 829 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 830 Specifications and Registration Procedures", BCP 13, 831 RFC 6838, DOI 10.17487/RFC6838, January 2013, 832 . 834 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 835 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 836 October 2013, . 838 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 839 RFC 8152, DOI 10.17487/RFC8152, July 2017, 840 . 842 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 843 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 844 May 2017, . 846 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 847 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 848 May 2018, . 850 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 851 Definition Language (CDDL): A Notational Convention to 852 Express Concise Binary Object Representation (CBOR) and 853 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 854 June 2019, . 856 11.2. Informative References 858 [I-D.ietf-rats-architecture] 859 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 860 W. Pan, "Remote Attestation Procedures Architecture", Work 861 in Progress, Internet-Draft, draft-ietf-rats-architecture- 862 08, 8 December 2020, . 865 [IANA-CoAP-Content-Formats] 866 IANA, "CoAP Content-Formats", 2021, 867 . 869 [IANA-CWT] IANA, "CBOR Web Token (CWT) Claims", 2021, 870 . 872 [IANA-MediaTypes] 873 IANA, "Media Types", 2021, 874 . 876 [PSA] Arm, "Platform Security Architecture Resources", 2021, 877 . 881 [TF-M] Linaro, "Trusted Firmware-M", 2021, 882 . 884 Appendix A. Reference Implementation 886 A reference implementation is provided by the Trusted Firmware 887 project [TF-M]. 889 Appendix B. Example 891 The following example shows a PSA attestation token for an 892 hypothetical system comprising two measured software components (a 893 boot loader and a trusted RTOS). The attesting device is in a 894 lifecycle state Section 3.3.1 of SECURED. The attestation has been 895 requested from a client residing in the SPE: 897 { 898 / profile / 18: "http://arm.com/psa/2.0.0", 899 / psa-client-id / -75001: 1, 900 / psa-lifecycle / -75002: 12288, 901 / psa-implementation-id / -75003: h'50515253545556575051 902 52535455565750515253545556575051525354555657', 903 / psa-boot-seed / -75004: h'DEADBEEFDEADBEEFDEAD 904 BEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEF', 905 / psa-certification-reference / -75005: "1234567890123", 906 / psa-software-components / -75006: [ 907 { 908 / measurement type / 1: "BL", 909 / measurement value / 2: h'0001020400010204000102040001020 910 400010204000102040001020400010204', 911 / signer ID / 5: h'519200FF519200FF519200FF519200F 912 F519200FF519200FF519200FF519200FF' 913 }, 914 { 915 / measurement type / 1: "PRoT", 916 / measurement value / 2: h'0506070805060708050607080506070 917 805060708050607080506070805060708', 918 / signer ID / 5: h'519200FF519200FF519200FF519200F 919 F519200FF519200FF519200FF519200FF' 920 } 921 ], 922 / nonce / 10: h'00010203000102030001020300010203 923 00010203000102030001020300010203', 924 / ueid / 11: h'01A0A1A2A3A0A1A2A3A0A1A2A3A0A1A2 925 A3A0A1A2A3A0A1A2A3A0A1A2A3A0A1A2A3', 926 / psa-verification-service-indicator / -75010: "https://psa-ve 927 rifier.org" 928 } 930 The JWK representation of the IAK used for creating the COSE Sign1 931 signature over the PSA token is: 933 { 934 "kty": "EC", 935 "crv": "P-256", 936 "x": "MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4", 937 "y": "4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM", 938 "d": "870MB6gfuTJ4HtUnUvYMyJpr5eUZNP4Bk43bVdj3eAE", 939 "use": "enc", 940 "kid": "1" 941 } 943 The resulting COSE object is: 945 18( 946 [ 947 / protected / h'A10126', 948 / unprotected / {}, 949 / payload / h'AD127818687474703A2F2F61726D2E636F6D2F7073 950 612F322E302E303A000124F8013A000124F91930003A000124FA582050515253 951 545556575051525354555657505152535455565750515253545556573A000124 952 FB5820DEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEFDE 953 ADBEEF3A000124FC6D313233343536373839303132333A000124FD82A3016242 954 4C02582000010204000102040001020400010204000102040001020400010204 955 00010204055820519200FF519200FF519200FF519200FF519200FF519200FF51 956 9200FF519200FFA3016450526F54025820050607080506070805060708050607 957 0805060708050607080506070805060708055820519200FF519200FF519200FF 958 519200FF519200FF519200FF519200FF519200FF0A5820000102030001020300 959 01020300010203000102030001020300010203000102030B582101A0A1A2A3A0 960 A1A2A3A0A1A2A3A0A1A2A3A0A1A2A3A0A1A2A3A0A1A2A3A0A1A2A33A00012501 961 781868747470733A2F2F7073612D76657269666965722E6F72673A00012500F6 962 3A000124F7F63A000124FFF6', 963 / signature / h'8C92FDC99CFDB0016F27008744B3730266342D2881 964 861DC9A3F89E02394DE7F906EE2D1A3C164A59D580CDD7DFA077290CBFB55069 965 C55A5D9A2AE17FA31D2108' 966 ] 967 ) 969 Contributors 971 We would like to thank the following colleagues for their 972 contributions: 974 * Laurence Lundblade 975 Security Theory LLC 976 lgl@securitytheory.com 978 * Tamas Ban 979 Arm Limited 980 Tamas.Ban@arm.com 982 * Sergei Trofimov 983 Arm Limited 984 Sergei.Trofimov@arm.com 986 Acknowledgments 988 Thanks to Carsten Bormann for help with the CDDL and Nicholas Wood 989 for ideas and comments. 991 Authors' Addresses 993 Hannes Tschofenig 994 Arm Limited 996 Email: Hannes.Tschofenig@arm.com 998 Simon Frost 999 Arm Limited 1001 Email: Simon.Frost@arm.com 1003 Mathias Brossard 1004 Arm Limited 1006 Email: Mathias.Brossard@arm.com 1008 Adrian Shaw 1009 Arm Limited 1011 Email: Adrian.Shaw@arm.com 1013 Thomas Fossati 1014 Arm Limited 1016 Email: Thomas.Fossati@arm.com