idnits 2.17.1 draft-tschofenig-rats-psa-token-06.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 (1 December 2020) is 1241 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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-07 == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-04 Summary: 3 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: 4 June 2021 A. Shaw 6 T. Fossati 7 Arm Limited 8 1 December 2020 10 Arm's Platform Security Architecture (PSA) Attestation Token 11 draft-tschofenig-rats-psa-token-06 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 At its core, the CWT (COSE Web Token) format is used and populated 25 with a set of claims in a way similar to EAT (Entity Attestation 26 Token). This specification describes what claims are used by PSA 27 compliant systems. 29 Note to Readers 31 Source for this draft and an issue tracker can be found at 32 https://github.com/thomas-fossati/draft-psa-token 33 (https://github.com/thomas-fossati/draft-psa-token). 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on 4 June 2021. 51 Copyright Notice 53 Copyright (c) 2020 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 58 license-info) in effect on the date of publication of this document. 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. Code Components 61 extracted from this document must include Simplified BSD License text 62 as described in Section 4.e of the Trust Legal Provisions and are 63 provided without warranty as described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 69 2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. PSA Claims . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.1. Caller Claims . . . . . . . . . . . . . . . . . . . . . . 4 72 3.1.1. Nonce . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3.1.2. Client ID . . . . . . . . . . . . . . . . . . . . . . 5 74 3.2. Target Identification Claims . . . . . . . . . . . . . . 5 75 3.2.1. Instance ID . . . . . . . . . . . . . . . . . . . . . 5 76 3.2.2. Implementation ID . . . . . . . . . . . . . . . . . . 6 77 3.2.3. Certification Reference . . . . . . . . . . . . . . . 6 78 3.3. Target State Claims . . . . . . . . . . . . . . . . . . . 6 79 3.3.1. Security Lifecycle . . . . . . . . . . . . . . . . . 6 80 3.3.2. Boot Seed . . . . . . . . . . . . . . . . . . . . . . 8 81 3.4. Software Inventory Claims . . . . . . . . . . . . . . . . 8 82 3.4.1. Software Components . . . . . . . . . . . . . . . . . 8 83 3.4.2. No Software Measurements . . . . . . . . . . . . . . 10 84 3.5. Verification Claims . . . . . . . . . . . . . . . . . . . 11 85 3.5.1. Verification Service Indicator . . . . . . . . . . . 11 86 3.5.2. Profile Definition . . . . . . . . . . . . . . . . . 11 87 4. Token Encoding and Signing . . . . . . . . . . . . . . . . . 11 88 5. Collated CDDL . . . . . . . . . . . . . . . . . . . . . . . . 11 89 6. Security and Privacy Considerations . . . . . . . . . . . . . 14 90 7. Verification . . . . . . . . . . . . . . . . . . . . . . . . 15 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 92 8.1. CBOR Web Token Claims Registration . . . . . . . . . . . 15 93 8.1.1. Nonce Claim . . . . . . . . . . . . . . . . . . . . . 15 94 8.1.2. Client ID Claim . . . . . . . . . . . . . . . . . . . 16 95 8.1.3. Instance ID Claim . . . . . . . . . . . . . . . . . . 16 96 8.1.4. Implementation ID Claim . . . . . . . . . . . . . . . 16 97 8.1.5. Certification Reference Claim . . . . . . . . . . . . 17 98 8.1.6. Security Lifecycle Claim . . . . . . . . . . . . . . 17 99 8.1.7. Boot Seed Claim . . . . . . . . . . . . . . . . . . . 17 100 8.1.8. Software Components Claim . . . . . . . . . . . . . . 18 101 8.1.9. No Software Measurements Claim . . . . . . . . . . . 18 102 8.1.10. Verification Service Indicator Claim . . . . . . . . 18 103 8.1.11. Profile Definition Claim . . . . . . . . . . . . . . 19 104 8.2. Media Type Registration . . . . . . . . . . . . . . . . . 19 105 8.3. CoAP Content-Formats Registration . . . . . . . . . . . . 20 106 8.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 20 107 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 108 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 109 9.2. Informative References . . . . . . . . . . . . . . . . . 22 110 Appendix A. Reference Implementation . . . . . . . . . . . . . . 22 111 Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 22 112 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24 113 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 116 1. Introduction 118 Trusted execution environments are now present in many devices, which 119 provide a safe environment to place security sensitive code such as 120 cryptography, secure boot, secure storage, and other essential 121 security functions. These security functions are typically exposed 122 through a narrow and well-defined interface, and can be used by 123 operating system libraries and applications. Various APIs have been 124 developed by Arm as part of the Platform Security Architecture [PSA] 125 framework. This document focuses on the output provided by PSA's 126 Initial Attestation API. Since the tokens are also consumed by 127 services outside the device, there is an actual need to ensure 128 interoperability. Interoperability needs are addressed here by 129 describing the exact syntax and semantics of the attestation claims, 130 and defining the way these claims are encoded and cryptographically 131 protected. 133 Further details on concepts expressed below can be found in the PSA 134 Security Model documentation [PSA-SM]. 136 2. Conventions and Definitions 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in 141 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 142 capitals, as shown here. 144 2.1. Glossary 146 RoT Root of Trust, the minimal set of software, hardware and data 147 that has to be implicitly trusted in the platform - there is no 148 software or hardware at a deeper level that can verify that the 149 Root of Trust is authentic and unmodified. An example of RoT is 150 an initial bootloader in ROM, which contains cryptographic 151 functions and credentials, running on a specific hardware 152 platform. 154 SPE Secure Processing Environment, a platform's processing 155 environment for software that provides confidentiality and 156 integrity for its runtime state, from software and hardware, 157 outside of the SPE. Contains trusted code and trusted hardware. 158 (Equivalent to Trusted Execution Environment (TEE), or "secure 159 world".) 161 NSPE Non Secure Processing Environment, the security domain outside 162 of the SPE, the Application domain, typically containing the 163 application firmware, operating systems, and general hardware. 164 (Equivalent to Rich Execution Environment (REE), or "normal 165 world".) 167 3. PSA Claims 169 This section describes the claims to be used in a PSA attestation 170 token. 172 CDDL [RFC8610] along with text descriptions is used to define each 173 claim independent of encoding. The following CDDL type(s) are reused 174 by different claims: 176 psa-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64 178 3.1. Caller Claims 180 3.1.1. Nonce 182 The Nonce claim is a challenge from the caller. The length must be 183 32, 48, or 64 bytes. 185 This claim MUST be present in a PSA attestation token. 187 psa-nonce = ( 188 psa-nonce-key => psa-hash-type 189 ) 191 3.1.2. Client ID 193 The Client ID claim represents the security domain of the caller. 195 In PSA, a security domain is represented by a signed integer whereby 196 negative values represent callers from the NSPE and where positive 197 IDs represent callers from the SPE. The value 0 is not permitted. 199 For an example definition of client IDs, see the PSA Firmware 200 Framework [PSA-FF]. 202 It is essential that this claim is checked in the verification 203 process to ensure that a security domain, i.e., an attestation 204 endpoint, cannot spoof a report from another security domain. 206 This claim MUST be present in a PSA attestation token. 208 Note that the CDDL label used to be called arm_psa_partition_id. 210 psa-client-id-nspe-type = -2147483648...0 211 psa-client-id-spe-type = 1..2147483647 213 psa-client-id-type = psa-client-id-nspe-type / psa-client-id-spe-type 215 psa-client-id = ( 216 psa-client-id-key => psa-client-id-type 217 ) 219 3.2. Target Identification Claims 221 3.2.1. Instance ID 223 The Instance ID claim represents the unique identifier of the device 224 instance. It is a 32 bytes hash of the public key corresponding to 225 the Initial Attestation Key (IAK). If the IAK is a symmetric key 226 then the Instance ID is a hash of the hash of the IAK itself. It is 227 encoded as a Universal Entity ID of type RAND [I-D.ietf-rats-eat], 228 i.e., prepending a 0x01 type byte to the key hash. The full 229 definition is in [PSA-SM]. 231 This claim MUST be present in a PSA attestation token. 233 psa-instance-id-type = bytes .size 33 235 psa-instance-id = ( 236 psa-instance-id-key => psa-instance-id-type 237 ) 239 3.2.2. Implementation ID 241 The Implementation ID claim uniquely identifies the underlying 242 immutable PSA RoT. A verification service can use this claim to 243 locate the details of the verification process. Such details include 244 the implementation's origin and associated certification state. The 245 full definition is in [PSA-SM]. 247 This claim MUST be present in a PSA attestation token. 249 psa-implementation-id-type = bytes .size 32 251 psa-implementation-id = ( 252 psa-implementation-id-key => psa-implementation-id-type 253 ) 255 3.2.3. Certification Reference 257 The Certification Reference claim is used to link the class of chip 258 and PSA RoT of the attesting device to an associated entry in the PSA 259 Certification database. It MUST be represented as a thirteen-digit 260 [EAN-13]. 262 Linking to the PSA Certification entry can still be achieved if this 263 claim is not present in the token by making an association at a 264 Verifier between the reference value and other token claim values - 265 for example, the Implementation ID. 267 psa-certification-reference-type = text .regexp "[0-9]{13}" 269 psa-certification-reference = ( 270 ? psa-certification-reference-key => 271 psa-certification-reference-type 272 ) 274 3.3. Target State Claims 276 3.3.1. Security Lifecycle 278 The Security Lifecycle claim represents the current lifecycle state 279 of the PSA RoT. The state is represented by an integer that is 280 divided to convey a major state and a minor state. A major state is 281 mandatory and defined by [PSA-SM]. A minor state is optional and 282 'IMPLEMENTATION DEFINED'. The PSA security lifecycle state and 283 implementation state are encoded as follows: 285 * version[15:8] - PSA security lifecycle state, and 286 * version[7:0] - IMPLEMENTATION DEFINED state. 288 The PSA lifecycle states are illustrated in Figure 1. For PSA, a 289 remote verifier can only trust reports from the PSA RoT when it is in 290 SECURED or NON_PSA_ROT_DEBUG major states. 292 This claim MUST be present in a PSA attestation token. 294 .----------------------. 295 .--- Enrol ---+ Provisioning Lockdown | 296 | '-----------+----------' 297 | | .------------------. 298 | | | | 299 * v v | 300 .--------------. .---------. | 301 | Verifier | .---------+ Secured +-----------. | 302 '--------------' | '-+-------' | | 303 * | | ^ | | 304 | | v | v | 305 Blacklist | .------------+------. .----------+----. 306 | | | Non-PSA RoT Debug | | Recoverable | 307 | | '---------+---------' | PSA RoT Debug | 308 .-+-----------+-. | '------+--------' 309 | Terminate +------------+-------------------' 310 '------+--------' 311 | .----------------. 312 '------------>| Decommissioned | 313 '----------------' 315 Figure 1: PSA Lifecycle States 317 psa-lifecycle-unknown-type = 0x0000..0x00ff 318 psa-lifecycle-assembly-and-test-type = 0x1000..0x10ff 319 psa-lifecycle-psa-rot-provisioning-type = 0x2000..0x20ff 320 psa-lifecycle-secured-type = 0x3000..0x30ff 321 psa-lifecycle-non-psa-rot-debug-type = 0x4000..0x40ff 322 psa-lifecycle-recoverable-psa-rot-debug-type = 0x5000..0x50ff 323 psa-lifecycle-decommissioned-type = 0x6000..0x60ff 325 psa-lifecycle-type = 326 psa-lifecycle-unknown-type / 327 psa-lifecycle-assembly-and-test-type / 328 psa-lifecycle-psa-rot-provisioning-type / 329 psa-lifecycle-secured-type / 330 psa-lifecycle-non-psa-rot-debug-type / 331 psa-lifecycle-recoverable-psa-rot-debug-type / 332 psa-lifecycle-decommissioned-type 334 psa-lifecycle = ( 335 psa-lifecycle-key => psa-lifecycle-type 336 ) 338 3.3.2. Boot Seed 340 The Boot Seed claim represents a random value created at system boot 341 time that will allow differentiation of reports from different boot 342 sessions. 344 This claim MUST be present in a PSA attestation token. 346 psa-boot-seed-type = bytes .size 32 348 psa-boot-seed = ( 349 psa-boot-seed-key => psa-boot-seed-type 350 ) 352 3.4. Software Inventory Claims 354 3.4.1. Software Components 356 The Software Components claim is a list of software components that 357 includes all the software loaded by the PSA RoT. This claim SHALL be 358 included in attestation tokens produced by an implementation 359 conformant with [PSA-SM]. If the Software Components claim is 360 present, then the No Software Measurement claim (Section 3.4.2) MUST 361 NOT be present. 363 Each entry in the Software Components list describes one software 364 component using the attributes described in the following 365 subsections. Unless explicitly stated, the presence of an attribute 366 is OPTIONAL. 368 Note that, as described in [I-D.ietf-rats-architecture], a relying 369 party will typically see the result of the verification process from 370 the Verifier in form of an attestation result, rather than the 371 "naked" PSA token from the attesting endpoint. Therefore, a relying 372 party is not expected to understand the Software Components claim. 373 Instead, it is for the Verifier to check this claim against the 374 available endorsements and provide an answer in form of an "high 375 level" attestation result, which may or may not include the original 376 Software Components claim. 378 psa-software-component = { 379 ? 1 => text, ; measurement type 380 2 => psa-hash-type, ; measurement value 381 ? 4 => text, ; version 382 5 => psa-hash-type, ; signer id 383 ? 6 => text, ; measurement description 384 } 386 psa-software-components = ( 387 psa-software-components-key => [ + psa-software-component ] 388 ) 390 3.4.1.1. Measurement Type 392 The Measurement Type attribute (key=1) is short string representing 393 the role of this software component. 395 The following measurement types MAY be used: 397 * "BL": a Boot Loader 399 * "PRoT": a component of the PSA Root of Trust 401 * "ARoT": a component of the Application Root of Trust 403 * "App": a component of the NSPE application 405 * "TS": a component of a Trusted Subsystem 407 3.4.1.2. Measurement Value 409 The Measurement Value attribute (key=2) represents a hash of the 410 invariant software component in memory at startup time. The value 411 MUST be a cryptographic hash of 256 bits or stronger. 413 This attribute MUST be present in a PSA software component. 415 3.4.1.3. Version 417 The Version attribute (key=4) is the issued software version in the 418 form of a text string. The value of this attribute will correspond 419 to the entry in the original signed manifest of the component. 421 3.4.1.4. Signer ID 423 The Signer ID attribute (key=5) is the hash of a signing authority 424 public key for the software component. The value of this attribute 425 will correspond to the entry in the original manifest for the 426 component. This can be used by a verifier to ensure the components 427 were signed by an expected trusted source. 429 This attribute MUST be present in a PSA software component to be 430 compliant with [PSA-SM]. 432 3.4.1.5. Measurement Description 434 The Measurement Description attribute (key=6) is the description of 435 the way in which the measurement value of the software component is 436 computed. The value will be a text string containing an abbreviated 437 description (or name) of the measurement method which can be used to 438 lookup the details of the method in a profile document. This 439 attribute will normally be excluded, unless there was an exception to 440 the default measurement described in the profile for a specific 441 component. 443 3.4.2. No Software Measurements 445 In the event that the implementation does not contain any software 446 measurements then the Software Components claim Section 3.4.1 can be 447 omitted but instead the token MUST include this claim to indicate 448 this is a deliberate state. The value SHOULD be 1. This claim is 449 intended for devices that are not compliant with [PSA-SM]. 451 psa-no-sw-measurements-type = 1 453 psa-no-sw-measurement = ( 454 psa-no-sw-measurement-key => psa-no-sw-measurements-type 455 ) 457 3.5. Verification Claims 459 3.5.1. Verification Service Indicator 461 The Verification Service Indicator claim is a hint used by a relying 462 party to locate a validation service for the token. The value is a 463 text string that can be used to locate the service or a URL 464 specifying the address of the service. A verifier may choose to 465 ignore this claim in favor of other information. 467 psa-verification-service-indicator-type = text 469 psa-verification-service-indicator = ( 470 ? psa-verification-service-indicator-key => 471 psa-verification-service-indicator-type 472 ) 474 3.5.2. Profile Definition 476 The Profile Definition claim contains the name of a document that 477 describes the "profile" of the report. The document name may include 478 versioning. The value for this specification MUST be 479 PSA_IOT_PROFILE_1. 481 psa-profile-type = "PSA_IOT_PROFILE_1" 483 psa-profile = ( 484 ? psa-profile-key => psa-profile-type 485 ) 487 4. Token Encoding and Signing 489 The report is encoded as a COSE Web Token (CWT) [RFC8392], similar to 490 the Entity Attestation Token (EAT) [I-D.ietf-rats-eat]. The token 491 consists of a series of claims declaring evidence as to the nature of 492 the instance of hardware and software. The claims are encoded in 493 CBOR [RFC7049] format. For asymmetric key algorithms, the signature 494 structure MUST be COSE_Sign1. For symmetric key algorithms, the 495 structure MUST be COSE_Mac0. 497 5. Collated CDDL 498 psa-token = { 499 psa-nonce, 500 psa-instance-id, 501 psa-verification-service-indicator, 502 psa-profile, 503 psa-implementation-id, 504 psa-client-id, 505 psa-lifecycle, 506 psa-certification-reference, 507 psa-boot-seed, 508 ( psa-software-components // psa-no-sw-measurement ), 509 } 511 psa-profile-key = -75000 512 psa-client-id-key = -75001 513 psa-lifecycle-key = -75002 514 psa-implementation-id-key = -75003 515 psa-boot-seed-key = -75004 516 psa-certification-reference-key = -75005 517 psa-software-components-key = -75006 518 psa-no-sw-measurement-key = -75007 519 psa-nonce-key = -75008 520 psa-instance-id-key = -75009 521 psa-verification-service-indicator-key = -75010 523 psa-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64 525 psa-boot-seed-type = bytes .size 32 527 psa-boot-seed = ( 528 psa-boot-seed-key => psa-boot-seed-type 529 ) 531 psa-client-id-nspe-type = -2147483648...0 532 psa-client-id-spe-type = 1..2147483647 534 psa-client-id-type = psa-client-id-nspe-type / psa-client-id-spe-type 536 psa-client-id = ( 537 psa-client-id-key => psa-client-id-type 538 ) 540 psa-certification-reference-type = text .regexp "[0-9]{13}" 542 psa-certification-reference = ( 543 ? psa-certification-reference-key => 544 psa-certification-reference-type 545 ) 546 psa-implementation-id-type = bytes .size 32 548 psa-implementation-id = ( 549 psa-implementation-id-key => psa-implementation-id-type 550 ) 552 psa-instance-id-type = bytes .size 33 554 psa-instance-id = ( 555 psa-instance-id-key => psa-instance-id-type 556 ) 558 psa-no-sw-measurements-type = 1 560 psa-no-sw-measurement = ( 561 psa-no-sw-measurement-key => psa-no-sw-measurements-type 562 ) 564 psa-nonce = ( 565 psa-nonce-key => psa-hash-type 566 ) 568 psa-profile-type = "PSA_IOT_PROFILE_1" 570 psa-profile = ( 571 ? psa-profile-key => psa-profile-type 572 ) 574 psa-lifecycle-unknown-type = 0x0000..0x00ff 575 psa-lifecycle-assembly-and-test-type = 0x1000..0x10ff 576 psa-lifecycle-psa-rot-provisioning-type = 0x2000..0x20ff 577 psa-lifecycle-secured-type = 0x3000..0x30ff 578 psa-lifecycle-non-psa-rot-debug-type = 0x4000..0x40ff 579 psa-lifecycle-recoverable-psa-rot-debug-type = 0x5000..0x50ff 580 psa-lifecycle-decommissioned-type = 0x6000..0x60ff 582 psa-lifecycle-type = 583 psa-lifecycle-unknown-type / 584 psa-lifecycle-assembly-and-test-type / 585 psa-lifecycle-psa-rot-provisioning-type / 586 psa-lifecycle-secured-type / 587 psa-lifecycle-non-psa-rot-debug-type / 588 psa-lifecycle-recoverable-psa-rot-debug-type / 589 psa-lifecycle-decommissioned-type 591 psa-lifecycle = ( 592 psa-lifecycle-key => psa-lifecycle-type 593 ) 594 psa-software-component = { 595 ? 1 => text, ; measurement type 596 2 => psa-hash-type, ; measurement value 597 ? 4 => text, ; version 598 5 => psa-hash-type, ; signer id 599 ? 6 => text, ; measurement description 600 } 602 psa-software-components = ( 603 psa-software-components-key => [ + psa-software-component ] 604 ) 606 psa-verification-service-indicator-type = text 608 psa-verification-service-indicator = ( 609 ? psa-verification-service-indicator-key => 610 psa-verification-service-indicator-type 611 ) 613 6. Security and Privacy Considerations 615 This specification re-uses the CWT and the EAT specification. Hence, 616 the security and privacy considerations of those specifications apply 617 here as well. 619 Since CWTs offer different ways to protect the token, this 620 specification profiles those options and allows signatures based on 621 use of public key cryptography as well as MAC authentication. The 622 token MUST be signed following the structure of the COSE 623 specification [RFC8152]. The COSE type MUST be COSE_Sign1 for public 624 key signatures or COSE_Mac0 for MAC authentication. Note however 625 that use of MAC authentication is NOT RECOMMENDED due to the 626 associated infrastructure costs for key management and protocol 627 complexities. It may also restrict the ability to interoperate with 628 third parties. 630 Attestation tokens contain information that may be unique to a device 631 and therefore they may allow to single out an individual device for 632 tracking purposes. Implementations that have privacy requirements 633 must take appropriate measures to ensure that the token is only used 634 to provision anonymous/pseudonym keys. 636 7. Verification 638 To verify the token, the primary need is to check correct formation 639 and signing as for any CWT token. In addition though, the verifier 640 can operate a policy where values of some of the claims in this 641 profile can be compared to reference values, registered with the 642 verifier for a given deployment, in order to confirm that the device 643 is endorsed by the manufacturer supply chain. The policy may require 644 that the relevant claims must have a match to a registered reference 645 value. All claims may be worthy of additional appraisal. It is 646 likely that most deployments would include a policy with appraisal 647 for the following claims: 649 * Instance ID - the value of the Instance ID can be used (together 650 with the kid in the token COSE header, if present) to assist in 651 locating the public key used to verify the token signature. 653 * Implementation ID - the value of the Implementation ID can be used 654 to identify the verification requirements of the deployment. 656 * Software Component, Measurement Value - this value can uniquely 657 identify a firmware release from the supply chain. In some cases, 658 a verifier may maintain a record for a series of firmware 659 releases, being patches to an original baseline release. A 660 verification policy may then allow this value to match any point 661 on that release sequence or expect some minimum level of maturity 662 related to the sequence. 664 * Software Component, Signer ID - where present in a deployment, 665 this could allow a verifier to operate a more general policy than 666 that for Measurement Value as above, by allowing a token to 667 contain any firmware entries signed by a known Signer ID, without 668 checking for a uniquely registered version. 670 8. IANA Considerations 672 8.1. CBOR Web Token Claims Registration 674 This specification registers the following claims in the IANA "CBOR 675 Web Token (CWT) Claims" registry [IANA-CWT], established by 676 [RFC8392]. 678 8.1.1. Nonce Claim 680 * Claim Name: "psa-nonce" 682 * Claim Description: Nonce 683 * JWT Claim Name: "psa-nonce" 685 * Claim Key: [[Proposed: -75008]] 687 * Claim Value Type(s): bytes (32, 48, or 64 bytes in length) 689 * Change Controller: [[Authors of this RFC]] 691 * Specification Document(s): Section 3.1.1 of [[this RFC]] 693 8.1.2. Client ID Claim 695 * Claim Name: "psa-client-id" 697 * Claim Description: Client ID 699 * JWT Claim Name: "psa-client-id" 701 * Claim Key: [[Proposed: -75001]] 703 * Claim Value Type(s): signed integer 705 * Change Controller: [[Authors of this RFC]] 707 * Specification Document(s): Section 3.1.2 of [[this RFC]] 709 8.1.3. Instance ID Claim 711 * Claim Name: "psa-instance-id" 713 * Claim Description: Instance ID 715 * JWT Claim Name: "psa-instance-id" 717 * Claim Key: [[Proposed: -75009]] 719 * Claim Value Type(s): bytes (33 bytes in length) 721 * Change Controller: [[Authors of this RFC]] 723 * Specification Document(s): Section 3.2.1 of [[this RFC]] 725 8.1.4. Implementation ID Claim 727 * Claim Name: "psa-implementation-id" 729 * Claim Description: Implementation ID 730 * JWT Claim Name: "psa-implementation-id" 732 * Claim Key: [[Proposed: -75003]] 734 * Claim Value Type(s): bytes (32 bytes in length) 736 * Change Controller: [[Authors of this RFC]] 738 * Specification Document(s): Section 3.2.2 of [[this RFC]] 740 8.1.5. Certification Reference Claim 742 * Claim Name: "psa-certification-reference" 744 * Claim Description: Certification Reference 746 * JWT Claim Name: "psa-certification-reference" 748 * Claim Key: [[Proposed: -75005]] 750 * Claim Value Type(s): text 752 * Change Controller: [[Authors of this RFC]] 754 * Specification Document(s): Section 3.2.3 of [[this RFC]] 756 8.1.6. Security Lifecycle Claim 758 * Claim Name: "psa-lifecycle" 760 * Claim Description: Security Lifecycle 762 * JWT Claim Name: "psa-lifecycle" 764 * Claim Key: [[Proposed: -75002]] 766 * Claim Value Type(s): unsigned integer 768 * Change Controller: [[Authors of this RFC]] 770 * Specification Document(s): Section 3.3.1 of [[this RFC]] 772 8.1.7. Boot Seed Claim 774 * Claim Name: "psa-boot-seed" 776 * Claim Description: Boot Seed 777 * JWT Claim Name: "psa-boot-seed" 779 * Claim Key: [[Proposed: -75004]] 781 * Claim Value Type(s): bytes (32 bytes in length) 783 * Change Controller: [[Authors of this RFC]] 785 * Specification Document(s): Section 3.3.2 of [[this RFC]] 787 8.1.8. Software Components Claim 789 * Claim Name: "psa-software-components" 791 * Claim Description: Software Components 793 * JWT Claim Name: "psa-software-components" 795 * Claim Key: [[Proposed: -75006]] 797 * Claim Value Type(s): array 799 * Change Controller: [[Authors of this RFC]] 801 * Specification Document(s): Section 3.4.1 of [[this RFC]] 803 8.1.9. No Software Measurements Claim 805 * Claim Name: "psa-no-sw-measurement" 807 * Claim Description: No Software Measurements 809 * JWT Claim Name: "psa-no-sw-measurement" 811 * Claim Key: [[Proposed: -75007]] 813 * Claim Value Type(s): unsigned integer 815 * Change Controller: [[Authors of this RFC]] 817 * Specification Document(s): Section 3.4.2 of [[this RFC]] 819 8.1.10. Verification Service Indicator Claim 821 * Claim Name: "psa-verification-service-indicator" 823 * Claim Description: Verification Service Indicator 824 * JWT Claim Name: "psa-verification-service-indicator" 826 * Claim Key: [[Proposed: -75010]] 828 * Claim Value Type(s): text 830 * Change Controller: [[Authors of this RFC]] 832 * Specification Document(s): Section 3.5.1 of [[this RFC]] 834 8.1.11. Profile Definition Claim 836 * Claim Name: "psa-profile" 838 * Claim Description: Profile Definition 840 * JWT Claim Name: "psa-profile" 842 * Claim Key: [[Proposed: -75000]] 844 * Claim Value Type(s): text 846 * Change Controller: [[Authors of this RFC]] 848 * Specification Document(s): Section 3.5.2 of [[this RFC]] 850 8.2. Media Type Registration 852 IANA is requested to register the "application/psa-attestation-token" 853 media type [RFC2046] in the "Media Types" registry [IANA-MediaTypes] 854 in the manner described in RFC 6838 [RFC6838], which can be used to 855 indicate that the content is a PSA Attestation Token. 857 * Type name: application 859 * Subtype name: psa-attestation-token 861 * Required parameters: n/a 863 * Optional parameters: n/a 865 * Encoding considerations: binary 867 * Security considerations: See the Security Considerations section 868 of [[this RFC]] 870 * Interoperability considerations: n/a 871 * Published specification: [[this RFC]] 873 * Applications that use this media type: Attesters and Relying 874 Parties sending PSA attestation tokens over HTTP(S), CoAP(S), and 875 other transports. 877 * Fragment identifier considerations: n/a 879 * Additional information: 881 - Magic number(s): n/a 883 - File extension(s): n/a 885 - Macintosh file type code(s): n/a 887 * Person & email address to contact for further information: Hannes 888 Tschofenig, Hannes.Tschofenig@arm.com 890 * Intended usage: COMMON 892 * Restrictions on usage: none 894 * Author: Hannes Tschofenig, Hannes.Tschofenig@arm.com 896 * Change controller: IESG 898 * Provisional registration? No 900 8.3. CoAP Content-Formats Registration 902 IANA is requested to register the CoAP Content-Format ID for the 903 "application/psa-attestation-token" media type in the "CoAP Content- 904 Formats" registry [IANA-CoAP-Content-Formats]. 906 8.3.1. Registry Contents 908 * Media Type: application/psa-attestation-token 910 * Encoding: - 912 * Id: [[To-be-assigned by IANA]] 914 * Reference: [[this RFC]] 916 9. References 918 9.1. Normative References 920 [EAN-13] GS1, "International Article Number - EAN/UPC barcodes", 921 2019, . 923 [PSA-FF] Arm, "Platform Security Architecture Firmware Framework 924 1.0 (PSA-FF)", February 2019, 925 . 927 [PSA-SM] Arm, "Platform Security Architecture Security Model 1.0 928 (PSA-SM)", February 2019, 929 . 931 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 932 Extensions (MIME) Part Two: Media Types", RFC 2046, 933 DOI 10.17487/RFC2046, November 1996, 934 . 936 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 937 Requirement Levels", BCP 14, RFC 2119, 938 DOI 10.17487/RFC2119, March 1997, 939 . 941 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 942 Specifications and Registration Procedures", BCP 13, 943 RFC 6838, DOI 10.17487/RFC6838, January 2013, 944 . 946 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 947 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 948 October 2013, . 950 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 951 RFC 8152, DOI 10.17487/RFC8152, July 2017, 952 . 954 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 955 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 956 May 2017, . 958 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 959 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 960 May 2018, . 962 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 963 Definition Language (CDDL): A Notational Convention to 964 Express Concise Binary Object Representation (CBOR) and 965 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 966 June 2019, . 968 9.2. Informative References 970 [I-D.ietf-rats-architecture] 971 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 972 W. Pan, "Remote Attestation Procedures Architecture", Work 973 in Progress, Internet-Draft, draft-ietf-rats-architecture- 974 07, 16 October 2020, . 977 [I-D.ietf-rats-eat] 978 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 979 O'Donoghue, "The Entity Attestation Token (EAT)", Work in 980 Progress, Internet-Draft, draft-ietf-rats-eat-04, 31 981 August 2020, . 984 [IANA-CoAP-Content-Formats] 985 IANA, "CoAP Content-Formats", 2020, 986 . 988 [IANA-CWT] IANA, "CBOR Web Token (CWT) Claims", 2020, 989 . 991 [IANA-MediaTypes] 992 IANA, "Media Types", 2020, 993 . 995 [PSA] Arm, "Platform Security Architecture Resources", 2019, 996 . 999 [TF-M] Linaro, "Trusted Firmware", 2020, 1000 . 1002 Appendix A. Reference Implementation 1004 A reference implementation is provided by the Trusted Firmware 1005 project [TF-M]. 1007 Appendix B. Example 1009 The following example shows a PSA attestation token for an 1010 hypothetical system comprising two measured software components (a 1011 boot loader and a trusted RTOS). The attesting device is in a 1012 lifecycle state Section 3.3.1 of SECURED. The attestation has been 1013 requested from a client residing in the SPE: 1015 { 1016 / psa-profile / -75000: "PSA_IOT_PROFILE_1", 1017 / psa-client-id / -75001: 1, 1018 / psa-lifecycle / -75002: 12288, 1019 / psa-implementation-id / -75003: h'50515253545556575051 1020 52535455565750515253545556575051525354555657', 1021 / psa-boot-seed / -75004: h'DEADBEEFDEADBEEFDEAD 1022 BEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEF', 1023 / psa-certification-reference / -75005: "1234567890123", 1024 / psa-software-components / -75006: [ 1025 { 1026 / measurement type / 1: "BL", 1027 / measurement value / 2: h'0001020400010204000102040001020 1028 400010204000102040001020400010204', 1029 / signer ID / 5: h'519200FF519200FF519200FF519200F 1030 F519200FF519200FF519200FF519200FF' 1031 }, 1032 { 1033 / measurement type / 1: "PRoT", 1034 / measurement value / 2: h'0506070805060708050607080506070 1035 805060708050607080506070805060708', 1036 / signer ID / 5: h'519200FF519200FF519200FF519200F 1037 F519200FF519200FF519200FF519200FF' 1038 } 1039 ], 1040 / psa-nonce / -75008: h'00010203000102030001020300010203 1041 00010203000102030001020300010203', 1042 / psa-instance-id / -75009: h'01A0A1A2A3A0A1A2A3A0A1A2A3A0A1A2 1043 A3A0A1A2A3A0A1A2A3A0A1A2A3A0A1A2A3', 1044 / psa-verification-service-indicator / -75010: "https://psa-ve 1045 rifier.org" 1046 } 1048 The JWK representation of the IAK used for creating the COSE Sign1 1049 signature over the PSA token is: 1051 { 1052 "kty": "EC", 1053 "crv": "P-256", 1054 "x": "MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4", 1055 "y": "4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM", 1056 "d": "870MB6gfuTJ4HtUnUvYMyJpr5eUZNP4Bk43bVdj3eAE", 1057 "use": "enc", 1058 "kid": "1" 1059 } 1061 The resulting COSE object is: 1063 18( 1064 [ 1065 / protected / h'A10126', 1066 / unprotected / {}, 1067 / payload / h'AA3A000124F7715053415F494F545F50524F46494C 1068 455F313A000124F8013A000124F91930003A000124FA58205051525354555657 1069 5051525354555657505152535455565750515253545556573A000124FB5820DE 1070 ADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEF3A 1071 000124FC6D313233343536373839303132333A000124FD82A30162424C025820 1072 0001020400010204000102040001020400010204000102040001020400010204 1073 055820519200FF519200FF519200FF519200FF519200FF519200FF519200FF51 1074 9200FFA3016450526F5402582005060708050607080506070805060708050607 1075 08050607080506070805060708055820519200FF519200FF519200FF519200FF 1076 519200FF519200FF519200FF519200FF3A000124FF5820000102030001020300 1077 01020300010203000102030001020300010203000102033A00012500582101A0 1078 A1A2A3A0A1A2A3A0A1A2A3A0A1A2A3A0A1A2A3A0A1A2A3A0A1A2A3A0A1A2A33A 1079 00012501781868747470733A2F2F7073612D76657269666965722E6F7267', 1080 / signature / h'7C0FA38F80E5EA2A5C710A4BB37ABE63B26B25F17D 1081 B6BE9489587F9B3F8FEB80E0E410D8CDAAFAE5588024CB3E18D60C1F96CED9E0 1082 6743824614019E99BF13FE' 1083 ] 1084 ) 1086 Contributors 1088 We would like to thank the following colleagues for their 1089 contributions: 1091 * Laurence Lundblade 1092 Security Theory LLC 1093 lgl@securitytheory.com 1095 * Tamas Ban 1096 Arm Limited 1097 Tamas.Ban@arm.com 1099 * Sergei Trofimov 1100 Arm Limited 1101 Sergei.Trofimov@arm.com 1103 Acknowledgments 1105 Thanks to Carsten Bormann for help with the CDDL and Nicholas Wood 1106 for ideas and comments. 1108 Authors' Addresses 1109 Hannes Tschofenig 1110 Arm Limited 1112 Email: Hannes.Tschofenig@arm.com 1114 Simon Frost 1115 Arm Limited 1117 Email: Simon.Frost@arm.com 1119 Mathias Brossard 1120 Arm Limited 1122 Email: Mathias.Brossard@arm.com 1124 Adrian Shaw 1125 Arm Limited 1127 Email: Adrian.Shaw@arm.com 1129 Thomas Fossati 1130 Arm Limited 1132 Email: Thomas.Fossati@arm.com