idnits 2.17.1 draft-tschofenig-rats-psa-token-05.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 (6 March 2020) is 1510 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-01 == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-03 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: 7 September 2020 A. Shaw 6 T. Fossati 7 Arm Limited 8 6 March 2020 10 Arm's Platform Security Architecture (PSA) Attestation Token 11 draft-tschofenig-rats-psa-token-05 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 7 September 2020. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. PSA Claims . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.1. Caller Claims . . . . . . . . . . . . . . . . . . . . . . 4 72 3.1.1. Auth Challenge . . . . . . . . . . . . . . . . . . . 4 73 3.1.2. Client ID . . . . . . . . . . . . . . . . . . . . . . 4 74 3.2. Target Identification Claims . . . . . . . . . . . . . . 5 75 3.2.1. Instance ID . . . . . . . . . . . . . . . . . . . . . 5 76 3.2.2. Implementation ID . . . . . . . . . . . . . . . . . . 5 77 3.2.3. Hardware Version . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 10 85 3.5.1. Verification Service Indicator . . . . . . . . . . . 10 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 91 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 93 8.2. Informative References . . . . . . . . . . . . . . . . . 15 94 Appendix A. Reference Implementation . . . . . . . . . . . . . . 16 95 Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 16 96 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18 97 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 100 1. Introduction 102 Trusted execution environments are now present in many devices, which 103 provide a safe environment to place security sensitive code such as 104 cryptography, secure boot, secure storage, and other essential 105 security functions. These security functions are typically exposed 106 through a narrow and well-defined interface, and can be used by 107 operating system libraries and applications. Various APIs have been 108 developed by Arm as part of the Platform Security Architecture [PSA] 109 framework. This document focuses on the output provided by PSA's 110 Initial Attestation API. Since the tokens are also consumed by 111 services outside the device, there is an actual need to ensure 112 interoperability. Interoperability needs are addressed here by 113 describing the exact syntax and semantics of the attestation claims, 114 and defining the way these claims are encoded and cryptographically 115 protected. 117 Further details on concepts expressed below can be found in the PSA 118 Security Model documentation [PSA-SM]. 120 2. Conventions and Definitions 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in 125 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 128 2.1. Glossary 130 RoT Root of Trust, the minimal set of software, hardware and data 131 that has to be implicitly trusted in the platform - there is no 132 software or hardware at a deeper level that can verify that the 133 Root of Trust is authentic and unmodified. An example of RoT is 134 an initial bootloader in ROM, which contains cryptographic 135 functions and credentials, running on a specific hardware 136 platform. 138 SPE Secure Processing Environment, a platform's processing 139 environment for software that provides confidentiality and 140 integrity for its runtime state, from software and hardware, 141 outside of the SPE. Contains trusted code and trusted hardware. 142 (Equivalent to Trusted Execution Environment (TEE), or "secure 143 world".) 145 NSPE Non Secure Processing Environment, the security domain outside 146 of the SPE, the Application domain, typically containing the 147 application firmware, operating systems, and general hardware. 148 (Equivalent to Rich Execution Environment (REE), or "normal 149 world".) 151 3. PSA Claims 153 This section describes the claims to be used in a PSA attestation 154 token. 156 CDDL [RFC8610] along with text descriptions is used to define each 157 claim independent of encoding. The following CDDL type(s) are reused 158 by different claims: 160 psa-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64 162 3.1. Caller Claims 164 3.1.1. Auth Challenge 166 The Auth Challenge claim is an input object from the caller. For 167 example, this can be a cryptographic nonce, a hash of locally 168 attested data. The length must be 32, 48, or 64 bytes. 170 This claim MUST be present in a PSA attestation token. 172 psa-nonce-claim = ( 173 arm_psa_nonce => psa-hash-type 174 ) 176 3.1.2. Client ID 178 The Client ID claim represents the Partition ID of the caller. It is 179 a signed integer whereby negative values represent callers from the 180 NSPE and where positive IDs represent callers from the SPE. The 181 value 0 is not permitted. For a definition of the Partition ID, see 182 the PSA Firmware Framework [PSA-FF]. 184 It is essential that this claim is checked in the verification 185 process to ensure that a security domain, i.e., an attestation 186 endpoint, cannot spoof a report from another security domain. 188 This claim MUST be present in a PSA attestation token. 190 psa-client-id-nspe-type = -2147483648...0 191 psa-client-id-spe-type = 1..2147483647 193 psa-client-id-type = psa-client-id-nspe-type / psa-client-id-spe-type 195 psa-client-id = ( 196 arm_psa_partition_id => psa-client-id-type 197 ) 199 3.2. Target Identification Claims 201 3.2.1. Instance ID 203 The Instance ID claim represents the unique identifier of the device 204 instance. It is a 32 bytes hash of the public key corresponding to 205 the Initial Attestation Key (IAK). If the IAK is a symmetric key 206 then the Instance ID is a hash of the IAK itself. It is encoded as a 207 Universal Entity ID of type RAND [I-D.ietf-rats-eat], i.e., 208 prepending a 0x01 type byte to the key hash. The full definition is 209 in [PSA-SM]. 211 This claim MUST be present in a PSA attestation token. 213 psa-instance-id-type = bytes .size 33 215 psa-instance-id = ( 216 arm_psa_UEID => psa-instance-id-type 217 ) 219 3.2.2. Implementation ID 221 The Implementation ID claim uniquely identifies the underlying 222 immutable PSA RoT. A verification service can use this claim to 223 locate the details of the verification process. Such details include 224 the implementation's origin and associated certification state. The 225 full definition is in [PSA-SM]. 227 This claim MUST be present in a PSA attestation token. 229 psa-implementation-id-type = bytes .size 32 231 psa-implementation-id = ( 232 arm_psa_implementation_id => psa-implementation-id-type 233 ) 235 3.2.3. Hardware Version 237 The Hardware Version claim provides metadata linking the token to the 238 GDSII that went to fabrication for this instance. It can be used to 239 link the class of chip and PSA RoT to the data on a certification 240 website. It MUST be represented as a thirteen-digit [EAN-13]. 242 psa-hardware-version-type = text .regexp "[0-9]{13}" 244 psa-hardware-version = ( 245 ? arm_psa_hw_version => psa-hardware-version-type 246 ) 248 3.3. Target State Claims 250 3.3.1. Security Lifecycle 252 The Security Lifecycle claim represents the current lifecycle state 253 of the PSA RoT. The state is represented by an integer that is 254 divided to convey a major state and a minor state. A major state is 255 mandatory and defined by [PSA-SM]. A minor state is optional and 256 'IMPLEMENTATION DEFINED'. The PSA security lifecycle state and 257 implementation state are encoded as follows: 259 * version[15:8] - PSA security lifecycle state, and 261 * version[7:0] - IMPLEMENTATION DEFINED state. 263 The PSA lifecycle states are illustrated in Figure 1. For PSA, a 264 remote verifier can only trust reports from the PSA RoT when it is in 265 SECURED or NON_PSA_ROT_DEBUG major states. 267 This claim MUST be present in a PSA attestation token. 269 .----------------------. 270 .--- Enrol ---+ Provisioning Lockdown | 271 | '-----------+----------' 272 | | .------------------. 273 | | | | 274 * v v | 275 .--------------. .---------. | 276 | Verifier | .---------+ Secured +-----------. | 277 '--------------' | '-+-------' | | 278 * | | ^ | | 279 | | v | v | 280 Blacklist | .------------+------. .----------+----. 281 | | | Non-PSA RoT Debug | | Recoverable | 282 | | '---------+---------' | PSA RoT Debug | 283 .-+-----------+-. | '------+--------' 284 | Terminate +------------+-------------------' 285 '------+--------' 286 | .----------------. 287 '------------>| Decommissioned | 288 '----------------' 290 Figure 1: PSA Lifecycle States 292 psa-lifecycle-unknown-type = 0x0000..0x00ff 293 psa-lifecycle-assembly-and-test-type = 0x1000..0x10ff 294 psa-lifecycle-psa-rot-provisioning-type = 0x2000..0x20ff 295 psa-lifecycle-secured-type = 0x3000..0x30ff 296 psa-lifecycle-non-psa-rot-debug-type = 0x4000..0x40ff 297 psa-lifecycle-recoverable-psa-rot-debug-type = 0x5000..0x50ff 298 psa-lifecycle-decommissioned-type = 0x6000..0x60ff 300 psa-lifecycle-type = 301 psa-lifecycle-unknown-type / 302 psa-lifecycle-assembly-and-test-type / 303 psa-lifecycle-psa-rot-provisioning-type / 304 psa-lifecycle-secured-type / 305 psa-lifecycle-non-psa-rot-debug-type / 306 psa-lifecycle-recoverable-psa-rot-debug-type / 307 psa-lifecycle-decommissioned-type 309 psa-lifecycle = ( 310 arm_psa_security_lifecycle => psa-lifecycle-type 311 ) 313 3.3.2. Boot Seed 315 The Boot Seed claim represents a random value created at system boot 316 time that will allow differentiation of reports from different boot 317 sessions. 319 This claim MUST be present in a PSA attestation token. 321 psa-boot-seed-type = bytes .size 32 323 psa-boot-seed = ( 324 arm_psa_boot_seed => psa-boot-seed-type 325 ) 327 3.4. Software Inventory Claims 329 3.4.1. Software Components 331 The Software Components claim is a list of software components that 332 includes all the software loaded by the PSA RoT. This claim SHALL be 333 included in attestation tokens produced by an implementation 334 conformant with [PSA-SM]. If the Software Components claim is 335 present, then the No Software Measurement claim (Section 3.4.2) MUST 336 NOT be present. 338 Each entry in the Software Components list describes one software 339 component using the attributes described in the following 340 subsections. Unless explicitly stated, the presence of an attribute 341 is OPTIONAL. 343 Note that, as described in [I-D.ietf-rats-architecture], a relying 344 party will typically see the result of the verification process from 345 the Verifier in form of an attestation result, rather than the 346 "naked" PSA token from the attesting endpoint. Therefore, a relying 347 party is not expected to understand the Software Components claim. 348 Instead, it is for the Verifier to check this claim against the 349 available endorsements and provide an answer in form of an "high 350 level" attestation result, which may or may not include the original 351 Software Components claim. 353 psa-software-component = { 354 ? 1 => text, ; measurement type 355 2 => psa-hash-type, ; measurement value 356 ? 4 => text, ; version 357 5 => psa-hash-type, ; signer id 358 ? 6 => text, ; measurement description 359 } 361 psa-software-components = ( 362 arm_psa_sw_components => [ + psa-software-component ] 363 ) 365 3.4.1.1. Measurement Type 367 The Measurement Type attribute (key=1) is short string representing 368 the role of this software component. 370 The following measurement types MAY be used: 372 * "BL": a Boot Loader 374 * "PRoT": a component of the PSA Root of Trust 376 * "ARoT": a component of the Application Root of Trust 378 * "App": a component of the NSPE application 380 * "TS": a component of a Trusted Subsystem 382 3.4.1.2. Measurement Value 384 The Measurement Value attribute (key=2) represents a hash of the 385 invariant software component in memory at startup time. The value 386 MUST be a cryptographic hash of 256 bits or stronger. 388 This attribute MUST be present in a PSA software component. 390 3.4.1.3. Version 392 The Version attribute (key=4) is the issued software version in the 393 form of a text string. The value of this attribute will correspond 394 to the entry in the original signed manifest of the component. 396 3.4.1.4. Signer ID 398 The Signer ID attribute (key=5) is the hash of a signing authority 399 public key for the software component. The value of this attribute 400 will correspond to the entry in the original manifest for the 401 component. This can be used by a verifier to ensure the components 402 were signed by an expected trusted source. 404 This attribute MUST be present in a PSA software component to be 405 compliant with [PSA-SM]. 407 3.4.1.5. Measurement Description 409 The Measurement Description attribute (key=6) is the description of 410 the way in which the measurement value of the software component is 411 computed. The value will be a text string containing an abbreviated 412 description (or name) of the measurement method which can be used to 413 lookup the details of the method in a profile document. This 414 attribute will normally be excluded, unless there was an exception to 415 the default measurement described in the profile for a specific 416 component. 418 3.4.2. No Software Measurements 420 In the event that the implementation does not contain any software 421 measurements then the Software Components claim Section 3.4.1 can be 422 omitted but instead the token MUST include this claim to indicate 423 this is a deliberate state. The value SHOULD be 1. This claim is 424 intended for devices that are not compliant with [PSA-SM]. 426 psa-no-sw-measurements-type = 1 428 psa-no-sw-measurement = ( 429 arm_psa_no_sw_measurements => psa-no-sw-measurements-type 430 ) 432 3.5. Verification Claims 434 3.5.1. Verification Service Indicator 436 The Verification Service Indicator claim is a hint used by a relying 437 party to locate a validation service for the token. The value is a 438 text string that can be used to locate the service or a URL 439 specifying the address of the service. A verifier may choose to 440 ignore this claim in favor of other information. 442 psa-verification-service-indicator-type = text 444 psa-verification-service-indicator = ( 445 ? arm_psa_origination => psa-verification-service-indicator-type 446 ) 448 3.5.2. Profile Definition 450 The Profile Definition claim contains the name of a document that 451 describes the "profile" of the report. The document name may include 452 versioning. The value for this specification MUST be 453 PSA_IOT_PROFILE_1. 455 psa-profile-type = "PSA_IOT_PROFILE_1" 457 psa-profile = ( 458 ? arm_psa_profile_id => psa-profile-type 459 ) 461 4. Token Encoding and Signing 463 The report is encoded as a COSE Web Token (CWT) [RFC8392], similar to 464 the Entity Attestation Token (EAT) [I-D.ietf-rats-eat]. The token 465 consists of a series of claims declaring evidence as to the nature of 466 the instance of hardware and software. The claims are encoded in 467 CBOR [RFC7049] format. For asymmetric key algorithms, the signature 468 structure MUST be COSE-Sign1. For symmetric key algorithms, the 469 structure MUST be COSE-Mac0. 471 5. Collated CDDL 473 psa-token = { 474 psa-nonce-claim, 475 psa-instance-id, 476 psa-verification-service-indicator, 477 psa-profile, 478 psa-implementation-id, 479 psa-client-id, 480 psa-lifecycle, 481 psa-hardware-version, 482 psa-boot-seed, 483 ( psa-software-components // psa-no-sw-measurement ), 484 } 486 arm_psa_profile_id = -75000 487 arm_psa_partition_id = -75001 488 arm_psa_security_lifecycle = -75002 489 arm_psa_implementation_id = -75003 490 arm_psa_boot_seed = -75004 491 arm_psa_hw_version = -75005 492 arm_psa_sw_components = -75006 493 arm_psa_no_sw_measurements = -75007 494 arm_psa_nonce = -75008 495 arm_psa_UEID = -75009 496 arm_psa_origination = -75010 498 psa-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64 500 psa-boot-seed-type = bytes .size 32 502 psa-boot-seed = ( 503 arm_psa_boot_seed => psa-boot-seed-type 504 ) 506 psa-client-id-nspe-type = -2147483648...0 507 psa-client-id-spe-type = 1..2147483647 509 psa-client-id-type = psa-client-id-nspe-type / psa-client-id-spe-type 511 psa-client-id = ( 512 arm_psa_partition_id => psa-client-id-type 513 ) 515 psa-hardware-version-type = text .regexp "[0-9]{13}" 517 psa-hardware-version = ( 518 ? arm_psa_hw_version => psa-hardware-version-type 519 ) 521 psa-implementation-id-type = bytes .size 32 523 psa-implementation-id = ( 524 arm_psa_implementation_id => psa-implementation-id-type 525 ) 527 psa-instance-id-type = bytes .size 33 529 psa-instance-id = ( 530 arm_psa_UEID => psa-instance-id-type 531 ) 533 psa-no-sw-measurements-type = 1 535 psa-no-sw-measurement = ( 536 arm_psa_no_sw_measurements => psa-no-sw-measurements-type 537 ) 538 psa-nonce-claim = ( 539 arm_psa_nonce => psa-hash-type 540 ) 542 psa-profile-type = "PSA_IOT_PROFILE_1" 544 psa-profile = ( 545 ? arm_psa_profile_id => psa-profile-type 546 ) 548 psa-lifecycle-unknown-type = 0x0000..0x00ff 549 psa-lifecycle-assembly-and-test-type = 0x1000..0x10ff 550 psa-lifecycle-psa-rot-provisioning-type = 0x2000..0x20ff 551 psa-lifecycle-secured-type = 0x3000..0x30ff 552 psa-lifecycle-non-psa-rot-debug-type = 0x4000..0x40ff 553 psa-lifecycle-recoverable-psa-rot-debug-type = 0x5000..0x50ff 554 psa-lifecycle-decommissioned-type = 0x6000..0x60ff 556 psa-lifecycle-type = 557 psa-lifecycle-unknown-type / 558 psa-lifecycle-assembly-and-test-type / 559 psa-lifecycle-psa-rot-provisioning-type / 560 psa-lifecycle-secured-type / 561 psa-lifecycle-non-psa-rot-debug-type / 562 psa-lifecycle-recoverable-psa-rot-debug-type / 563 psa-lifecycle-decommissioned-type 565 psa-lifecycle = ( 566 arm_psa_security_lifecycle => psa-lifecycle-type 567 ) 569 psa-software-component = { 570 ? 1 => text, ; measurement type 571 2 => psa-hash-type, ; measurement value 572 ? 4 => text, ; version 573 5 => psa-hash-type, ; signer id 574 ? 6 => text, ; measurement description 575 } 577 psa-software-components = ( 578 arm_psa_sw_components => [ + psa-software-component ] 579 ) 581 psa-verification-service-indicator-type = text 583 psa-verification-service-indicator = ( 584 ? arm_psa_origination => psa-verification-service-indicator-type 585 ) 587 6. Security and Privacy Considerations 589 This specification re-uses the CWT and the EAT specification. Hence, 590 the security and privacy considerations of those specifications apply 591 here as well. 593 Since CWTs offer different ways to protect the token, this 594 specification profiles those options and allows signatures based on 595 use of public key cryptography as well as MAC authentication. The 596 token MUST be signed following the structure of the COSE 597 specification [RFC8152]. The COSE type MUST be COSE-Sign1 for public 598 key signatures or COSE-Mac0 for MAC authentication. Note however 599 that use of MAC authentication is NOT RECOMMENDED due to the 600 associated infrastructure costs for key management and protocol 601 complexities. It may also restrict the ability to interoperate with 602 third parties. 604 Attestation tokens contain information that may be unique to a device 605 and therefore they may allow to single out an individual device for 606 tracking purposes. Implementations that have privacy requirements 607 must take appropriate measures to ensure that the token is only used 608 to provision anonymous/pseudonym keys. 610 7. IANA Considerations 612 IANA is requested to allocate the claims defined in Section 3 to the 613 CBOR Web Token (CWT) Claims registry [IANA-CWT]. The change 614 controller are the authors and the reference is this document. 616 8. References 618 8.1. Normative References 620 [EAN-13] GS1, "International Article Number - EAN/UPC barcodes", 621 2019, . 623 [PSA-FF] Arm, "Platform Security Architecture Firmware Framework 624 1.0 (PSA-FF)", February 2019, 625 . 627 [PSA-SM] Arm, "Platform Security Architecture Security Model 1.0 628 (PSA-SM)", February 2019, 629 . 631 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 632 Requirement Levels", BCP 14, RFC 2119, 633 DOI 10.17487/RFC2119, March 1997, 634 . 636 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 637 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 638 October 2013, . 640 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 641 RFC 8152, DOI 10.17487/RFC8152, July 2017, 642 . 644 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 645 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 646 May 2017, . 648 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 649 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 650 May 2018, . 652 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 653 Definition Language (CDDL): A Notational Convention to 654 Express Concise Binary Object Representation (CBOR) and 655 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 656 June 2019, . 658 8.2. Informative References 660 [I-D.ietf-rats-architecture] 661 Birkholz, H., Thaler, D., Richardson, M., and N. Smith, 662 "Remote Attestation Procedures Architecture", Work in 663 Progress, Internet-Draft, draft-ietf-rats-architecture-01, 664 4 February 2020, . 667 [I-D.ietf-rats-eat] 668 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 669 O'Donoghue, "The Entity Attestation Token (EAT)", Work in 670 Progress, Internet-Draft, draft-ietf-rats-eat-03, 20 671 February 2020, . 674 [IANA-CWT] IANA, "CBOR Web Token (CWT) Claims", 2020, 675 . 677 [PSA] Arm, "Platform Security Architecture Resources", 2019, 678 . 681 [TF-M] Linaro, "Trusted Firmware", 2020, 682 . 684 Appendix A. Reference Implementation 686 A reference implementation is provided by the Trusted Firmware 687 project [TF-M]. 689 Appendix B. Example 691 The following example shows an attestation token that was produced 692 for a device that has a single-stage bootloader, and an RTOS with a 693 device management client. From a code point of view, the RTOS and 694 the device management client form a single binary. 696 EC key using curve P-256 with: 698 * x: 699 0xdcf0d0f4bcd5e26a54ee36cad660d283d12abc5f7307de58689e77cd60452e75 701 * y: 702 0x8cbadb5fe9f89a7107e5a2e8ea44ec1b09b7da2a1a82a0252a4c1c26ee1ed7cf 704 * d: 705 0xc74670bcb7e85b3803efb428940492e73e3fe9d4f7b5a8ad5e480cbdbcb554c2 707 Key using COSE format (base64-encoded): 709 pSJYIIy621/p+JpxB+Wi6OpE7BsJt9oqGoKgJSpMHCbuHtfPI1ggx0ZwvLfoWzgD77Q 710 olASS5z4/6dT3taitXkgMvby1VMIBAiFYINzw0PS81eJqVO42ytZg0oPRKrxfcwfeWG 711 ied81gRS51IAE= 713 Example of EAT token (base64-encoded): 715 0oRDoQEmoFkCIqk6AAEk+1ggAAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8 716 6AAEk+lggAAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh86AAEk/YSkAlggAA 717 ECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8EZTMuMS40BVggAAECAwQFBgcIC 718 QoLDA0ODxAREhMUFRYXGBkaGxwdHh8BYkJMpAJYIAABAgMEBQYHCAkKCwwNDg8QERIT 719 FBUWFxgZGhscHR4fBGMxLjEFWCAAAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0 720 eHwFkUFJvVKQCWCAAAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHwRjMS4wBV 721 ggAAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8BZEFSb1SkAlggAAECAwQFB 722 gcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8EYzIuMgVYIAABAgMEBQYHCAkKCwwNDg8Q 723 ERITFBUWFxgZGhscHR4fAWNBcHA6AAEk+RkwADoAAST/WCAAAQIDBAUGBwgJCgsMDQ4 724 PEBESExQVFhcYGRobHB0eHzoAASUBbHBzYV92ZXJpZmllcjoAAST4IDoAASUAWCEBAA 725 ECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh86AAEk93FQU0FfSW9UX1BST0ZJT 726 EVfMVhAWIYFCO5+jMSOuoctu11pSlQrEyKtDVECPBlw30KfBlAcaDqVEIoMztCm6A4J 727 ZvIr1j0cAFaXShG6My14d4f7Tw== 729 Same token using extended CBOR diagnostic format: 731 18( 732 [ 733 / protected / h'a10126' / { 734 \ alg \ 1: -7 \ ECDSA 256 \ 735 } / , 736 / unprotected / {}, 737 / payload / h'a93a000124fb5820000102030405060708090a0b0c0d0e0f10111 738 2131415161718191a1b1c1d1e1f3a000124fa5820000102030405060708090a0b0c 739 0d0e0f101112131415161718191a1b1c1d1e1f3a000124fd84a4025820000102030 740 405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f0465332e312e 741 34055820000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1 742 d1e1f0162424ca4025820000102030405060708090a0b0c0d0e0f10111213141516 743 1718191a1b1c1d1e1f0463312e31055820000102030405060708090a0b0c0d0e0f1 744 01112131415161718191a1b1c1d1e1f016450526f54a40258200001020304050607 745 08090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f0463312e30055820000 746 102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f016441 747 526f54a4025820000102030405060708090a0b0c0d0e0f101112131415161718191 748 a1b1c1d1e1f0463322e32055820000102030405060708090a0b0c0d0e0f10111213 749 1415161718191a1b1c1d1e1f01634170703a000124f91930003a000124ff5820000 750 102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f3a0001 751 25016c7073615f76657269666965723a000124f8203a00012500582101000102030 752 405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f3a000124f771 753 5053415f496f545f50524f46494c455f 754 31' / { 755 / arm_psa_boot_seed / -75004: h'000102030405060708090a0b0c0d0e0f 756 101112131415161718191a1b1c1d1e1f', 757 / arm_psa_implementation_id / -75003: h'000102030405060708090a0b 758 0c0d0e0f101112131415161718191a1b1c1d1e1f', 759 / arm_psa_sw_components / -75006: [ 760 { 761 / measurement / 2: h'000102030405060708090a0b0c0d0e0f1011 762 12131415161718191a1b1c1d1e1f', 763 / version / 4: "3.1.4", 764 / signerID / 5: h'000102030405060708090a0b0c0d0e0f1011121 765 31415161718191a1b1c1d1e1f', 766 / type / 1: "BL" 767 }, 768 { 769 / measurement / 2: h'000102030405060708090a0b0c0d0e0f1011 770 12131415161718191a1b1c1d1e1f', 771 / version / 4: "1.1", 772 / signerID / 5: h'000102030405060708090a0b0c0d0e0f1011121 773 31415161718191a1b1c1d1e1f', 774 / type / 1: "PRoT" 775 }, 776 { 777 / measurement / 2: h'000102030405060708090a0b0c0d0e0f1011 778 12131415161718191a1b1c1d1e1f', 779 / version / 4: "1.0", 780 / signerID / 5: h'000102030405060708090a0b0c0d0e0f1011121 781 31415161718191a1b1c1d1e1f', 782 / type / 1: "ARoT" 783 }, 784 { 785 / measurement / 2: h'000102030405060708090a0b0c0d0e0f1011 786 12131415161718191a1b1c1d1e1f', 787 / version / 4: "2.2", 788 / signerID / 5: h'000102030405060708090a0b0c0d0e0f1011121 789 31415161718191a1b1c1d1e1f', 790 / type / 1: "App" 791 } 792 ], 793 / arm_psa_security_lifecycle / -75002: 12288 / SECURED /, 794 / arm_psa_nonce / -75008: h'000102030405060708090a0b0c0d0e0f101 795 112131415161718191a1b1c1d1e1f', 796 / arm_psa_origination / -75010: "psa_verifier", 797 / arm_psa_partition_id / -75001: -1, 798 / arm_psa_UEID / -75009: h'01000102030405060708090a0b0c0d0e0f10 799 1112131415161718191a1b1c1d1e1f', 800 / arm_psa_profile_id / -75000: "PSA_IoT_PROFILE_1" 801 }), 802 } / , 803 / signature / h'58860508ee7e8cc48eba872dbb5d694a542b1322ad0d51023c1 804 970df429f06501c683a95108a0cced0a6e80e0966f22bd63d1c0056974a11ba332d 805 787787fb4f' 806 ] 807 ) 809 Contributors 811 We would like to thank the following colleagues for their 812 contributions: 814 * Laurence Lundblade 815 Security Theory LLC 816 lgl@securitytheory.com 818 * Tamas Ban 819 Arm Limited 820 Tamas.Ban@arm.com 822 * Sergei Trofimov 823 Arm Limited 824 Sergei.Trofimov@arm.com 826 Acknowledgments 828 Thanks to Carsten Bormann for help with the CDDL and Nicholas Wood 829 for ideas and comments. 831 Authors' Addresses 833 Hannes Tschofenig 834 Arm Limited 836 Email: Hannes.Tschofenig@arm.com 838 Simon Frost 839 Arm Limited 841 Email: Simon.Frost@arm.com 843 Mathias Brossard 844 Arm Limited 846 Email: Mathias.Brossard@arm.com 848 Adrian Shaw 849 Arm Limited 851 Email: Adrian.Shaw@arm.com 853 Thomas Fossati 854 Arm Limited 856 Email: Thomas.Fossati@arm.com