idnits 2.17.1 draft-tschofenig-rats-psa-token-04.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 (November 20, 2019) is 1617 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) == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-01 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, Ed. 3 Internet-Draft S. Frost 4 Intended status: Standards Track M. Brossard 5 Expires: May 23, 2020 A. Shaw 6 T. Fossati 7 Arm Limited 8 November 20, 2019 10 Arm's Platform Security Architecture (PSA) Attestation Token 11 draft-tschofenig-rats-psa-token-04 13 Abstract 15 The insecurity of IoT systems is a widely known and discussed 16 problem. The Arm Platform Security Architecture (PSA) is being 17 developed to address this challenge by making it easier to build 18 secure IoT systems. 20 This document specifies token format and claims used in the 21 attestation API of the Arm Platform Security Architecture (PSA). 23 At its core, the CWT (COSE Web Token) format is used and populated 24 with a set of claims, in a way similar to EAT (Entity Attestation 25 Token). This specification describes what claims are used by PSA 26 compliant systems and what has been implemented within Arm Trusted 27 Firmware-M. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 23, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 77 2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4 78 3. Information Model . . . . . . . . . . . . . . . . . . . . . . 5 79 3.1. PSA Lifecycle States . . . . . . . . . . . . . . . . . . 7 80 3.2. PSA Software Components . . . . . . . . . . . . . . . . . 7 81 4. Token Encoding . . . . . . . . . . . . . . . . . . . . . . . 9 82 5. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 7. Security and Privacy Considerations . . . . . . . . . . . . . 14 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 88 9.2. Informative References . . . . . . . . . . . . . . . . . 15 89 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 16 90 Appendix B. Reference Implementation . . . . . . . . . . . . . . 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 Modern hardware for Internet of Things devices contain trusted 96 execution environments and in case of the Arm v8-M architecture 97 TrustZone support. On these low end microcontrollers, TrustZone 98 enables the separation between a "normal world" and a "secure world" 99 where security sensitive code resides in the "secure world" and 100 applications running in the "normal world" request secure services 101 using a well-defined API. Various APIs have been developed by Arm as 102 part of the Platform Security Architecture [PSA] programme; this 103 document focuses on the functionality provided by the attestation 104 API. Since the tokens exposed via the attestation API are also 105 consumed by services outside the device, there is an actual need for 106 making them interoperable. In this specification these 107 interoperability needs are addressed by describing the exact syntax 108 and semantics of the attestation claims, and defining the way these 109 claims are encoded and cryptographically protected. 111 Further details on concepts expressed below can be found in the PSA 112 Security Model documentation [PSA-SM]. 114 Figure 1 provides a view of the architectural components and how they 115 interact. Applications on the IoT device communicate with services 116 residing in the "secure world" by means of a well-defined API. The 117 attestation API produces tokens, as described in this document, and 118 those tokens may be presented to network or application services. 120 .-----------------+------------------. 121 | Normal World | Secure World | 122 | | .-. | 123 | | |A| | 124 | | |T| | 125 | | |T| | 126 | | |E| .-. | 127 | | .-. |S| |S| | 128 | | |C| |T| |T| | 129 .----------. | | |R| |A| |O| | 130 | Network | | .----------. | |Y| |T| |R| | 131 | and App |<-------------+ Apps | .--+--. |P| |I| |A| | 132 | Services | | '----------' |P | | |T| |O| |G| | 133 '----------' | .----------. |S | | |O| |N| |E| | 134 | |Middleware| |A | | '-' '-' '-' | 135 | '----------' | | | .----------. | 136 | .----------. |A | | | | | 137 | | | |P | | | SPM | | 138 | | RTOS and | |I | | '----------' | 139 | | Drivers | '--+--' .----------. | 140 | | | | | Boot | | 141 | '----------' | | Loader | | 142 | | '----------' | 143 +-----------------+------------------+ 144 | H A R D|W A R E | 145 '-----------------+------------------' 147 Internet of Things Device 149 Figure 1: Software Architecture 151 2. Conventions and Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in 156 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 157 capitals, as shown here. 159 2.1. Glossary 161 RoT Root of Trust, the minimal set of software, hardware and data 162 that has to be implicitly trusted in the platform - there is no 163 software or hardware at a deeper level that can verify that the 164 Root of Trust is authentic and unmodified. 166 SPE Secure Processing Environment, a platform's processing 167 environment for software that provides confidentiality and 168 integrity for its runtime state, from software and hardware, 169 outside of the SPE. Contains the Secure Partition Manager (SPM), 170 the Secure Partitions and the trusted hardware. 172 NSPE Non Secure Processing Environment, the security domain outside 173 of the SPE, the Application domain, typically containing the 174 application firmware and hardware. 176 3. Information Model 178 Table 1 describes the mandatory and optional claims in the report. 180 +----------------+--------------+-----------------------------------+ 181 | Claim | Mandatory | Description | 182 +----------------+--------------+-----------------------------------+ 183 | Auth Challenge | Yes | Input object from the caller. For | 184 | | | example, this can be a | 185 | | | cryptographic nonce, a hash of | 186 | | | locally attested data. The length | 187 | | | must be 32, 48, or 64 bytes. | 188 | | | | 189 | Instance ID | Yes | Represents the unique identifier | 190 | | | of the instance. It is a hash of | 191 | | | the public key corresponding to | 192 | | | the Initial Attestation Key. The | 193 | | | full definition is in [PSA-SM]. | 194 | | | | 195 | Verification | No | A hint used by a relying party to | 196 | Service | | locate a validation service for | 197 | Indicator | | the token. The value is a text | 198 | | | string that can be used to locate | 199 | | | the service or a URL specifying | 200 | | | the address of the service. A | 201 | | | verifier may choose to ignore | 202 | | | this claim in favor of other | 203 | | | information. | 204 | | | | 205 | Profile | No | Contains the name of a document | 206 | Definition | | that describes the 'profile' of | 207 | | | the report. The document name may | 208 | | | include versioning. The value for | 209 | | | this specification is | 210 | | | PSA_IOT_PROFILE_1. | 211 | | | | 212 | Implementation | Yes | Uniquely identifies the | 213 | ID | | underlying immutable PSA RoT. A | 214 | | | verification service can use this | 215 | | | claim to locate the details of | 216 | | | the verification process. Such | 217 | | | details include the | 218 | | | implementation's origin and | 219 | | | associated certification state. | 220 | | | | 221 | Client ID | Yes | Represents the Partition ID of | 222 | | | the caller. It is a signed | 223 | | | integer whereby negative values | 224 | | | represent callers from the NSPE | 225 | | | and where positive IDs represent | 226 | | | callers from the SPE. The full | 227 | | | definition of the partition ID is | 228 | | | given in [PSA-FF]. | 229 | | | | 230 | Security | Yes | Represents the current lifecycle | 231 | Lifecycle | | state of the PSA RoT. The state | 232 | | | is represented by an integer that | 233 | | | is divided to convey a major | 234 | | | state and a minor state. A major | 235 | | | state is mandatory and defined by | 236 | | | [PSA-SM]. A minor state is | 237 | | | optional and 'IMPLEMENTATION | 238 | | | DEFINED'. The encoding is: | 239 | | | version[15:8] - PSA security | 240 | | | lifecycle state, and version[7:0] | 241 | | | - IMPLEMENTATION DEFINED state. | 242 | | | The PSA lifecycle states are | 243 | | | listed in Section 3.1. For PSA, a | 244 | | | remote verifier can only trust | 245 | | | reports from the PSA RoT when it | 246 | | | is in SECURED or | 247 | | | NON_PSA_ROT_DEBUG major states. | 248 | | | | 249 | Hardware | No | Provides metadata linking the | 250 | version | | token to the GDSII that went to | 251 | | | fabrication for this instance. It | 252 | | | can be used to link the class of | 253 | | | chip and PSA RoT to the data on a | 254 | | | certification website. It must be | 255 | | | represented as a thirteen-digit | 256 | | | [EAN-13] | 257 | | | | 258 | Boot Seed | Yes | Represents a random value created | 259 | | | at system boot time that will | 260 | | | allow differentiation of reports | 261 | | | from different boot sessions. | 262 | | | | 263 | Software | Yes (unless | A list of software components | 264 | Components | the No | that represent all the software | 265 | | Software | loaded by the PSA Root of Trust. | 266 | | Measurements | This claim is needed for the | 267 | | claim is | rules outlined in [PSA-SM]. The | 268 | | specified) | software components are further | 269 | | | detailed in Section 3.2. | 270 | | | | 271 | No Software | Yes (if no | In the event that the | 272 | Measurements | software | implementation does not contain | 273 | | components | any software measurements then | 274 | | specified) | the Software Components claim | 275 | | | above can be omitted but instead | 276 | | | it will be mandatory to include | 277 | | | this claim to indicate this is a | 278 | | | deliberate state. This claim is | 279 | | | intended for devices that are not | 280 | | | compliant with [PSA-SM]. | 281 +----------------+--------------+-----------------------------------+ 283 Table 1: Information Model of PSA Attestation Claims. 285 3.1. PSA Lifecycle States 287 The PSA lifecycle states consist of the following values: 289 - PSA_LIFECYCLE_UNKNOWN (0x0000u) 291 - PSA_LIFECYCLE_ASSEMBLY_AND_TEST (0x1000u) 293 - PSA_LIFECYCLE_PSA_ROT_PROVISIONING (0x2000u) 295 - PSA_LIFECYCLE_SECURED (0x3000u) 297 - PSA_LIFECYCLE_NON_PSA_ROT_DEBUG (0x4000u) 299 - PSA_LIFECYCLE_RECOVERABLE_PSA_ROT_DEBUG (0x5000u) 301 - PSA_LIFECYCLE_DECOMMISSIONED (0x6000u) 303 3.2. PSA Software Components 305 Each software component in the Software Components claim MUST include 306 the required properties of Table 2. 308 +-----+-------------+-----------+-----------------------------------+ 309 | Key | Type | Mandatory | Description | 310 | ID | | | | 311 +-----+-------------+-----------+-----------------------------------+ 312 | 1 | Measurement | No | A short string representing the | 313 | | Type | | role of this software component | 314 | | | | (e.g. 'BL' for Boot Loader). | 315 | | | | | 316 | 2 | Measurement | Yes | Represents a hash of the | 317 | | value | | invariant software component in | 318 | | | | memory at startup time. The value | 319 | | | | must be a cryptographic hash of | 320 | | | | 256 bits or stronger. | 321 | | | | | 322 | 3 | Reserved | No | Reserved | 323 | | | | | 324 | 4 | Version | No | The issued software version in | 325 | | | | the form of a text string. The | 326 | | | | value of this claim will | 327 | | | | correspond to the entry in the | 328 | | | | original signed manifest of the | 329 | | | | component. | 330 | | | | | 331 | 5 | Signer ID | No | The hash of a signing authority | 332 | | | | public key for the software | 333 | | | | component. The value of this | 334 | | | | claim will correspond to the | 335 | | | | entry in the original manifest | 336 | | | | for the component. This can be | 337 | | | | used by a verifier to ensure the | 338 | | | | components were signed by an | 339 | | | | expected trusted source. This | 340 | | | | field must be present to be | 341 | | | | compliant with [PSA-SM]. | 342 | | | | | 343 | 6 | Measurement | No | Description of the way in which | 344 | | description | | the measurement value of the | 345 | | | | software component is computed. | 346 | | | | The value will be a text string | 347 | | | | containing an abbreviated | 348 | | | | description (or name) of the | 349 | | | | measurement method which can be | 350 | | | | used to lookup the details of the | 351 | | | | method in a profile document. | 352 | | | | This claim will normally be | 353 | | | | excluded, unless there was an | 354 | | | | exception to the default | 355 | | | | measurement described in the | 356 | | | | profile for a specific component. | 357 +-----+-------------+-----------+-----------------------------------+ 359 Table 2: Software Components Claims. 361 The following measurement types are current defined: 363 - 'BL': a Boot Loader 365 - 'PRoT': a component of the PSA Root of Trust 367 - 'ARoT': a component of the Application Root of Trust 369 - 'App': a component of the NSPE application 371 - 'TS': a component of a Trusted Subsystem 373 4. Token Encoding 375 The report is encoded as a COSE Web Token (CWT) [RFC8392], similar to 376 the Entity Attestation Token (EAT) [I-D.ietf-rats-eat]. The token 377 consists of a series of claims declaring evidence as to the nature of 378 the instance of hardware and software. The claims are encoded in 379 CBOR [RFC7049] format. 381 5. Claims 383 The token is modelled to include custom values that correspond to the 384 following claims suggested in the EAT specification: 386 - nonce (mandatory); arm_psa_nonce is used instead 388 - UEID (mandatory); arm_psa_UEID is used instead 390 Later revisions of this documents might phase out those custom claims 391 to be replaced by the EAT standard claims. 393 As noted, some fields must be at least 32 bytes long to provide 394 sufficient cryptographic strength. 396 +-------+-------------+------------------------+--------------------+ 397 | Claim | Claim | Claim Name | CBOR Value Type | 398 | Key | Description | | | 399 +-------+-------------+------------------------+--------------------+ 400 | -7500 | Profile | arm_psa_profile_id | Text string | 401 | 0 | Definition | | | 402 | | | | | 403 | -7500 | Client ID | arm_psa_partition_id | Unsigned integer | 404 | 1 | | | or Negative | 405 | | | | integer | 406 | | | | | 407 | -7500 | Security | arm_psa_security_lifec | Unsigned integer | 408 | 2 | Lifecycle | ycle | | 409 | | | | | 410 | -7500 | Implementat | arm_psa_implementation | Byte string (>=32 | 411 | 3 | ion ID | _id | bytes) | 412 | | | | | 413 | -7500 | Boot Seed | arm_psa_boot_seed | Byte string (>=32 | 414 | 4 | | | bytes) | 415 | | | | | 416 | -7500 | Hardware | arm_psa_hw_version | Text string | 417 | 5 | Version | | | 418 | | | | | 419 | -7500 | Software | arm_psa_sw_components | Array of map | 420 | 6 | Components | | entries (compound | 421 | | | | map claim). See | 422 | | | | below for allowed | 423 | | | | key-values. | 424 | | | | | 425 | -7500 | No Software | arm_psa_no_sw_measurem | Unsigned integer | 426 | 7 | Measurement | ents | | 427 | | s | | | 428 | | | | | 429 | -7500 | Auth | arm_psa_nonce | Byte string | 430 | 8 | Challenge | | | 431 | | | | | 432 | -7500 | Instance ID | arm_psa_UEID | Byte string (the | 433 | 9 | | | type byte of the | 434 | | | | UEID should be set | 435 | | | | to 0x01. The type | 436 | | | | byte is described | 437 | | | | in [I-D.ietf-rats- | 438 | | | | eat].) | 439 | | | | | 440 | -7501 | Verificatio | arm_psa_origination | Byte string | 441 | 0 | n Service | | | 442 | | Indicator | | | 443 +-------+-------------+------------------------+--------------------+ 444 When using the Software Components claim each key value MUST 445 correspond to the following types: 447 1. Text string (type) 449 2. Byte string (measurement, >=32 bytes) 451 3. Reserved 453 4. Text string (version) 455 5. Byte string (signer ID, >=32 bytes) 457 6. Text string (measurement description) 459 6. Example 461 The following example shows an attestation token that was produced 462 for a device that has a single-stage bootloader, and an RTOS with a 463 device management client. From a code point of view, the RTOS and 464 the device management client form a single binary. 466 EC key using curve P-256 with: 468 - x: 469 0xdcf0d0f4bcd5e26a54ee36cad660d283d12abc5f7307de58689e77cd60452e75 471 - y: 472 0x8cbadb5fe9f89a7107e5a2e8ea44ec1b09b7da2a1a82a0252a4c1c26ee1ed7cf 474 - d: 475 0xc74670bcb7e85b3803efb428940492e73e3fe9d4f7b5a8ad5e480cbdbcb554c2 477 Key using COSE format (base64-encoded): 479 pSJYIIy621/p+JpxB+Wi6OpE7BsJt9oqGoKgJSpMHCbuHtfPI1ggx0ZwvLfoWzgD77Q 480 olASS5z4/6dT3taitXkgMvby1VMIBAiFYINzw0PS81eJqVO42ytZg0oPRKrxfcwfeWG 481 ied81gRS51IAE= 483 Example of EAT token (base64-encoded): 485 0oRDoQEmoFkCIqk6AAEk+1ggAAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8 486 6AAEk+lggAAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh86AAEk/YSkAlggAA 487 ECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8EZTMuMS40BVggAAECAwQFBgcIC 488 QoLDA0ODxAREhMUFRYXGBkaGxwdHh8BYkJMpAJYIAABAgMEBQYHCAkKCwwNDg8QERIT 489 FBUWFxgZGhscHR4fBGMxLjEFWCAAAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0 490 eHwFkUFJvVKQCWCAAAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHwRjMS4wBV 491 ggAAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8BZEFSb1SkAlggAAECAwQFB 492 gcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8EYzIuMgVYIAABAgMEBQYHCAkKCwwNDg8Q 493 ERITFBUWFxgZGhscHR4fAWNBcHA6AAEk+RkwADoAAST/WCAAAQIDBAUGBwgJCgsMDQ4 494 PEBESExQVFhcYGRobHB0eHzoAASUBbHBzYV92ZXJpZmllcjoAAST4IDoAASUAWCEBAA 495 ECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh86AAEk93FQU0FfSW9UX1BST0ZJT 496 EVfMVhAWIYFCO5+jMSOuoctu11pSlQrEyKtDVECPBlw30KfBlAcaDqVEIoMztCm6A4J 497 ZvIr1j0cAFaXShG6My14d4f7Tw== 499 Same token using extended CBOR diagnostic format: 501 18( 502 [ 503 / protected / h'a10126' / { 504 \ alg \ 1: -7 \ ECDSA 256 \ 505 } / , 506 / unprotected / {}, 507 / payload / h'a93a000124fb5820000102030405060708090a0b0c0d0e0f1011121 508 31415161718191a1b1c1d1e1f3a000124fa5820000102030405060708090a0b0c0d0e 509 0f101112131415161718191a1b1c1d1e1f3a000124fd84a4025820000102030405060 510 708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f0465332e312e34055820 511 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f01624 512 24ca4025820000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c 513 1d1e1f0463312e31055820000102030405060708090a0b0c0d0e0f101112131415161 514 718191a1b1c1d1e1f016450526f54a4025820000102030405060708090a0b0c0d0e0f 515 101112131415161718191a1b1c1d1e1f0463312e30055820000102030405060708090 516 a0b0c0d0e0f101112131415161718191a1b1c1d1e1f016441526f54a4025820000102 517 030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f0463322e320 518 55820000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 519 01634170703a000124f91930003a000124ff5820000102030405060708090a0b0c0d0 520 e0f101112131415161718191a1b1c1d1e1f3a000125016c7073615f76657269666965 521 723a000124f8203a00012500582101000102030405060708090a0b0c0d0e0f1011121 522 31415161718191a1b1c1d1e1f3a000124f7715053415f496f545f50524f46494c455f 523 31' / { 524 / arm_psa_boot_seed / -75004: h'000102030405060708090a0b0c0d0e0f10 525 1112131415161718191a1b1c1d1e1f', 526 / arm_psa_implementation_id / -75003: h'000102030405060708090a0b0c 527 0d0e0f101112131415161718191a1b1c1d1e1f', 528 / arm_psa_sw_components / -75006: [ 529 { 530 / measurement / 2: h'000102030405060708090a0b0c0d0e0f101112 531 131415161718191a1b1c1d1e1f', 532 / version / 4: "3.1.4", 533 / signerID / 5: h'000102030405060708090a0b0c0d0e0f101112131 534 415161718191a1b1c1d1e1f', 535 / type / 1: "BL" 536 }, 537 { 538 / measurement / 2: h'000102030405060708090a0b0c0d0e0f101112 539 131415161718191a1b1c1d1e1f', 540 / version / 4: "1.1", 541 / signerID / 5: h'000102030405060708090a0b0c0d0e0f101112131 542 415161718191a1b1c1d1e1f', 543 / type / 1: "PRoT" 544 }, 545 { 546 / measurement / 2: h'000102030405060708090a0b0c0d0e0f101112 547 131415161718191a1b1c1d1e1f', 548 / version / 4: "1.0", 549 / signerID / 5: h'000102030405060708090a0b0c0d0e0f101112131 550 415161718191a1b1c1d1e1f', 551 / type / 1: "ARoT" 552 }, 553 { 554 / measurement / 2: h'000102030405060708090a0b0c0d0e0f101112 555 131415161718191a1b1c1d1e1f', 556 / version / 4: "2.2", 557 / signerID / 5: h'000102030405060708090a0b0c0d0e0f101112131 558 415161718191a1b1c1d1e1f', 559 / type / 1: "App" 560 } 561 ], 562 / arm_psa_security_lifecycle / -75002: 12288 / SECURED /, 563 / arm_psa_nonce / -75008: h'000102030405060708090a0b0c0d0e0f10111 564 2131415161718191a1b1c1d1e1f', 565 / arm_psa_origination / -75010: "psa_verifier", 566 / arm_psa_partition_id / -75001: -1, 567 / arm_psa_UEID / -75009: h'01000102030405060708090a0b0c0d0e0f1011 568 12131415161718191a1b1c1d1e1f', 569 / arm_psa_profile_id / -75000: "PSA_IoT_PROFILE_1" 570 }), 571 } / , 572 / signature / h'58860508ee7e8cc48eba872dbb5d694a542b1322ad0d51023c197 573 0df429f06501c683a95108a0cced0a6e80e0966f22bd63d1c0056974a11ba332d7877 574 87fb4f' 575 ] 576 ) 578 7. Security and Privacy Considerations 580 This specification re-uses the CWT and the EAT specification. Hence, 581 the security and privacy considerations of those specifications apply 582 here as well. 584 Since CWTs offer different ways to protect the token this 585 specification profiles those options and only uses public key 586 cryptography. The token MUST be signed following the structure of 587 the COSE specification [RFC8152]. The COSE type MUST be COSE-Sign1. 589 Attestation tokens contain information that may be unique to a device 590 and therefore they may allow to single out an individual device for 591 tracking purposes. Implementation must take appropriate measures to 592 ensure that only those claims are included that fulfil the purpose of 593 the application and that users of those devices consent to the data 594 sharing. 596 8. IANA Considerations 598 IANA is requested to allocate the claims defined in Section 5 to the 599 CBOR Web Token (CWT) Claims registry [IANA-CWT]. The change 600 controller are the authors and the reference is this document. 602 9. References 604 9.1. Normative References 606 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 607 Requirement Levels", BCP 14, RFC 2119, 608 DOI 10.17487/RFC2119, March 1997, 609 . 611 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 612 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 613 October 2013, . 615 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 616 RFC 8152, DOI 10.17487/RFC8152, July 2017, 617 . 619 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 620 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 621 May 2017, . 623 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 624 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 625 May 2018, . 627 9.2. Informative References 629 [EAN-13] GS1, "International Article Number - EAN/UPC barcodes", 630 2019, . 632 [I-D.ietf-rats-eat] 633 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 634 O'Donoghue, "The Entity Attestation Token (EAT)", draft- 635 ietf-rats-eat-01 (work in progress), July 2019. 637 [IANA-CWT] 638 IANA, "CBOR Web Token (CWT) Claims", 2019, 639 . 641 [PSA] Arm, "Platform Security Architecture Resources", 2019, 642 . 645 [PSA-FF] Arm, "Platform Security Architecture Firmware Framework 646 1.0 (PSA-FF)", February 2019, 647 . 649 [PSA-SM] Arm, "Platform Security Architecture Security Model 1.0 650 (PSA-SM)", February 2019, 651 . 653 [TF-M] Linaro, "Trusted Firmware", 2019, 654 . 656 Appendix A. Contributors 658 We would like to thank the following supporters for their 659 contributions: 661 * Laurence Lundblade 662 Security Theory LLC 663 lgl@securitytheory.com 665 * Tamas Ban 666 Arm Limited 667 Tamas.Ban@arm.com 669 Appendix B. Reference Implementation 671 Trusted Firmware M (TF-M) [TF-M] is the name of the open source 672 project that provides a reference implementation of PSA APIs and an 673 SPM, created for the latest Arm v8-M microcontrollers with TrustZone 674 technology. TF-M provides foundational firmware components that 675 silicon manufacturers and OEMs can build on (including trusted boot, 676 secure device initialisation and secure function invocation). 678 Authors' Addresses 680 Hannes Tschofenig (editor) 681 Arm Limited 683 EMail: hannes.tschofenig@arm.com 685 Simon Frost 686 Arm Limited 688 EMail: Simon.Frost@arm.com 690 Mathias Brossard 691 Arm Limited 693 EMail: Mathias.Brossard@arm.com 695 Adrian Shaw 696 Arm Limited 698 EMail: Adrian.Shaw@arm.com 699 Thomas Fossati 700 Arm Limited 702 EMail: thomas.fossati@arm.com