idnits 2.17.1 draft-tschofenig-rats-psa-token-00.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 11, 2019) is 1873 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS H. Tschofenig, Ed. 3 Internet-Draft S. Frost 4 Intended status: Standards Track M. Brossard 5 Expires: September 12, 2019 A. Shaw 6 Arm Limited 7 March 11, 2019 9 Arm's Platform Security Architecture (PSA) Attestation Token 10 draft-tschofenig-rats-psa-token-00 12 Abstract 14 The insecurity of IoT systems is a widely known and discussed 15 problem. The Arm Platform Security Architecture (PSA) is being 16 developed to address this challenge by making it easier to build 17 secure systems. 19 This document specifies token format and claims used in the 20 attestation API of the Arm Platform Security Architecture (PSA). 22 At its core, the Entity Attestation Token (EAT) format is used and 23 populated with a set of claims. This specification describes what 24 claims are used by the PSA and what has been implemented within Arm 25 Trusted Firmware-M. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 12, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 74 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 75 2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. Information Model . . . . . . . . . . . . . . . . . . . . . . 5 77 4. Token Encoding . . . . . . . . . . . . . . . . . . . . . . . 9 78 5. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 7. Security and Privacy Considerations . . . . . . . . . . . . . 14 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 84 9.2. Informative References . . . . . . . . . . . . . . . . . 15 85 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 16 86 Appendix B. Reference Implementation . . . . . . . . . . . . . . 16 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 Modern hardware for Internet of Things devices contain trusted 92 execution environments and in case of the Arm v8-M architecture 93 TrustZone support. TrustZone on these low end microcontrollers 94 allows the separation between a normal world and a secure world where 95 security sensitive code resides in the secure world and is executed 96 by applications running on the normal world using a well-defined API. 98 Various APIs have been developed by Arm as part of the Platform 99 Security Architecture [PSA]; this document focuses on the 100 functionality provided by the attestation API. Since the tokens 101 exposed via the attestation API are also consumed by services outside 102 the device, interoperability needs arise. In this specification 103 these interoperability needs are addressed by a combination of 105 - a set of claims encoded in CBOR, 107 - embedded in a CBOR Web Token (CWT), 109 - protected by functionality offered by the CBOR Object Signing and 110 Encryption (COSE) specification. 112 Figure 1 shows the architecture graphically. Apps on the IoT device 113 communicate with services on the secure world using a defined API. 114 The attestation API exposes tokens, as described in this document, 115 and those tokens may be presented to network or application services. 117 +-----------------+------------------+ 118 | Normal World | Secure World | 119 | | +-+ | 120 | | |A| | 121 | | |T| | 122 | | |T| | 123 | | |E| +-+ | 124 | | +-+ |S| |S| | 125 | | |C| |T| |T| | 126 +----------+ | | |R| |A| |O| | 127 | Network | | +----------+ | |Y| |T| |R| | 128 | and App |<=============| Apps | +--+--+ |P| |I| |A| | 129 | Services | | +----------+ |P | | |T| |O| |G| | 130 +----------+ | +----------+ |S | | |O| |N| |E| | 131 | |Middleware| |A | | +-+ +-+ +-+ | 132 | +----------+ | | | +----------+ | 133 | +----------+ |A | | | | | 134 | | | |P | | | TF-M Core| | 135 | | RTOS and | |I | | +----------+ | 136 | | Drivers | +--+--+ +----------+ | 137 | | | | | Boot | | 138 | +----------+ | | Loader | | 139 | | +----------+ | 140 +-----------------+------------------+ 141 | H A R D|W A R E | 142 +-----------------+------------------+ 144 Internet of Things Device 146 Figure 1: Software Architecture 148 2. Conventions and Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in RFC 153 2119 [RFC2119]. 155 2.1. Glossary 157 RoT Root of Trust, the minimal set of software, hardware and data 158 that has to be implicitly trusted in the platform - there is no 159 software or hardware at a deeper level that can verify that the 160 Root of Trust is authentic and unmodified. 162 SPE Secure Processing Environment, a platform's processing 163 environment for software that provides confidentiality and 164 integrity for its runtime state, from software and hardware, 165 outside of the SPE. Contains the Secure Partition Manager, the 166 Secure Partitions and the trusted hardware. 168 NSPE Non Secure Processing Environment, the security domain outside 169 of the SPE, the Application domain, typically containing the 170 application firmware and hardware. 172 3. Information Model 174 Table 1 describes the utilized claims. 176 +----------------+--------------+-----------------------------------+ 177 | Claim | Mandatory | Description | 178 +----------------+--------------+-----------------------------------+ 179 | Challenge | Yes | Input object from the caller. For | 180 | | | example, this can be a | 181 | | | cryptographic nonce, a hash of | 182 | | | locally attested data, or both. | 183 | | | The length must be 32, 48, or 64 | 184 | | | bytes. | 185 | | | | 186 | Instance ID | Yes | Represents the unique identifier | 187 | | | of the instance. It is a hash of | 188 | | | the public key corresponding to | 189 | | | the Initial Attestation Key. | 190 | | | | 191 | Verification | No | Information used by a relying | 192 | Service | | party to locate a validation | 193 | Indicator | | service for the token. The value | 194 | | | is a text string that can be used | 195 | | | to locate the service or a URL | 196 | | | specifying the address of the | 197 | | | service. | 198 | | | | 199 | Profile | No | Contains the name of a document | 200 | Definition | | that describes the 'profile' of | 201 | | | the report. The document name may | 202 | | | include versioning. The value for | 203 | | | this specification is | 204 | | | PSA_IOT_PROFILE_1. | 205 | | | | 206 | Implementation | Yes | Represents the original | 207 | ID | | implementation signer of the | 208 | | | attestation key and identifies | 209 | | | the contract between the report | 210 | | | and verification. A verification | 211 | | | service will use this claim to | 212 | | | locate the details of the | 213 | | | verification process. | 214 | | | | 215 | Client ID | Yes | Represents the Partition ID of | 216 | | | the caller. It is a signed | 217 | | | integer whereby negative values | 218 | | | represent callers from the NSPE | 219 | | | and where positive IDs represent | 220 | | | callers from the SPE. The full | 221 | | | definition of the partition ID is | 222 | | | defined in the PSA Firmware | 223 | | | Framework (PSA-FF) [PSA-FF]. | 224 | | | | 225 | Security | Yes | Represents the current lifecycle | 226 | Lifecycle | | state of the PSA RoT. The state | 227 | | | is represented by a 16-bit | 228 | | | unsigned integer that is divided | 229 | | | to convey a major state and a | 230 | | | minor state. A major state is | 231 | | | defined by [PSA-SM]. A minor | 232 | | | state is 'IMPLEMENTATION | 233 | | | DEFINED'. The encoding is: | 234 | | | version[15:8] - PSA lifecycle | 235 | | | state, and version[7:0] - | 236 | | | IMPLEMENTATION DEFINED state. The | 237 | | | PSA lifecycle states are listed | 238 | | | below. For PSA, a remote verifier | 239 | | | can only trust reports from the | 240 | | | PSA RoT when it is in SECURED, | 241 | | | NON_PSA_ROT_DEBUG or | 242 | | | RECOVERABLE_PSA_ROT_DEBUG major | 243 | | | states. | 244 | | | | 245 | Hardware | No | Provides metadata linking the | 246 | version | | token to the GDSII that went to | 247 | | | fabrication for this instance. It | 248 | | | can be used to link the class of | 249 | | | chip and PSA RoT to the data on a | 250 | | | certification website. It must be | 251 | | | represented as a thirteen-digit | 252 | | | [EAN-13] | 253 | | | | 254 | Boot Seed | Yes | Represents a random value created | 255 | | | at system boot time that will | 256 | | | allow differentiation of reports | 257 | | | from different system sessions. | 258 | | | | 259 | Software | Yes (unless | A list of software components | 260 | Components | the No | that represent the entire | 261 | | Software | software state of the system. | 262 | | Measurements | This claim is recommended in | 263 | | claim is | order to comply with the rules | 264 | | specified) | outlined in the [PSA-SM]. The | 265 | | | software components are further | 266 | | | explained below. | 267 | | | | 268 | No Software | Yes (if no | In the event that the | 269 | Measurements | software | implementation does not contain | 270 | | components | any software measurements then | 271 | | specified) | the Software Components claim | 272 | | | above can be omitted but instead | 273 | | | it will be mandatory to include | 274 | | | this claim to indicate this is a | 275 | | | deliberate state. | 276 +----------------+--------------+-----------------------------------+ 278 Table 1: Information Model of PSA Attestation Claims. 280 The PSA lifecycle states consist of the following values: 282 - UNKNOWN (0x1000u) 284 - PSA_ROT_PROVISIONING (0x2000u) 286 - SECURED (0x3000u) 288 - NON_PSA_ROT_DEBUG (0x4000u) 290 - RECOVERABLE_PSA_ROT_DEBUG (0x5000u) 292 - PSA_LIFECYCLE_DECOMMISSIONED (0x6000u) 294 Table 2 shows the structure of each software component entry in the 295 Software Components claim. 297 +-----+-------------+-----------+-----------------------------------+ 298 | Key | Type | Mandatory | Description | 299 | ID | | | | 300 +-----+-------------+-----------+-----------------------------------+ 301 | 1 | Measurement | No | A short string representing the | 302 | | Type | | role of this software component | 303 | | | | (e.g. 'BL' for Boot Loader). | 304 | | | | | 305 | 2 | Measurement | Yes | Represents a hash of the | 306 | | value | | invariant software component in | 307 | | | | memory at startup time. The value | 308 | | | | must be a cryptographic hash of | 309 | | | | 256 bits or stronger. | 310 | | | | | 311 | 3 | Reserved | No | Reserved | 312 | | | | | 313 | 4 | Version | No | The issued software version in | 314 | | | | the form of a text string. The | 315 | | | | value of this claim will | 316 | | | | correspond to the entry in the | 317 | | | | original signed manifest of the | 318 | | | | component. | 319 | | | | | 320 | 5 | Signer ID | Yes | The hash of a signing authority | 321 | | | | public key for the software | 322 | | | | component. The value of this | 323 | | | | claim will correspond to the | 324 | | | | entry in the original manifest | 325 | | | | for the component. | 326 | | | | | 327 | 6 | Measurement | No | Description of the software | 328 | | description | | component, which represents the | 329 | | | | way in which the measurement | 330 | | | | value of the software component | 331 | | | | is computed. The value will be a | 332 | | | | text string containing an | 333 | | | | abbreviated description (or name) | 334 | | | | of the measurement method which | 335 | | | | can be used to lookup the details | 336 | | | | of the method in a profile | 337 | | | | document. This claim will | 338 | | | | normally be excluded, unless | 339 | | | | there was an exception to the | 340 | | | | default measurement described in | 341 | | | | the profile for a specific | 342 | | | | component. | 343 +-----+-------------+-----------+-----------------------------------+ 345 Table 2: Software Components Claims. 347 The following measurement types are current defined: 349 - 'BL': a Boot Loader 351 - 'PRoT': a component of the PSA Root of Trust 353 - 'ARoT': a component of the Application Root of Trust 355 - 'App': a component of the NSPE application 356 - 'TS': a component of a Trusted Subsystem 358 4. Token Encoding 360 The report is represented as a token, which must be formatted in 361 accordance to the Entity Attestation Token (EAT) [I-D.mandyam-eat]. 362 The token consists of a series of claims declaring evidence as to the 363 nature of the instance of hardware and software. The claims are 364 encoded in CBOR [RFC7049] format. 366 5. Claims 368 The token is modelled to include custom values that correspond to the 369 following claims suggested in the EAT specification: 371 - nonce (mandatory); arm_psa_nonce is used instead 373 - UEID (mandatory); arm_psa_UEID is used instead 375 - origination (recommended); arm_psa_origination is used instead 377 Later revisions of this documents might phase out those custom claims 378 to be replaced by the EAT standard claims. 380 As noted, some fields must be at least 32 bytes long to provide 381 sufficient cryptographic strength. 383 +--------+--------------+----------------------------+--------------+ 384 | Claim | Claim | Claim Name | CBOR Value | 385 | Key | Description | | Type | 386 +--------+--------------+----------------------------+--------------+ 387 | -75000 | Profile | arm_psa_profile_id | Text string | 388 | | Definition | | | 389 | | | | | 390 | -75001 | Client ID | arm_psa_partition_id | Unsigned | 391 | | | | integer or | 392 | | | | Negative | 393 | | | | integer | 394 | | | | | 395 | -75002 | Security | arm_psa_security_lifecycle | Unsigned | 396 | | Lifecycle | | integer | 397 | | | | | 398 | -75003 | Impl. ID | arm_psa_implementation_id | Byte string | 399 | | | | (>=32 bytes) | 400 | | | | | 401 | -75004 | Boot Seed | arm_psa_boot_seed | Byte string | 402 | | | | (>=32 bytes) | 403 | | | | | 404 | -75005 | Hardware | arm_psa_hw_version | Text string | 405 | | Version | | | 406 | | | | | 407 | -75006 | Software | arm_psa_sw_components | Array of map | 408 | | Components | | entries. | 409 | | | | (compound | 410 | | | | map claim) | 411 | | | | | 412 | -75007 | No Software | arm_psa_no_sw_measurements | Unsigned | 413 | | Measurements | | integer | 414 | | | | | 415 | -75008 | Challenge | arm_psa_nonce | Byte string | 416 | | | | | 417 | -75009 | Instance ID | arm_psa_UEID | Byte string | 418 | | | | | 419 | -75010 | Verification | arm_psa_origination | Byte string | 420 | | Service | | or | 421 | | Indicator | | StringOrURI | 422 +--------+--------------+----------------------------+--------------+ 424 Each map entry of the software component claim MUST have the 425 following types for each key value: 427 1. Text string (type) 429 2. Byte string (measurement, >=32 bytes) 430 3. Reserved 432 4. Text string (version) 434 5. Byte string (signer ID, >=32 bytes) 436 6. Text string (measurement description) 438 The following key values will be present in the software components 439 claim: 1 (Type), 2 (Measurement Value), 4 (Version) and 5 (Signer 440 ID). Keys 3 (Reserved) and 6 (Measurement Description) will not be 441 present. Instead of a referenced Measurement Description it is 442 defined that all cases, the software measurement value is taken as a 443 SHA256 hash of the software image, prior to it executing in place. 445 6. Example 447 The following example shows an attestation token that was produced 448 for a device that has a single-stage bootloader, and an RTOS with a 449 device management client. From a code point of view, the RTOS and 450 the device management client form a single binary. 452 EC key using curve P-256 with: 454 - x: 455 0xdcf0d0f4bcd5e26a54ee36cad660d283d12abc5f7307de58689e77cd60452e75 457 - y: 458 0x8cbadb5fe9f89a7107e5a2e8ea44ec1b09b7da2a1a82a0252a4c1c26ee1ed7cf 460 - d: 461 0xc74670bcb7e85b3803efb428940492e73e3fe9d4f7b5a8ad5e480cbdbcb554c2 463 Key using COSE format (base64-encoded): 465 pSJYIIy621/p+JpxB+Wi6OpE7BsJt9oqGoKgJSpMHCbuHtfPI1ggx0ZwvLfoWzgD77Q 466 olASS5z4/6dT3taitXkgMvby1VMIBAiFYINzw0PS81eJqVO42ytZg0oPRKrxfcwfeWG 467 ied81gRS51IAE= 469 Example of EAT token (base64-encoded): 471 0oRDoQEmoFkCIqk6AAEk+1ggAAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8 472 6AAEk+lggAAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh86AAEk/YSkAlggAA 473 ECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8EZTMuMS40BVggAAECAwQFBgcIC 474 QoLDA0ODxAREhMUFRYXGBkaGxwdHh8BYkJMpAJYIAABAgMEBQYHCAkKCwwNDg8QERIT 475 FBUWFxgZGhscHR4fBGMxLjEFWCAAAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0 476 eHwFkUFJvVKQCWCAAAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHwRjMS4wBV 477 ggAAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8BZEFSb1SkAlggAAECAwQFB 478 gcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8EYzIuMgVYIAABAgMEBQYHCAkKCwwNDg8Q 479 ERITFBUWFxgZGhscHR4fAWNBcHA6AAEk+RkwADoAAST/WCAAAQIDBAUGBwgJCgsMDQ4 480 PEBESExQVFhcYGRobHB0eHzoAASUBbHBzYV92ZXJpZmllcjoAAST4IDoAASUAWCEBAA 481 ECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh86AAEk93FQU0FfSW9UX1BST0ZJT 482 EVfMVhAWIYFCO5+jMSOuoctu11pSlQrEyKtDVECPBlw30KfBlAcaDqVEIoMztCm6A4J 483 ZvIr1j0cAFaXShG6My14d4f7Tw== 485 Same token using extended CBOR diagnostic format: 487 18( 488 [ 489 / protected / h'a10126' / { 490 \ alg \ 1: -7 \ ECDSA 256 \ 491 } / , 492 / unprotected / {}, 493 / payload / h'a93a000124fb5820000102030405060708090a0b0c0d0e0f1011121 494 31415161718191a1b1c1d1e1f3a000124fa5820000102030405060708090a0b0c0d0e 495 0f101112131415161718191a1b1c1d1e1f3a000124fd84a4025820000102030405060 496 708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f0465332e312e34055820 497 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f01624 498 24ca4025820000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c 499 1d1e1f0463312e31055820000102030405060708090a0b0c0d0e0f101112131415161 500 718191a1b1c1d1e1f016450526f54a4025820000102030405060708090a0b0c0d0e0f 501 101112131415161718191a1b1c1d1e1f0463312e30055820000102030405060708090 502 a0b0c0d0e0f101112131415161718191a1b1c1d1e1f016441526f54a4025820000102 503 030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f0463322e320 504 55820000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 505 01634170703a000124f91930003a000124ff5820000102030405060708090a0b0c0d0 506 e0f101112131415161718191a1b1c1d1e1f3a000125016c7073615f76657269666965 507 723a000124f8203a00012500582101000102030405060708090a0b0c0d0e0f1011121 508 31415161718191a1b1c1d1e1f3a000124f7715053415f496f545f50524f46494c455f 509 31' / { 510 / arm_psa_boot_seed / -75004: h'000102030405060708090a0b0c0d0e0f10 511 1112131415161718191a1b1c1d1e1f', 512 / arm_psa_implementation_id / -75003: h'000102030405060708090a0b0c 513 0d0e0f101112131415161718191a1b1c1d1e1f', 514 / arm_psa_sw_components / -75006: [ 515 { 516 / measurement / 2: h'000102030405060708090a0b0c0d0e0f101112 517 131415161718191a1b1c1d1e1f', 518 / version / 4: "3.1.4", 519 / signerID / 5: h'000102030405060708090a0b0c0d0e0f101112131 520 415161718191a1b1c1d1e1f', 521 / type / 1: "BL" 522 }, 523 { 524 / measurement / 2: h'000102030405060708090a0b0c0d0e0f101112 525 131415161718191a1b1c1d1e1f', 526 / version / 4: "1.1", 527 / signerID / 5: h'000102030405060708090a0b0c0d0e0f101112131 528 415161718191a1b1c1d1e1f', 529 / type / 1: "PRoT" 530 }, 531 { 532 / measurement / 2: h'000102030405060708090a0b0c0d0e0f101112 533 131415161718191a1b1c1d1e1f', 534 / version / 4: "1.0", 535 / signerID / 5: h'000102030405060708090a0b0c0d0e0f101112131 536 415161718191a1b1c1d1e1f', 537 / type / 1: "ARoT" 538 }, 539 { 540 / measurement / 2: h'000102030405060708090a0b0c0d0e0f101112 541 131415161718191a1b1c1d1e1f', 542 / version / 4: "2.2", 543 / signerID / 5: h'000102030405060708090a0b0c0d0e0f101112131 544 415161718191a1b1c1d1e1f', 545 / type / 1: "App" 546 } 547 ], 548 / arm_psa_security_lifecycle / -75002: 12288 / SECURED /, 549 / arm_psa_nonce / -75008: h'000102030405060708090a0b0c0d0e0f10111 550 2131415161718191a1b1c1d1e1f', 551 / arm_psa_origination / -75010: "psa_verifier", 552 / arm_psa_partition_id / -75001: -1, 553 / arm_psa_UEID / -75009: h'01000102030405060708090a0b0c0d0e0f1011 554 12131415161718191a1b1c1d1e1f', 555 / arm_psa_profile_id / -75000: "PSA_IoT_PROFILE_1" 556 }), 557 } / , 558 / signature / h'58860508ee7e8cc48eba872dbb5d694a542b1322ad0d51023c197 559 0df429f06501c683a95108a0cced0a6e80e0966f22bd63d1c0056974a11ba332d7877 560 87fb4f' 561 ] 562 ) 564 7. Security and Privacy Considerations 566 This specification re-uses the CWT and the EAT specification. Hence, 567 the security and privacy considerations of those specifications apply 568 here as well. 570 Since CWTs offer different ways to protect the token this 571 specification profiles those options and only uses public key 572 cryptography. The token MUST be signed following the structure of 573 the COSE specification [RFC8152]. The COSE type MUST be COSE-Sign1. 575 Attestation tokens contain information that may be unique to a device 576 and therefore they may allow single out an individual device for 577 tracking purposes. Implementation must take to ensure that only 578 those claims are included that fulfil the purpose of the application 579 and that users of those devices consent to the data sharing. 581 8. IANA Considerations 583 IANA is requested to allocate the claims defined in Section 5 to the 584 [RFC8392] created CBOR Web Token (CWT) Claims registry [IANA-CWT]. 585 The change controller are the authors and the reference is this 586 document. 588 9. References 590 9.1. Normative References 592 [I-D.mandyam-eat] 593 Mandyam, G., Lundblade, L., Lundblade, L., Ballesteros, 594 M., and J. O'Donoghue, "The Entity Attestation Token 595 (EAT)", draft-mandyam-eat-01 (work in progress), November 596 2018. 598 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 599 Requirement Levels", BCP 14, RFC 2119, 600 DOI 10.17487/RFC2119, March 1997, 601 . 603 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 604 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 605 October 2013, . 607 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 608 RFC 8152, DOI 10.17487/RFC8152, July 2017, 609 . 611 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 612 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 613 May 2018, . 615 9.2. Informative References 617 [EAN-13] GS1, "International Article Number - EAN/UPC barcodes", 618 2019, . 620 [IANA-CWT] 621 IANA, "CBOR Web Token (CWT) Claims", 2019, 622 . 624 [PSA] Arm, "Platform Security Architecture Resources", 2019, 625 . 628 [PSA-FF] Arm, "Platform Security Architecture Firmware Framework 629 1.0 (PSA-FF)", February 2019, 630 . 632 [PSA-SM] Arm, "Platform Security Architecture Security Model 1.0 633 (PSA-SM)", February 2019, 634 . 636 [TF-M] Linaro, "Trusted Firmware", 2019, 637 . 639 Appendix A. Contributors 641 We would like to thank the following supporters for their 642 contributions: 644 * Laurence Lundblade 645 Security Theory LLC 646 lgl@securitytheory.com 648 * Tamas Ban 649 Arm Limited 650 Tamas.Ban@arm.com 652 Appendix B. Reference Implementation 654 Trusted Firmware M (TF-M) [TF-M] is the name of the open source 655 project that provides a reference implementation of PSA APIs, created 656 for the latest Arm v8-M microcontrollers with TrustZone technology. 657 TF-M provides foundational firmware components that silicon 658 manufacturers and OEMs can build on (including trusted boot, secure 659 device initialisation and secure function invocation). 661 Authors' Addresses 663 Hannes Tschofenig (editor) 664 Arm Limited 666 EMail: hannes.tschofenig@arm.com 668 Simon Frost 669 Arm Limited 671 EMail: Simon.Frost@arm.com 673 Mathias Brossard 674 Arm Limited 676 EMail: Mathias.Brossard@arm.com 678 Adrian Shaw 679 Arm Limited 681 EMail: Adrian.Shaw@arm.com