idnits 2.17.00 (12 Aug 2021) /tmp/idnits9428/draft-ietf-teep-protocol-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 October 2021) is 207 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) == Unused Reference: 'RFC8126' is defined on line 1307, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-rats-architecture-12 ** Downref: Normative reference to an Informational draft: draft-ietf-rats-architecture (ref. 'I-D.ietf-rats-architecture') == Outdated reference: A later version (-12) exists of draft-ietf-rats-eat-11 ** Downref: Normative reference to an Informational draft: draft-moran-suit-report (ref. 'I-D.moran-suit-report') ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-03) exists of draft-birkholz-rats-suit-claims-02 == Outdated reference: A later version (-17) exists of draft-ietf-teep-architecture-15 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEEP H. Tschofenig 3 Internet-Draft Arm Ltd. 4 Intended status: Standards Track M. Pei 5 Expires: 28 April 2022 Broadcom 6 D. Wheeler 7 Amazon 8 D. Thaler 9 Microsoft 10 A. Tsukamoto 11 AIST 12 25 October 2021 14 Trusted Execution Environment Provisioning (TEEP) Protocol 15 draft-ietf-teep-protocol-07 17 Abstract 19 This document specifies a protocol that installs, updates, and 20 deletes Trusted Components in a device with a Trusted Execution 21 Environment (TEE). This specification defines an interoperable 22 protocol for managing the lifecycle of Trusted Components. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 28 April 2022. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Message Overview . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Detailed Messages Specification . . . . . . . . . . . . . . . 5 61 4.1. Creating and Validating TEEP Messages . . . . . . . . . . 5 62 4.1.1. Creating a TEEP message . . . . . . . . . . . . . . . 5 63 4.1.2. Validating a TEEP Message . . . . . . . . . . . . . . 6 64 4.2. QueryRequest Message . . . . . . . . . . . . . . . . . . 6 65 4.3. QueryResponse Message . . . . . . . . . . . . . . . . . . 9 66 4.3.1. Evidence . . . . . . . . . . . . . . . . . . . . . . 11 67 4.4. Update Message . . . . . . . . . . . . . . . . . . . . . 12 68 4.5. Success Message . . . . . . . . . . . . . . . . . . . . . 14 69 4.6. Error Message . . . . . . . . . . . . . . . . . . . . . . 15 70 5. Mapping of TEEP Message Parameters to CBOR Labels . . . . . . 18 71 6. Behavior Specification . . . . . . . . . . . . . . . . . . . 20 72 6.1. TAM Behavior . . . . . . . . . . . . . . . . . . . . . . 20 73 6.2. TEEP Agent Behavior . . . . . . . . . . . . . . . . . . . 21 74 7. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 22 75 8. Freshness Mechanisms . . . . . . . . . . . . . . . . . . . . 22 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 78 10.1. Media Type Registration . . . . . . . . . . . . . . . . 25 79 10.2. Ciphersuite Registry . . . . . . . . . . . . . . . . . . 26 80 10.3. Freshness Mechanism Registry . . . . . . . . . . . . . . 27 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 82 11.1. Normative References . . . . . . . . . . . . . . . . . . 27 83 11.2. Informative References . . . . . . . . . . . . . . . . . 29 84 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 85 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 86 C. Complete CDDL . . . . . . . . . . . . . . . . . . . . . . . . 30 87 D. Examples of Diagnostic Notation and Binary Representation . . 34 88 D.1. QueryRequest Message . . . . . . . . . . . . . . . . . . 34 89 D.1.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 34 90 D.1.2. CBOR Binary Representation . . . . . . . . . . . . . 34 91 D.2. Entity Attestation Token . . . . . . . . . . . . . . . . 35 92 D.2.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 35 93 D.3. QueryResponse Message . . . . . . . . . . . . . . . . . . 35 94 D.3.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 35 95 D.3.2. CBOR Binary Representation . . . . . . . . . . . . . 36 96 D.4. Update Message . . . . . . . . . . . . . . . . . . . . . 37 97 D.4.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 37 98 D.4.2. CBOR Binary Representation . . . . . . . . . . . . . 37 99 D.5. Success Message . . . . . . . . . . . . . . . . . . . . . 38 100 D.5.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 38 101 D.5.2. CBOR Binary Representation . . . . . . . . . . . . . 38 102 D.6. Error Message . . . . . . . . . . . . . . . . . . . . . . 38 103 D.6.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 38 104 D.6.2. CBOR binary Representation . . . . . . . . . . . . . 39 105 E. Examples of SUIT Manifests . . . . . . . . . . . . . . . . . 39 106 E.1. Install a Trusted Component . . . . . . . . . . . . . . . 39 107 E.2. Delete a Trusted Component . . . . . . . . . . . . . . . 43 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 110 1. Introduction 112 The Trusted Execution Environment (TEE) concept has been designed to 113 separate a regular operating system, also referred as a Rich 114 Execution Environment (REE), from security-sensitive applications. 115 In a TEE ecosystem, device vendors may use different operating 116 systems in the REE and may use different types of TEEs. When Trusted 117 Component Developers or Device Administrators use Trusted Application 118 Managers (TAMs) to install, update, and delete Trusted Applications 119 and their dependencies on a wide range of devices with potentially 120 different TEEs then an interoperability need arises. 122 This document specifies the protocol for communicating between a TAM 123 and a TEEP Agent. 125 The Trusted Execution Environment Provisioning (TEEP) architecture 126 document [I-D.ietf-teep-architecture] provides design guidance and 127 introduces the necessary terminology. 129 2. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in 134 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 135 capitals, as shown here. 137 This specification re-uses the terminology defined in 138 [I-D.ietf-teep-architecture]. 140 As explained in Section 4.4 of that document, the TEEP protocol 141 treats each Trusted Application (TA), any dependencies the TA has, 142 and personalization data as separate components that are expressed in 143 SUIT manifests, and a SUIT manifest might contain or reference 144 multiple binaries (see [I-D.ietf-suit-manifest] for more details). 146 As such, the term Trusted Component (TC) in this document refers to a 147 set of binaries expressed in a SUIT manifest, to be installed in a 148 TEE. Note that a Trusted Component may include one or more TAs and/ 149 or configuration data and keys needed by a TA to operate correctly. 151 Each Trusted Component is uniquely identified by a SUIT Component 152 Identifier (see [I-D.ietf-suit-manifest] Section 8.7.2.2). 154 3. Message Overview 156 The TEEP protocol consists of messages exchanged between a TAM and a 157 TEEP Agent. The messages are encoded in CBOR and designed to provide 158 end-to-end security. TEEP protocol messages are signed by the 159 endpoints, i.e., the TAM and the TEEP Agent, but Trusted Applications 160 may also be encrypted and signed by a Trusted Component Developer or 161 Device Administrator. The TEEP protocol not only uses CBOR but also 162 the respective security wrapper, namely COSE [RFC8152]. Furthermore, 163 for software updates the SUIT manifest format 164 [I-D.ietf-suit-manifest] is used, and for attestation the Entity 165 Attestation Token (EAT) [I-D.ietf-rats-eat] format is supported 166 although other attestation formats are also permitted. 168 This specification defines five messages: QueryRequest, 169 QueryResponse, Update, Success, and Error. 171 A TAM queries a device's current state with a QueryRequest message. 172 A TEEP Agent will, after authenticating and authorizing the request, 173 report attestation information, list all Trusted Components, and 174 provide information about supported algorithms and extensions in a 175 QueryResponse message. An error message is returned if the request 176 could not be processed. A TAM will process the QueryResponse message 177 and determine whether to initiate subsequent message exchanges to 178 install, update, or delete Trusted Applications. 180 +------------+ +-------------+ 181 | TAM | |TEEP Agent | 182 +------------+ +-------------+ 184 QueryRequest -------> 186 QueryResponse 188 <------- or 190 Error 192 With the Update message a TAM can instruct a TEEP Agent to install 193 and/or delete one or more Trusted Components. The TEEP Agent will 194 process the message, determine whether the TAM is authorized and 195 whether the Trusted Component has been signed by an authorized 196 Trusted Component Signer. A Success message is returned when the 197 operation has been completed successfully, or an Error message 198 otherwise. 200 +------------+ +-------------+ 201 | TAM | |TEEP Agent | 202 +------------+ +-------------+ 204 Update ----> 206 Success 208 <---- or 210 Error 212 4. Detailed Messages Specification 214 TEEP messages are protected by the COSE_Sign1 structure. The TEEP 215 protocol messages are described in CDDL format [RFC8610] below. 217 { 218 teep-message => (query-request / 219 query-response / 220 update / 221 teep-success / 222 teep-error ), 223 } 225 4.1. Creating and Validating TEEP Messages 227 4.1.1. Creating a TEEP message 229 To create a TEEP message, the following steps are performed. 231 1. Create a TEEP message according to the description below and 232 populate it with the respective content. TEEP messages sent by 233 TAMs (QueryRequest and Update) can include a "token". The first 234 usage of a token generated by a TAM MUST be randomly created. 235 Subsequent token values MUST be different for each subsequent 236 message created by a TAM. 238 2. Create a COSE Header containing the desired set of Header 239 Parameters. The COSE Header MUST be valid per the [RFC8152] 240 specification. 242 3. Create a COSE_Sign1 object using the TEEP message as the 243 COSE_Sign1 Payload; all steps specified in [RFC8152] for creating 244 a COSE_Sign1 object MUST be followed. 246 4.1.2. Validating a TEEP Message 248 When TEEP message is received (see the ProcessTeepMessage conceptual 249 API defined in [I-D.ietf-teep-architecture] section 6.2.1), the 250 following validation steps are performed. If any of the listed steps 251 fail, then the TEEP message MUST be rejected. 253 1. Verify that the received message is a valid CBOR object. 255 2. Verify that the message contains a COSE_Sign1 structure. 257 3. Verify that the resulting COSE Header includes only parameters 258 and values whose syntax and semantics are both understood and 259 supported or that are specified as being ignored when not 260 understood. 262 4. Follow the steps specified in Section 4 of [RFC8152] ("Signing 263 Objects") for validating a COSE_Sign1 object. The COSE_Sign1 264 payload is the content of the TEEP message. 266 5. Verify that the TEEP message is a valid CBOR map and verify the 267 fields of the TEEP message according to this specification. 269 4.2. QueryRequest Message 271 A QueryRequest message is used by the TAM to learn information from 272 the TEEP Agent, such as the features supported by the TEEP Agent, 273 including ciphersuites, and protocol versions. Additionally, the TAM 274 can selectively request data items from the TEEP Agent via the 275 request parameter. Currently, the following features are supported: 277 * Request for attestation information, 279 * Listing supported extensions, 281 * Querying installed Trusted Components, and 283 * Listing supported SUIT commands. 285 Like other TEEP messages, the QueryRequest message is signed, and the 286 relevant CDDL snippet is shown below. The complete CDDL structure is 287 shown in Appendix C. 289 query-request = [ 290 type: TEEP-TYPE-query-request, 291 options: { 292 ? token => bstr .size (8..64), 293 ? supported-cipher-suites => [ + suite ], 294 ? supported-freshness-mechanisms => [ + freshness-mechanism ], 295 ? challenge => bstr .size (8..512), 296 ? versions => [ + version ], 297 * $$query-request-extensions 298 * $$teep-option-extensions 299 }, 300 data-item-requested: data-item-requested 301 ] 303 The message has the following fields: 305 type 306 The value of (1) corresponds to a QueryRequest message sent from 307 the TAM to the TEEP Agent. 309 token 310 The value in the token parameter is used to match responses to 311 requests. This is particularly useful when a TAM issues multiple 312 concurrent requests to a TEEP Agent. The token MUST be present if 313 and only if the attestation bit is clear in the data-item- 314 requested value. The size of the token is at least 8 bytes (64 315 bits) and maximum of 64 bytes, which is the same as in an EAT 316 Nonce Claim (see [I-D.ietf-rats-eat] Section 3.3). The first 317 usage of a token generated by a TAM MUST be randomly created. 318 Subsequent token values MUST be different for each request message 319 to distinguish the correct response from multiple requests. The 320 token value MUST NOT be used for other purposes, such as a TAM to 321 identify the devices and/or a device to identify TAMs or Trusted 322 Components. The TAM SHOULD set an expiration time for each token 323 and MUST ignore any messages with expired tokens. The TAM MUST 324 expire the token value after receiving the first response 325 containing the token value and ignore any subsequent messages that 326 have the same token value. 328 data-item-requested 329 The data-item-requested parameter indicates what information the 330 TAM requests from the TEEP Agent in the form of a bitmap. Each 331 value in the bitmap corresponds to an IANA registered information 332 element. This specification defines the following initial set of 333 information elements: 335 attestation (1) With this value the TAM requests the TEEP Agent 336 to return attestation evidence (e.g., an EAT) in the response. 338 trusted-components (2) With this value the TAM queries the TEEP 339 Agent for all installed Trusted Components. 341 extensions (4) With this value the TAM queries the TEEP Agent for 342 supported capabilities and extensions, which allows a TAM to 343 discover the capabilities of a TEEP Agent implementation. 345 Further values may be added in the future via IANA registration. 347 supported-cipher-suites 348 The supported-cipher-suites parameter lists the ciphersuite(s) 349 supported by the TAM. If this parameter is not present, it is to 350 be treated the same as if it contained both ciphersuites defined 351 in this document. Details about the ciphersuite encoding can be 352 found in Section 7. 354 supported-freshness-mechanisms 355 The supported-freshness-mechanisms parameter lists the freshness 356 mechanism(s) supported by the TAM. Details about the encoding can 357 be found in Section 8. If this parameter is absent, it means only 358 the nonce mechanism is supported. 360 challenge 361 The challenge field is an optional parameter used for ensuring the 362 freshness of the attestation evidence returned with a 363 QueryResponse message. It MUST be absent if the attestation bit 364 is clear (since the token is used instead in that case). When a 365 challenge is provided in the QueryRequest and an EAT is returned 366 with a QueryResponse message then the challenge contained in this 367 request MUST be used to generate the EAT, such as by copying the 368 challengt into the nonce claim found in the EAT if using the Nonce 369 freshness mechanism. For more details see Section 8. If any 370 format other than EAT is used, it is up to that format to define 371 the use of the challenge field. 373 versions 374 The versions parameter enumerates the TEEP protocol version(s) 375 supported by the TAM. A value of 0 refers to the current version 376 of the TEEP protocol. If this field is not present, it is to be 377 treated the same as if it contained only version 0. 379 4.3. QueryResponse Message 381 The QueryResponse message is the successful response by the TEEP 382 Agent after receiving a QueryRequest message. 384 Like other TEEP messages, the QueryResponse message is signed, and 385 the relevant CDDL snippet is shown below. The complete CDDL 386 structure is shown in Appendix C. 388 query-response = [ 389 type: TEEP-TYPE-query-response, 390 options: { 391 ? token => bstr .size (8..64), 392 ? selected-cipher-suite => suite, 393 ? selected-version => version, 394 ? evidence-format => text, 395 ? evidence => bstr, 396 ? tc-list => [ + tc-info ], 397 ? requested-tc-list => [ + requested-tc-info ], 398 ? unneeded-tc-list => [ + SUIT_Component_Identifier ], 399 ? ext-list => [ + ext-info ], 400 * $$query-response-extensions, 401 * $$teep-option-extensions 402 } 403 ] 405 tc-info = { 406 component-id => SUIT_Component_Identifier, 407 ? tc-manifest-sequence-number => .within uint .size 8 408 } 410 requested-tc-info = { 411 component-id => SUIT_Component_Identifier, 412 ? tc-manifest-sequence-number => .within uint .size 8 413 ? have-binary => bool 414 } 416 The QueryResponse message has the following fields: 418 type 419 The value of (2) corresponds to a QueryResponse message sent from 420 the TEEP Agent to the TAM. 422 token 423 The value in the token parameter is used to match responses to 424 requests. The value MUST correspond to the value received with 425 the QueryRequest message if one was present, and MUST be absent if 426 no token was present in the QueryRequest. 428 selected-cipher-suite 429 The selected-cipher-suite parameter indicates the selected 430 ciphersuite. Details about the ciphersuite encoding can be found 431 in Section 7. 433 selected-version 434 The selected-version parameter indicates the TEEP protocol version 435 selected by the TEEP Agent. The absense of this parameter 436 indicates the same as if it was present with a value of 0. 438 evidence-format 439 The evidence-format parameter indicates the IANA Media Type of the 440 attestation evidence contained in the evidence parameter. It MUST 441 be present if the evidence parameter is present and the format is 442 not an EAT. 444 evidence 445 The evidence parameter contains the attestation evidence. This 446 parameter MUST be present if the QueryResponse is sent in response 447 to a QueryRequest with the attestation bit set. If the evidence- 448 format parameter is absent, the attestation evidence contained in 449 this parameter MUST be an Entity Attestation Token following the 450 encoding defined in [I-D.ietf-rats-eat]. See Section 4.3.1 for 451 further discussion. 453 tc-list 454 The tc-list parameter enumerates the Trusted Components installed 455 on the device in the form of tc-info objects. This parameter MUST 456 be present if the QueryResponse is sent in response to a 457 QueryRequest with the trusted-components bit set. 459 requested-tc-list 460 The requested-tc-list parameter enumerates the Trusted Components 461 that are not currently installed in the TEE, but which are 462 requested to be installed, for example by an installer of an 463 Untrusted Application that has a TA as a dependency, or by a 464 Trusted Application that has another Trusted Component as a 465 dependency. Requested Trusted Components are expressed in the 466 form of requested-tc-info objects. A TEEP Agent can get this 467 information from the UnrequestTA conceptual API defined in 468 [I-D.ietf-teep-architecture] section 6.2.1. 470 unneeded-tc-list 471 The unneeded-tc-list parameter enumerates the Trusted Components 472 that are currently installed in the TEE, but which are no longer 473 needed by any other application. The TAM can use this information 474 in determining whether a Trusted Component can be deleted. Each 475 unneeded Trusted Component is identified by its SUIT Component 476 Identifier. A TEEP Agent can get this information from the 477 UnrequestTA conceptual API defined in [I-D.ietf-teep-architecture] 478 section 6.2.1. 480 ext-list 481 The ext-list parameter lists the supported extensions. This 482 document does not define any extensions. This parameter MUST be 483 present if the QueryResponse is sent in response to a QueryRequest 484 with the extensions bit set. 486 The tc-info object has the following fields: 488 component-id 489 A SUIT Component Identifier. 491 tc-manifest-sequence-number 492 The suit-manifest-sequence-number value from the SUIT manifest for 493 the Trusted Component, if a SUIT manifest was used. 495 The requested-tc-info message has the following fields: 497 component-id 498 A SUIT Component Identifier. 500 tc-manifest-sequence-number 501 The minimum suit-manifest-sequence-number value from a SUIT 502 manifest for the Trusted Component. If not present, indicates 503 that any sequence number will do. 505 have-binary 506 If present with a value of true, indicates that the TEEP agent 507 already has the Trusted Component binary and only needs an Update 508 message with a SUIT manifest that authorizes installing it. If 509 have-binary is true, the tc-manifest-sequence-number field MUST be 510 present. 512 4.3.1. Evidence 514 Section 7.1 of [I-D.ietf-teep-architecture] lists information that 515 may be required in the evidence depend on the circumstance. When an 516 Entity Attestation Token is used, the following claims can be used to 517 meet those requirements: 519 +===========+=====================+=================================+ 520 |Requirement|Claim | Reference | 521 +===========+=====================+=================================+ 522 |Device |device-identifier | [I-D.birkholz-rats-suit-claims] | 523 |unique | | section 3.1.3 | 524 |identifier | | | 525 +-----------+---------------------+---------------------------------+ 526 |Vendor of |vendor-identifier | [I-D.birkholz-rats-suit-claims] | 527 |the device | | section 3.1.1 | 528 +-----------+---------------------+---------------------------------+ 529 |Class of |class-identifier | [I-D.birkholz-rats-suit-claims] | 530 |the device | | section 3.1.2 | 531 +-----------+---------------------+---------------------------------+ 532 |TEE |chip-version | [I-D.ietf-rats-eat] section 3.7 | 533 |hardware | | | 534 |type | | | 535 +-----------+---------------------+---------------------------------+ 536 |TEE |chip-version | [I-D.ietf-rats-eat] section 3.7 | 537 |hardware | | | 538 |version | | | 539 +-----------+---------------------+---------------------------------+ 540 |TEE |component-identifier | [I-D.birkholz-rats-suit-claims] | 541 |firmware | | section 3.1.4 | 542 |type | | | 543 +-----------+---------------------+---------------------------------+ 544 |TEE |version | [I-D.birkholz-rats-suit-claims] | 545 |firmware | | section 3.1.8 | 546 |version | | | 547 +-----------+---------------------+---------------------------------+ 548 |Freshness |nonce | [I-D.ietf-rats-eat] section 3.3 | 549 |proof | | | 550 +-----------+---------------------+---------------------------------+ 552 Table 1 554 4.4. Update Message 556 The Update message is used by the TAM to install and/or delete one or 557 more Trusted Components via the TEEP Agent. 559 Like other TEEP messages, the Update message is signed, and the 560 relevant CDDL snippet is shown below. The complete CDDL structure is 561 shown in Appendix C. 563 update = [ 564 type: TEEP-TYPE-update, 565 options: { 566 ? token => bstr .size (8..64), 567 ? manifest-list => [ + bstr .cbor SUIT_Envelope ], 568 * $$update-extensions, 569 * $$teep-option-extensions 570 } 571 ] 573 The Update message has the following fields: 575 type 576 The value of (3) corresponds to an Update message sent from the 577 TAM to the TEEP Agent. In case of successful processing, a 578 Success message is returned by the TEEP Agent. In case of an 579 error, an Error message is returned. Note that the Update message 580 is used for initial Trusted Component installation as well as for 581 updates and deletes. 583 token 584 The value in the token field is used to match responses to 585 requests. 587 manifest-list 588 The manifest-list field is used to convey one or multiple SUIT 589 manifests to install. A manifest is a bundle of metadata about a 590 Trusted Component, such as where to find the code, the devices to 591 which it applies, and cryptographic information protecting the 592 manifest. The manifest may also convey personalization data. 593 Trusted Component binaries and personalization data can be signed 594 and encrypted by the same Trusted Component Signer. Other 595 combinations are, however, possible as well. For example, it is 596 also possible for the TAM to sign and encrypt the personalization 597 data and to let the Trusted Component Developer sign and/or 598 encrypt the Trusted Component binary. 600 Note that an Update message carrying one or more SUIT manifests will 601 inherently involve multiple signatures, one by the TAM in the TEEP 602 message and one from a Trusted Component signer inside each manifest. 603 This is intentional as they are for different purposes. 605 The TAM is what authorizes apps to be installed, updated, and deleted 606 on a given TEE and so the TEEP signature is checked by the TEEP Agent 607 at protocol message processing time. (This same TEEP security 608 wrapper is also used on messages like QueryRequest so that Agents 609 only send potentially sensitive data such as evidence to trusted 610 TAMs.) 611 The Trusted Component signer on the other hand is what authorizes the 612 Trusted Component to actually run, so the manifest signature could be 613 checked at install time or load (or run) time or both, and this 614 checking is done by the TEE independent of whether TEEP is used or 615 some other update mechanism. See section 5 of 616 [I-D.ietf-teep-architecture] for further discussion. 618 4.5. Success Message 620 The Success message is used by the TEEP Agent to return a success in 621 response to an Update message. 623 Like other TEEP messages, the Success message is signed, and the 624 relevant CDDL snippet is shown below. The complete CDDL structure is 625 shown in Appendix C. 627 teep-success = [ 628 type: TEEP-TYPE-teep-success, 629 options: { 630 ? token => bstr .size (8..64), 631 ? msg => text .size (1..128), 632 ? suit-reports => [ + suit-report ], 633 * $$teep-success-extensions, 634 * $$teep-option-extensions 635 } 636 ] 638 The Success message has the following fields: 640 type 641 The value of (5) corresponds to corresponds to a Success message 642 sent from the TEEP Agent to the TAM. 644 token 645 The value in the token parameter is used to match responses to 646 requests. It MUST match the value of the token parameter in the 647 Update message the Success is in response to, if one was present. 648 If none was present, the token MUST be absent in the Success 649 message. 651 msg 652 The msg parameter contains optional diagnostics information 653 encoded in UTF-8 [RFC3629] using Net-Unicode form [RFC5198] with 654 max 128 bytes returned by the TEEP Agent. 656 suit-reports 657 If present, the suit-reports parameter contains a set of SUIT 658 Reports as defined in Section 4 of [I-D.moran-suit-report]. If 659 the suit-report-nonce field is present in the SUIT Report, is 660 value MUST match the value of the token parameter in the Update 661 message the Success message is in response to. 663 4.6. Error Message 665 The Error message is used by the TEEP Agent to return an error in 666 response to an Update message. 668 Like other TEEP messages, the Error message is signed, and the 669 relevant CDDL snippet is shown below. The complete CDDL structure is 670 shown in Appendix C. 672 teep-error = [ 673 type: TEEP-TYPE-teep-error, 674 options: { 675 ? token => bstr .size (8..64), 676 ? err-msg => text .size (1..128), 677 ? supported-cipher-suites => [ + suite ], 678 ? supported-freshness-mechanisms => [ + freshness-mechanism ], 679 ? versions => [ + version ], 680 ? suit-reports => [ + suit-report ], 681 * $$teep-error-extensions, 682 * $$teep-option-extensions 683 }, 684 err-code: uint (0..23) 685 ] 687 The Error message has the following fields: 689 type 690 The value of (6) corresponds to an Error message sent from the 691 TEEP Agent to the TAM. 693 token 694 The value in the token parameter is used to match responses to 695 requests. It MUST match the value of the token parameter in the 696 Update message the Success is in response to, if one was present. 697 If none was present, the token MUST be absent in the Error 698 message. 700 err-msg 701 The err-msg parameter is human-readable diagnostic text that MUST 702 be encoded using UTF-8 [RFC3629] using Net-Unicode form [RFC5198] 703 with max 128 bytes. 705 supported-cipher-suites 706 The supported-cipher-suites parameter lists the ciphersuite(s) 707 supported by the TEEP Agent. Details about the ciphersuite 708 encoding can be found in Section 7. This otherwise optional 709 parameter MUST be returned if err-code is 710 ERR_UNSUPPORTED_CIPHER_SUITES. 712 supported-freshness-mechanisms 713 The supported-freshness-mechanisms parameter lists the freshness 714 mechanism(s) supported by the TEEP Agent. Details about the 715 encoding can be found in Section 8. This otherwise optional 716 parameter MUST be returned if err-code is 717 ERR_UNSUPPORTED_FRESHNESS_MECHANISMS. 719 versions 720 The versions parameter enumerates the TEEP protocol version(s) 721 supported by the TEEP Agent. This otherwise optional parameter 722 MUST be returned if err-code is ERR_UNSUPPORTED_MSG_VERSION. 724 suit-reports 725 If present, the suit-reports parameter contains a set of SUIT 726 Reports as defined in Section 4 of [I-D.moran-suit-report]. If 727 the suit-report-nonce field is present in the SUIT Report, is 728 value MUST match the value of the token parameter in the Update 729 message the Error message is in response to. 731 err-code 732 The err-code parameter contains one of the error codes listed 733 below). Only selected values are applicable to each message. 735 This specification defines the following initial error messages: 737 ERR_PERMANENT_ERROR (1) 738 The TEEP request contained incorrect fields or fields that are 739 inconsistent with other fields. For diagnosis purposes it is 740 RECOMMMENDED to identify the failure reason in the error message. 741 A TAM receiving this error might refuse to communicate further 742 with the TEEP Agent for some period of time until it has reason to 743 believe it is worth trying again, but it should take care not to 744 give up on communication when there is no attestation evidence 745 indicating that the error is genuine. In contrast, 746 ERR_TEMPORARY_ERROR is an indication that a more agressive retry 747 is warranted. 749 ERR_UNSUPPORTED_EXTENSION (2) 750 The TEEP Agent does not support an extension included in the 751 request message. For diagnosis purposes it is RECOMMMENDED to 752 identify the unsupported extension in the error message. A TAM 753 receiving this error might retry the request without using 754 extensions. 756 ERR_UNSUPPORTED_FRESHNESS_MECHANISMS (3) 757 The TEEP Agent does not support any freshness algorithm mechanisms 758 in the request message. A TAM receiving this error might retry 759 the request using a different set of supported freshness 760 mechanisms in the request message. 762 ERR_UNSUPPORTED_MSG_VERSION (4) 763 The TEEP Agent does not support the TEEP protocol version 764 indicated in the request message. A TAM receiving this error 765 might retry the request using a different TEEP protocol version. 767 ERR_UNSUPPORTED_CIPHER_SUITES (5) 768 The TEEP Agent does not support any ciphersuites indicated in the 769 request message. A TAM receiving this error might retry the 770 request using a different set of supported ciphersuites in the 771 request message. 773 ERR_BAD_CERTIFICATE (6) 774 Processing of a certificate failed. For diagnosis purposes it is 775 RECOMMMENDED to include information about the failing certificate 776 in the error message. For example, the certificate was of an 777 unsupported type, or the certificate was revoked by its signer. A 778 TAM receiving this error might attempt to use an alternate 779 certificate. 781 ERR_CERTIFICATE_EXPIRED (9) 782 A certificate has expired or is not currently valid. A TAM 783 receiving this error might attempt to renew its certificate before 784 using it again. 786 ERR_TEMPORARY_ERROR (10) 787 A miscellaneous temporary error, such as a memory allocation 788 failure, occurred while processing the request message. A TAM 789 receiving this error might retry the same request at a later point 790 in time. 792 ERR_MANIFEST_PROCESSING_FAILED (17) 793 The TEEP Agent encountered one or more manifest processing 794 failures. If the suit-reports parameter is present, it contains 795 the failure details. A TAM receiving this error might still 796 attempt to install or update other components that do not depend 797 on the failed manifest. 799 New error codes should be added sparingly, not for every 800 implementation error. That is the intent of the err-msg field, which 801 can be used to provide details meaningful to humans. New error codes 802 should only be added if the TAM is expected to do something 803 behaviorally different upon receipt of the error message, rather than 804 just logging the event. Hence, each error code is responsible for 805 saying what the behavioral difference is expected to be. 807 5. Mapping of TEEP Message Parameters to CBOR Labels 809 In COSE, arrays and maps use strings, negative integers, and unsigned 810 integers as their keys. Integers are used for compactness of 811 encoding. Since the word "key" is mainly used in its other meaning, 812 as a cryptographic key, this specification uses the term "label" for 813 this usage as a map key. 815 This specification uses the following mapping: 817 +================================+=======+ 818 | Name | Label | 819 +================================+=======+ 820 | supported-cipher-suites | 1 | 821 +--------------------------------+-------+ 822 | challenge | 2 | 823 +--------------------------------+-------+ 824 | version | 3 | 825 +--------------------------------+-------+ 826 | selected-cipher-suite | 5 | 827 +--------------------------------+-------+ 828 | selected-version | 6 | 829 +--------------------------------+-------+ 830 | evidence | 7 | 831 +--------------------------------+-------+ 832 | tc-list | 8 | 833 +--------------------------------+-------+ 834 | ext-list | 9 | 835 +--------------------------------+-------+ 836 | manifest-list | 10 | 837 +--------------------------------+-------+ 838 | msg | 11 | 839 +--------------------------------+-------+ 840 | err-msg | 12 | 841 +--------------------------------+-------+ 842 | evidence-format | 13 | 843 +--------------------------------+-------+ 844 | requested-tc-list | 14 | 845 +--------------------------------+-------+ 846 | unneeded-tc-list | 15 | 847 +--------------------------------+-------+ 848 | component-id | 16 | 849 +--------------------------------+-------+ 850 | tc-manifest-sequence-number | 17 | 851 +--------------------------------+-------+ 852 | have-binary | 18 | 853 +--------------------------------+-------+ 854 | suit-reports | 19 | 855 +--------------------------------+-------+ 856 | token | 20 | 857 +--------------------------------+-------+ 858 | supported-freshness-mechanisms | 21 | 859 +--------------------------------+-------+ 861 Table 2 863 6. Behavior Specification 865 Behavior is specified in terms of the conceptual APIs defined in 866 section 6.2.1 of [I-D.ietf-teep-architecture]. 868 6.1. TAM Behavior 870 When the ProcessConnect API is invoked, the TAM sends a QueryRequest 871 message. 873 When the ProcessTeepMessage API is invoked, the TAM first does 874 validation as specified in Section 4.1.2, and drops the message if it 875 is not valid. Otherwise, it proceeds as follows. 877 If the message includes a token, it can be used to match the response 878 to a request previously sent by the TAM. The TAM MUST expire the 879 token value after receiving the first response from the device that 880 has a valid signature and ignore any subsequent messages that have 881 the same token value. The token value MUST NOT be used for other 882 purposes, such as a TAM to identify the devices and/or a device to 883 identify TAMs or Trusted Components. 885 If a QueryResponse message is received that contains evidence, the 886 evidence is passed to an attestation Verifier (see 887 [I-D.ietf-rats-architecture]) to determine whether the Agent is in a 888 trustworthy state. Based on the results of attestation, and the 889 lists of installed, requested, and unneeded Trusted Components 890 reported in the QueryResponse, the TAM determines, in any 891 implementation specific manner, which Trusted Components need to be 892 installed, updated, or deleted, if any. If any Trusted Components 893 need to be installed, updated, or deleted, the TAM sends an Update 894 message containing SUIT Manifests with command sequences to do the 895 relevant installs, updates, or deletes. It is important to note that 896 the TEEP Agent's Update Procedure requires resolving and installing 897 any dependencies indicated in the manifest, which may take some time, 898 and the resulting Success or Error message is generated only after 899 completing the Update Procedure. Hence, depending on the freshness 900 mechanism in use, the TAM may need to store data (e.g., a nonce) for 901 some time. 903 If a Success or Error message is received containing one or more SUIT 904 Reports, the TAM also validates that the nonce in any SUIT Report 905 matches the token sent in the Update message, and drops the message 906 if it does not match. Otherwise, the TAM handles the update in any 907 implementation specific way, such as updating any locally cached 908 information about the state of the TEEP Agent, or logging the 909 results. 911 If any other Error message is received, the TAM can handle it in any 912 implementation specific way, but Section 4.6 provides recommendations 913 for such handling. 915 6.2. TEEP Agent Behavior 917 When the RequestTA API is invoked, the TEEP Agent first checks 918 whether the requested TA is already installed. If it is already 919 installed, the TEEP Agent passes no data back to the caller. 920 Otherwise, if the TEEP Agent chooses to initiate the process of 921 requesting the indicated TA, it determines (in any implementation 922 specific way) the TAM URI based on any TAM URI provided by the 923 RequestTA caller and any local configuration, and passes back the TAM 924 URI to connect to. 926 When the RequestPolicyCheck API is invoked, the TEEP Agent decides 927 whether to initiate communication with any trusted TAMs (e.g., it 928 might choose to do so for a given TAM unless it detects that it has 929 already communicated with that TAM recently). If so, it passes back 930 a TAM URI to connect to. If the TEEP Agent has multiple TAMs it 931 needs to connect with, it just passes back one, with the expectation 932 that RequestPolicyCheck API will be invoked to retrieve each one 933 successively until there are no more and it can pass back no data at 934 that time. Thus, once a TAM URI is returned, the TEEP Agent can 935 remember that it has already initiated communication with that TAM. 937 When the ProcessError API is invoked, the TEEP Agent can handle it in 938 any implementation specific way, such as logging the error or using 939 the information in future choices of TAM URI. 941 When the ProcessTeepMessage API is invoked, the Agent first does 942 validation as specified in Section 4.1.2, and drops the message if it 943 is not valid. Otherwise, processing continues as follows based on 944 the type of message. 946 When a QueryRequest message is received, the Agent responds with a 947 QueryResponse message if all fields were understood, or an Error 948 message if any error was encountered. 950 When an Update message is received, the Agent attempts to update the 951 Trusted Components specified in the SUIT manifests by following the 952 Update Procedure specified in [I-D.ietf-suit-manifest], and responds 953 with a Success message if all SUIT manifests were successfully 954 installed, or an Error message if any error was encountered. It is 955 important to note that the Update Procedure requires resolving and 956 installing any dependencies indicated in the manifest, which may take 957 some time, and the Success or Error message is generated only after 958 completing the Update Procedure. 960 7. Ciphersuites 962 A ciphersuite consists of an AEAD algorithm, a MAC algorithm, and a 963 signature algorithm. Each ciphersuite is identified with an integer 964 value, which corresponds to an IANA registered ciphersuite (see 965 Section 10.2. This document specifies two ciphersuites. 967 +=======+================================================+ 968 | Value | Ciphersuite | 969 +=======+================================================+ 970 | 1 | AES-CCM-16-64-128, HMAC 256/256, X25519, EdDSA | 971 +-------+------------------------------------------------+ 972 | 2 | AES-CCM-16-64-128, HMAC 256/256, P-256, ES256 | 973 +-------+------------------------------------------------+ 975 Table 3 977 A TAM MUST support both ciphersuites. A TEEP Agent MUST support at 978 least one of the two but can choose which one. For example, a TEEP 979 Agent might choose ciphersuite 2 if it has hardware support for it. 981 Any ciphersuites without confidentiality protection can only be added 982 if the associated specification includes a discussion of security 983 considerations and applicability, since manifests may carry sensitive 984 information. For example, Section 6 of [I-D.ietf-teep-architecture] 985 permits implementations that terminate transport security inside the 986 TEE and if the transport security provides confidentiality then 987 additional encryption might not be needed in the manifest for some 988 use cases. For most use cases, however, manifest confidentiality 989 will be needed to protect sensitive fields from the TAM as discussed 990 in Section 9.8 of [I-D.ietf-teep-architecture]. 992 8. Freshness Mechanisms 994 A freshness mechanism determines how a TAM can tell whether evidence 995 provided in a Query Response is fresh. There are multiple ways this 996 can be done as discussed in Section 10 of 997 [I-D.ietf-rats-architecture]. 999 Each freshness mechanism is identified with an integer value, which 1000 corresponds to an IANA registered freshness mechanism (see 1001 Section 10.3. This document defines the following freshness 1002 mechanisms: 1004 +=======+=====================+ 1005 | Value | Freshness mechanism | 1006 +=======+=====================+ 1007 | 1 | Nonce | 1008 +-------+---------------------+ 1009 | 2 | Timestamp | 1010 +-------+---------------------+ 1011 | 3 | Epoch ID | 1012 +-------+---------------------+ 1014 Table 4 1016 In the Nonce mechanism, the evidence MUST include a nonce provided in 1017 the QueryRequest challenge. In other mechanisms, a timestamp or 1018 epoch ID determined via mechanisms outside the TEEP protocol is used, 1019 and the challenge is only needed in the QueryRequest message if a 1020 challenge is needed in generating evidence for reasons other than 1021 freshness. 1023 If a TAM supports multiple freshness mechanisms that require 1024 different challenge formats, the QueryRequest message can currently 1025 only send one such challenge. This situation is expected to be rare, 1026 but should it occur, the TAM can choose to prioritize one of them and 1027 exclude the other from the supported-freshness-mechanisms in the 1028 QueryRequest, and resend the QueryRequest with the other mechanism if 1029 an ERR_UNSUPPORTED_FRESHNESS_MECHANISMS Error is received that 1030 indicates the TEEP Agent supports the other mechanism. 1032 9. Security Considerations 1034 This section summarizes the security considerations discussed in this 1035 specification: 1037 Cryptographic Algorithms 1038 TEEP protocol messages exchanged between the TAM and the TEEP 1039 Agent are protected using COSE. This specification relies on the 1040 cryptographic algorithms provided by COSE. Public key based 1041 authentication is used by the TEEP Agent to authenticate the TAM 1042 and vice versa. 1044 Attestation 1045 A TAM can rely on the attestation evidence provided by the TEEP 1046 Agent. To sign the attestation evidence, it is necessary for the 1047 device to possess a public key (usually in the form of a 1048 certificate [RFC5280]) along with the corresponding private key. 1049 Depending on the properties of the attestation mechanism, it is 1050 possible to uniquely identify a device based on information in the 1051 attestation evidence or in the certificate used to sign the 1052 attestation evidence. This uniqueness may raise privacy concerns. 1053 To lower the privacy implications the TEEP Agent MUST present its 1054 attestation evidence only to an authenticated and authorized TAM 1055 and when using EATS, it SHOULD use encryption as discussed in 1056 [I-D.ietf-rats-eat], since confidentiality is not provided by the 1057 TEEP protocol itself and the transport protocol under the TEEP 1058 protocol might be implemented outside of any TEE. If any 1059 mechanism other than EATs is used, it is up to that mechanism to 1060 specify how privacy is provided. 1062 Trusted Component Binaries 1063 Each Trusted Component binary is signed by a Trusted Component 1064 Signer. It is the responsibility of the TAM to relay only 1065 verified Trusted Components from authorized Trusted Component 1066 Signers. Delivery of a Trusted Component to the TEEP Agent is 1067 then the responsibility of the TAM, using the security mechanisms 1068 provided by the TEEP protocol. To protect the Trusted Component 1069 binary, the SUIT manifest format is used and it offers a variety 1070 of security features, including digitial signatures and symmetric 1071 encryption. 1073 Personalization Data 1074 A Trusted Component Signer or TAM can supply personalization data 1075 along with a Trusted Component. This data is also protected by a 1076 SUIT manifest. Personalization data signed and encrypted by a 1077 Trusted Component Signer other than the TAM is opaque to the TAM. 1079 TEEP Broker 1080 As discussed in section 6 of [I-D.ietf-teep-architecture], the 1081 TEEP protocol typically relies on a TEEP Broker to relay messages 1082 between the TAM and the TEEP Agent. When the TEEP Broker is 1083 compromised it can drop messages, delay the delivery of messages, 1084 and replay messages but it cannot modify those messages. (A 1085 replay would be, however, detected by the TEEP Agent.) A 1086 compromised TEEP Broker could reorder messages in an attempt to 1087 install an old version of a Trusted Component. Information in the 1088 manifest ensures that TEEP Agents are protected against such 1089 downgrade attacks based on features offered by the manifest 1090 itself. 1092 Trusted Component Signer Compromise 1093 A TAM is responsible for vetting a Trusted Component and before 1094 distributing them to TEEP Agents. 1096 It is RECOMMENDED to provide a way to update the trust anchor 1097 store used by the TEE, for example using a firmware update 1098 mechanism. Thus, if a Trusted Component Signer is later 1099 compromised, the TAM can update the trust anchor store used by the 1100 TEE, for example using a firmware update mechanism. 1102 CA Compromise 1103 The CA issuing certificates to a TEE or a Trusted Component Signer 1104 might get compromised. It is RECOMMENDED to provide a way to 1105 update the trust anchor store used by the TEE, for example using a 1106 firmware update mechanism. If the CA issuing certificates to 1107 devices gets compromised then these devices might be rejected by a 1108 TAM, if revocation is available to the TAM. 1110 TAM Certificate Expiry 1111 The integrity and the accuracy of the clock within the TEE 1112 determines the ability to determine an expired TAM certificate, if 1113 certificates are used. 1115 Compromised Time Source 1116 As discussed above, certificate validity checks rely on comparing 1117 validity dates to the current time, which relies on having a 1118 trusted source of time, such as [RFC8915]. A compromised time 1119 source could thus be used to subvert such validity checks. 1121 10. IANA Considerations 1123 10.1. Media Type Registration 1125 IANA is requested to assign a media type for application/teep+cbor. 1127 Type name: application 1129 Subtype name: teep+cbor 1131 Required parameters: none 1133 Optional parameters: none 1135 Encoding considerations: Same as encoding considerations of 1136 application/cbor. 1138 Security considerations: See Security Considerations Section of this 1139 document. 1141 Interoperability considerations: Same as interoperability 1142 considerations of application/cbor as specified in [RFC7049]. 1144 Published specification: This document. 1146 Applications that use this media type: TEEP protocol implementations 1148 Fragment identifier considerations: N/A 1150 Additional information: Deprecated alias names for this type: N/A 1152 Magic number(s): N/A 1154 File extension(s): N/A 1156 Macintosh file type code(s): N/A 1158 Person to contact for further information: teep@ietf.org 1160 Intended usage: COMMON 1162 Restrictions on usage: none 1164 Author: See the "Authors' Addresses" section of this document 1166 Change controller: IETF 1168 10.2. Ciphersuite Registry 1170 IANA is also requested to create a new registry for ciphersuites. 1172 Name of registry: TEEP Ciphersuites 1174 Policy: Specification Required 1176 Additional requirements: The specification must document relevant 1177 security considerations. 1179 Initial values: 1181 +=======+=========================+===============+ 1182 | Value | Ciphersuite | Specification | 1183 +=======+=========================+===============+ 1184 | 1 | AES-CCM-16-64-128, HMAC | RFC TBD | 1185 | | 256/256, X25519, EdDSA | Section 7 | 1186 +-------+-------------------------+---------------+ 1187 | 2 | AES-CCM-16-64-128, HMAC | RFC TBD | 1188 | | 256/256, P-256, ES256 | Section 7 | 1189 +-------+-------------------------+---------------+ 1191 Table 5 1193 [RFC Editor: please replace TBD above with the number assigned to 1194 this document] 1196 10.3. Freshness Mechanism Registry 1198 IANA is also requested to create a new registry for freshness 1199 mechanisms. 1201 Name of registry: TEEP Freshness Mechanisms 1203 Policy: Specification Required 1205 Additional requirements: The specification must document relevant 1206 security considerations. 1208 Initial values: 1210 +=======+=====================+===================+ 1211 | Value | Freshness mechanism | Specification | 1212 +=======+=====================+===================+ 1213 | 1 | Nonce | RFC TBD Section 8 | 1214 +-------+---------------------+-------------------+ 1215 | 2 | Timestamp | RFC TBD Section 8 | 1216 +-------+---------------------+-------------------+ 1217 | 3 | Epoch ID | RFC TBD Section 8 | 1218 +-------+---------------------+-------------------+ 1220 Table 6 1222 [RFC Editor: please replace TBD above with the number assigned to 1223 this document] 1225 11. References 1227 11.1. Normative References 1229 [I-D.ietf-rats-architecture] 1230 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 1231 W. Pan, "Remote Attestation Procedures Architecture", Work 1232 in Progress, Internet-Draft, draft-ietf-rats-architecture- 1233 12, 23 April 2021, . 1236 [I-D.ietf-rats-eat] 1237 Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity 1238 Attestation Token (EAT)", Work in Progress, Internet- 1239 Draft, draft-ietf-rats-eat-11, 24 October 2021, 1240 . 1243 [I-D.ietf-suit-manifest] 1244 Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, 1245 "A Concise Binary Object Representation (CBOR)-based 1246 Serialization Format for the Software Updates for Internet 1247 of Things (SUIT) Manifest", Work in Progress, Internet- 1248 Draft, draft-ietf-suit-manifest-14, 12 July 2021, 1249 . 1252 [I-D.moran-suit-report] 1253 Moran, B., "Secure Reporting of Update Status", Work in 1254 Progress, Internet-Draft, draft-moran-suit-report-01, 22 1255 February 2021, . 1258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1259 Requirement Levels", BCP 14, RFC 2119, 1260 DOI 10.17487/RFC2119, March 1997, 1261 . 1263 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1264 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1265 2003, . 1267 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 1268 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 1269 . 1271 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1272 Housley, R., and W. Polk, "Internet X.509 Public Key 1273 Infrastructure Certificate and Certificate Revocation List 1274 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1275 . 1277 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1278 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1279 October 2013, . 1281 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1282 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1283 . 1285 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1286 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1287 May 2017, . 1289 11.2. Informative References 1291 [I-D.birkholz-rats-suit-claims] 1292 Birkholz, H. and B. Moran, "Trustworthiness Vectors for 1293 the Software Updates of Internet of Things (SUIT) Workflow 1294 Model", Work in Progress, Internet-Draft, draft-birkholz- 1295 rats-suit-claims-02, 12 July 2021, 1296 . 1299 [I-D.ietf-teep-architecture] 1300 Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, 1301 "Trusted Execution Environment Provisioning (TEEP) 1302 Architecture", Work in Progress, Internet-Draft, draft- 1303 ietf-teep-architecture-15, 12 July 2021, 1304 . 1307 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1308 Writing an IANA Considerations Section in RFCs", BCP 26, 1309 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1310 . 1312 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1313 Definition Language (CDDL): A Notational Convention to 1314 Express Concise Binary Object Representation (CBOR) and 1315 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1316 June 2019, . 1318 [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. 1319 Sundblad, "Network Time Security for the Network Time 1320 Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, 1321 . 1323 A. Contributors 1325 We would like to thank Brian Witten (Symantec), Tyler Kim (Solacia), 1326 Nick Cook (Arm), and Minho Yoo (IoTrust) for their contributions to 1327 the Open Trust Protocol (OTrP), which influenced the design of this 1328 specification. 1330 B. Acknowledgements 1332 We would like to thank Eve Schooler for the suggestion of the 1333 protocol name. 1335 We would like to thank Kohei Isobe (TRASIO/SECOM), Kuniyasu Suzaki 1336 (TRASIO/AIST), Tsukasa Oi (TRASIO), and Yuichi Takita (SECOM) for 1337 their valuable implementation feedback. 1339 We would also like to thank Carsten Bormann and Henk Birkholz for 1340 their help with the CDDL. 1342 C. Complete CDDL 1344 Valid TEEP messages MUST adhere to the following CDDL data 1345 definitions, except that "SUIT_Envelope" and 1346 "SUIT_Component_Identifier" are specified in 1347 [I-D.ietf-suit-manifest]. 1349 teep-message = $teep-message-type .within teep-message-framework 1351 SUIT_Envelope = any 1353 teep-message-framework = [ 1354 type: uint (0..23) / $teep-type-extension, 1355 options: { * teep-option }, 1356 * uint; further integers, e.g., for data-item-requested 1357 ] 1359 teep-option = (uint => any) 1361 ; messages defined below: 1362 $teep-message-type /= query-request 1363 $teep-message-type /= query-response 1364 $teep-message-type /= update 1365 $teep-message-type /= teep-success 1366 $teep-message-type /= teep-error 1368 ; message type numbers, uint (0..23) 1369 TEEP-TYPE-query-request = 1 1370 TEEP-TYPE-query-response = 2 1371 TEEP-TYPE-update = 3 1372 TEEP-TYPE-teep-success = 5 1373 TEEP-TYPE-teep-error = 6 1375 version = .within uint .size 4 1376 ext-info = .within uint .size 4 1377 ; data items as bitmaps 1378 data-item-requested = $data-item-requested .within uint .size 8 1379 attestation = 1 1380 $data-item-requested /= attestation 1381 trusted-components = 2 1382 $data-item-requested /= trusted-components 1383 extensions = 4 1384 $data-item-requested /= extensions 1386 query-request = [ 1387 type: TEEP-TYPE-query-request, 1388 options: { 1389 ? token => bstr .size (8..64), 1390 ? supported-cipher-suites => [ + suite ], 1391 ? supported-freshness-mechanisms => [ + freshness-mechanism ], 1392 ? challenge => bstr .size (8..512), 1393 ? versions => [ + version ], 1394 * $$query-request-extensions 1395 * $$teep-option-extensions 1396 }, 1397 data-item-requested: data-item-requested 1398 ] 1400 ; ciphersuites 1401 suite = $TEEP-suite .within uint .size 4 1403 TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA = 1 1404 TEEP-AES-CCM-16-64-128-HMAC256--256-P-256-ES256 = 2 1406 $TEEP-suite /= TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA 1407 $TEEP-suite /= TEEP-AES-CCM-16-64-128-HMAC256--256-P-256-ES256 1409 ; freshness-mechanisms 1411 freshness-mechanism = $TEEP-freshness-mechanism .within uint .size 4 1413 FRESHNESS_NONCE = 0 1414 FRESHNESS_TIMESTAMP = 1 1415 FRESHNESS_EPOCH_ID = 2 1417 $TEEP-freshness-mechanism /= FRESHNESS_NONCE 1418 $TEEP-freshness-mechanism /= FRESHNESS_TIMESTAMP 1419 $TEEP-freshness-mechanism /= FRESHNESS_EPOCH_ID 1421 query-response = [ 1422 type: TEEP-TYPE-query-response, 1423 options: { 1424 ? token => bstr .size (8..64), 1425 ? selected-cipher-suite => suite, 1426 ? selected-version => version, 1427 ? evidence-format => text, 1428 ? evidence => bstr, 1429 ? tc-list => [ + tc-info ], 1430 ? requested-tc-list => [ + requested-tc-info ], 1431 ? unneeded-tc-list => [ + SUIT_Component_Identifier ], 1432 ? ext-list => [ + ext-info ], 1433 * $$query-response-extensions, 1434 * $$teep-option-extensions 1435 } 1436 ] 1438 tc-info = { 1439 component-id => SUIT_Component_Identifier, 1440 ? tc-manifest-sequence-number => .within uint .size 8 1441 } 1443 requested-tc-info = { 1444 component-id => SUIT_Component_Identifier, 1445 ? tc-manifest-sequence-number => .within uint .size 8 1446 ? have-binary => bool 1447 } 1449 update = [ 1450 type: TEEP-TYPE-update, 1451 options: { 1452 ? token => bstr .size (8..64), 1453 ? manifest-list => [ + bstr .cbor SUIT_Envelope ], 1454 * $$update-extensions, 1455 * $$teep-option-extensions 1456 } 1457 ] 1459 teep-success = [ 1460 type: TEEP-TYPE-teep-success, 1461 options: { 1462 ? token => bstr .size (8..64), 1463 ? msg => text .size (1..128), 1464 ? suit-reports => [ + suit-report ], 1465 * $$teep-success-extensions, 1466 * $$teep-option-extensions 1467 } 1468 ] 1470 teep-error = [ 1471 type: TEEP-TYPE-teep-error, 1472 options: { 1473 ? token => bstr .size (8..64), 1474 ? err-msg => text .size (1..128), 1475 ? supported-cipher-suites => [ + suite ], 1476 ? supported-freshness-mechanisms => [ + freshness-mechanism ], 1477 ? versions => [ + version ], 1478 ? suit-reports => [ + suit-report ], 1479 * $$teep-error-extensions, 1480 * $$teep-option-extensions 1481 }, 1482 err-code: uint (0..23) 1483 ] 1485 ; The err-code parameter, uint (0..23) 1486 ERR_PERMANENT_ERROR = 1 1487 ERR_UNSUPPORTED_EXTENSION = 2 1488 ERR_UNSUPPORTED_FRESHNESS_MECHANISMS = 3 1489 ERR_UNSUPPORTED_MSG_VERSION = 4 1490 ERR_UNSUPPORTED_CIPHER_SUITES = 5 1491 ERR_BAD_CERTIFICATE = 6 1492 ERR_CERTIFICATE_EXPIRED = 9 1493 ERR_TEMPORARY_ERROR = 10 1494 ERR_MANIFEST_PROCESSING_FAILED = 17 1496 ; labels of mapkey for teep message parameters, uint (0..23) 1497 supported-cipher-suites = 1 1498 challenge = 2 1499 versions = 3 1500 selected-cipher-suite = 5 1501 selected-version = 6 1502 evidence = 7 1503 tc-list = 8 1504 ext-list = 9 1505 manifest-list = 10 1506 msg = 11 1507 err-msg = 12 1508 evidence-format = 13 1509 requested-tc-list = 14 1510 unneeded-tc-list = 15 1511 component-id = 16 1512 tc-manifest-sequence-number = 17 1513 have-binary = 18 1514 suit-reports = 19 1515 token = 20 1516 supported-freshness-mechanisms = 21 1518 D. Examples of Diagnostic Notation and Binary Representation 1520 This section includes some examples with the following assumptions: 1522 * TEEP Device will have two TCs with the following SUIT Component 1523 Identifiers: 1525 - [ 0x000102030405060708090a0b0c0d0e0f ] 1527 - [ 0x100102030405060708090a0b0c0d0e0f ] 1529 * SUIT manifest-list is set empty only for example purposes (see 1530 Appendix E for actual manifest examples) 1532 D.1. QueryRequest Message 1534 D.1.1. CBOR Diagnostic Notation 1536 / query-request = / 1537 [ 1538 1, / type : TEEP-TYPE-query-request = 1 (uint (0..23)) / 1539 / options : / 1540 { 1541 20 : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf, 1542 / token = 20 (mapkey) : 1543 h'a0a1a2a3a4a5a6a7a8a9aaabacadaeaf' (bstr .size (8..64)), 1544 generated by TAM / 1545 1 : [ 1 ], / supported-cipher-suites = 1 (mapkey) : 1546 TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA = 1547 [ 1 ] (array of .within uint .size 4) / 1548 3 : [ 0 ] / version = 3 (mapkey) : 1549 [ 0 ] (array of .within uint .size 4) / 1550 }, 1551 3 / data-item-requested : 1552 attestation | trusted-components = 3 (.within uint .size 8) / 1553 ] 1555 D.1.2. CBOR Binary Representation 1556 83 # array(3) 1557 01 # unsigned(1) uint (0..23) 1558 A4 # map(4) 1559 14 # unsigned(20) uint (0..23) 1560 4F # bytes(16) (8..64) 1561 A0A1A2A3A4A5A6A7A8A9AAABACADAEAF 1562 01 # unsigned(1) uint (0..23) 1563 81 # array(1) 1564 01 # unsigned(1) within uint .size 4 1565 03 # unsigned(3) uint (0..23) 1566 81 # array(1) 1567 00 # unsigned(0) within uint .size 4 1568 04 # unsigned(4) uint (0..23) 1569 43 # bytes(3) 1570 010203 # "\x01\x02\x03" 1571 03 # unsigned(3) .within uint .size 8 1573 D.2. Entity Attestation Token 1575 This is shown below in CBOR diagnostic form. Only the payload signed 1576 by COSE is shown. 1578 D.2.1. CBOR Diagnostic Notation 1580 / eat-claim-set = / 1581 { 1582 / issuer / 1: "joe", 1583 / timestamp (iat) / 6: 1(1526542894) 1584 / nonce / 10: h'948f8860d13a463e8e', 1585 / secure-boot / 15: true, 1586 / debug-status / 16: 3, / disabled-permanently / 1587 / security-level / 14: 3, / secure-restricted / 1588 / device-identifier / : h'e99600dd921649798b013e9752dcf0c5', 1589 / vendor-identifier / : h'2b03879b33434a7ca682b8af84c19fd4', 1590 / class-identifier / : h'9714a5796bd245a3a4ab4f977cb8487f', 1591 / chip-version / 26: [ "MyTEE", 1 ], 1592 / component-identifier / : h'60822887d35e43d5b603d18bcaa3f08d', 1593 / version / : "v0.1" 1594 } 1596 D.3. QueryResponse Message 1598 D.3.1. CBOR Diagnostic Notation 1599 / query-response = / 1600 [ 1601 2, / type : TEEP-TYPE-query-response = 2 (uint (0..23)) / 1602 / options : / 1603 { 1604 20 : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf, 1605 / token = 20 (mapkey) : 1606 h'a0a1a2a3a4a5a6a7a8a9aaabacadaeaf' (bstr .size (8..64)), 1607 given from TAM's QueryRequest message / 1608 5 : 1, / selected-cipher-suite = 5 (mapkey) : 1609 TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA = 1610 1 (.within uint .size 4) / 1611 6 : 0, / selected-version = 6 (mapkey) : 1612 0 (.within uint .size 4) / 1613 7 : ... / evidence = 7 (mapkey) : 1614 Entity Attestation Token / 1615 8 : [ / tc-list = 8 (mapkey) : (array of tc-info) / 1616 { 1617 16 : [ 0x000102030405060708090a0b0c0d0e0f ] / component-id = 1618 16 (mapkey) : [ h'000102030405060708090a0b0c0d0e0f' ] 1619 (SUIT_Component_Identifier = [* bstr]) / 1620 }, 1621 { 1622 16 : [ 0x100102030405060708090a0b0c0d0e0f ] / component-id = 1623 16 (mapkey) : [ h'100102030405060708090a0b0c0d0e0f' ] 1624 (SUIT_Component_Identifier = [* bstr]) / 1625 } 1626 ] 1627 } 1628 ] 1630 D.3.2. CBOR Binary Representation 1631 82 # array(2) 1632 02 # unsigned(2) uint (0..23) 1633 A5 # map(5) 1634 14 # unsigned(20) uint (0..23) 1635 4F # bytes(16) (8..64) 1636 A0A1A2A3A4A5A6A7A8A9AAABACADAEAF 1637 05 # unsigned(5) uint (0..23) 1638 01 # unsigned(1) .within uint .size 4 1639 06 # unsigned(6) uint (0..23) 1640 00 # unsigned(0) .within uint .size 4 1641 07 # unsigned(7) uint (0..23) 1642 ... # Entity Attestation Token 1643 08 # unsigned(8) uint (0..23) 1644 82 # array(2) 1645 81 # array(1) 1646 4F # bytes(16) 1647 000102030405060708090A0B0C0D0E0F 1648 81 # array(1) 1649 4F # bytes(16) 1650 100102030405060708090A0B0C0D0E0F 1652 D.4. Update Message 1654 D.4.1. CBOR Diagnostic Notation 1656 / update = / 1657 [ 1658 3, / type : TEEP-TYPE-update = 3 (uint (0..23)) / 1659 / options : / 1660 { 1661 20 : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf, 1662 / token = 20 (mapkey) : 1663 h'a0a1a2a3a4a5a6a7a8a9aaabacadaeaf' (bstr .size (8..64)), 1664 generated by TAM / 1665 10 : [ ] / manifest-list = 10 (mapkey) : 1666 [ ] (array of bstr wrapped SUIT_Envelope(any)) / 1667 / empty, example purpose only / 1668 } 1669 ] 1671 D.4.2. CBOR Binary Representation 1672 82 # array(2) 1673 03 # unsigned(3) uint (0..23) 1674 A3 # map(3) 1675 14 # unsigned(20) uint (0..23) 1676 4F # bytes(16) (8..64) 1677 A0A1A2A3A4A5A6A7A8A9AAABACADAEAF 1678 0A # unsigned(10) uint (0..23) 1679 80 # array(0) 1681 D.5. Success Message 1683 D.5.1. CBOR Diagnostic Notation 1685 / teep-success = / 1686 [ 1687 5, / type : TEEP-TYPE-teep-success = 5 (uint (0..23)) / 1688 / options : / 1689 { 1690 20 : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf, 1691 / token = 20 (mapkey) : 1692 h'a0a1a2a3a4a5a6a7a8a9aaabacadaeaf' (bstr .size (8..64)), 1693 given from TAM's Update message / 1694 } 1695 ] 1697 D.5.2. CBOR Binary Representation 1699 82 # array(2) 1700 05 # unsigned(5) uint (0..23) 1701 A1 # map(1) 1702 14 # unsigned(20) uint (0..23) 1703 4F # bytes(16) (8..64) 1704 A0A1A2A3A4A5A6A7A8A9AAABACADAEAF 1706 D.6. Error Message 1708 D.6.1. CBOR Diagnostic Notation 1709 / teep-error = / 1710 [ 1711 6, / type : TEEP-TYPE-teep-error = 6 (uint (0..23)) / 1712 / options : / 1713 { 1714 20 : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf, 1715 / token = 20 (mapkey) : 1716 h'a0a1a2a3a4a5a6a7a8a9aaabacadaeaf' (bstr .size (8..64)), 1717 given from TAM's Update message / 1718 12 : "disk-full" / err-msg = 12 (mapkey) : 1719 "disk-full" (text .size (1..128)) / 1720 }, 1721 17, / err-code : ERR_MANIFEST_PROCESSING_FAILED = 17 (uint (0..23)) / 1722 ] 1724 D.6.2. CBOR binary Representation 1726 83 # array(3) 1727 06 # unsigned(6) uint (0..23) 1728 A2 # map(2) 1729 14 # unsigned(20) uint (0..23) 1730 4F # bytes(16) (8..64) 1731 A0A1A2A3A4A5A6A7A8A9AAABACADAEAF 1732 0C # unsigned(12) uint (0..23) 1733 69 # text(9) (1..128) 1734 6469736B2D66756C6C # "disk-full" 1735 11 # unsigned(17) uint (0..23) 1737 E. Examples of SUIT Manifests 1739 This section shows some examples of SUIT manifests for a case where 1740 the TEE will use a Trusted Application (TA) for OP-TEE on Arm 1741 TrustZone, storing the TA in Replay Protected Memory Block (RPMB) 1742 secure storage in a file named "edd94cd8-9d9c-4cc8-9216- 1743 b3ad5a2d5b8a.ta". 1745 The TA developer places personalization data for the device on an 1746 HTTPS server and puts the URI in the TA manifest. The 1747 personalization data will also be stored in RPMB secure storage in a 1748 file named "config.json". 1750 E.1. Install a Trusted Component 1752 This sample manifest installs a Trusted Component that depends on 1753 personalization data resolved separately. 1755 TA Manifest: 1757 107({ 1758 / authentication-wrapper / 2:<<[ 1759 digest: <<[ 1760 / algorithm-id / -16 / "sha256" /, 1761 / digest-bytes / h'd6c1fc7200483092e2db59d4907f9b15' 1762 h'05cb3af2795cf78f7ae3d88166fdf743' 1763 ]>>, 1764 signature: <<18([ 1765 / protected / <<{ 1766 / alg / 1:-7 / "ES256" /, 1767 }>>, 1768 / unprotected / {}, 1769 / payload / F6 / nil /, 1770 / signature / h'd11a2dd9610fb62a707335f584079225' 1771 h'709f96e8117e7eeed98a2f207d05c8ec' 1772 h'fba1755208f6abea977b8a6efe3bc2ca' 1773 h'3215e1193be201467d052b42db6b7287' 1774 ])>> 1775 ]>>, 1776 / manifest / 3:<<{ 1777 / manifest-version / 1:1, 1778 / manifest-sequence-number / 2:3, 1779 / common / 3:<<{ 1780 / components / 2:[ 1781 ["OP-TEE","RPMB","edd94cd8-9d9c-4cc8-9216- b3ad5a2d5b8a","ta"] 1782 ], 1783 / common-sequence / 4:<<[ 1784 / directive-override-parameters / 20,{ 1785 / vendor-id / 1:h'c0ddd5f15243566087db4f5b0aa26c2f', 1786 / class-id / 2:h'db42f7093d8c55baa8c5265fc5820f4e', 1787 / image-digest / 3:<<[ 1788 / algorithm-id / -16 / "sha256" /, 1789 / digest-bytes / h'00112233445566778899aabbccddeeff' 1790 h'0123456789abcdeffedcba9876543210' 1791 ]>>, 1792 / image-size / 14:76778, 1793 }, 1794 / condition-vendor-identifier / 1,15, 1795 / condition-class-identifier / 2,15 1796 ]>>, 1797 }>>, 1798 / install / 9:<<[ 1799 / directive-set-parameters / 19,{ 1800 / uri / 21: 1801 'https://teep.example/edd94cd8-9d9c-4cc8-9216-b3ad5a2d5b8a.ta', 1802 } , 1803 / directive-fetch / 21,2, 1804 / condition-image-match / 3,15 1806 ]>>, 1807 / validate / 10:<<[ 1808 / condition-image-match / 3,15 1809 ]>>, 1810 / run / 12:<<[ 1811 / directive-run / 23,2 1812 ]>>, 1813 / text / 13:<<{ 1814 [ 1815 h'4f502d544545', 1816 h'44f301', 1817 h'edd94cd89d9c4cc89216b3ad5a2d5b8a', 1818 h'7461' 1819 ]:{ 1820 / model-name / 2: 'OP-TEE on TF-A on TrustZone', 1821 / vendor-domain / 3:'teep.example' 1822 } 1823 }>> 1824 }>> 1825 }) 1827 Personalization Data Manifest: 1829 107({ 1830 2:<<[ 1831 digest: <<[ 1832 / algorithm-id / -16 / "sha256" /, 1833 / digest-bytes / h'a7fd6593eac32eb4be578278e6540c5c' 1834 h'09cfd7d4d234973054833b2b93030609' 1835 ]>> 1836 ]>>, 1837 / manifest / 3:<<{ 1838 / manifest-version / 1:1, 1839 / manifest-sequence-number / 2:3, 1840 / dependencies / 1:[ 1841 { 1842 / dependency-digest / 1:[ 1843 / algorithm-id / -16 / "sha256" /, 1844 / digest-bytes / h'd6c1fc7200483092e2db59d4907f9b15' 1845 h'05cb3af2795cf78f7ae3d88166fdf743' 1846 ] 1847 } 1848 ], 1849 / components / 2:[ 1850 ["OP-TEE","RPMB","config.json"] 1851 ], 1852 / common-sequence / 4:<<[ 1853 / directive-set-component-index / 12,0, 1854 / directive-override-parameters / 20,{ 1855 / vendor-id / 1:h'ec41787224345ae580003de697ff8d43' 1856 / ec417872-2434-5ae5-8000-3de697ff8d43 /, 1857 / class-id / 2:h'eb1701b48be85709aca0adf89f056a64' 1858 / eb1701b4-8be8-5709-aca0-adf89f056a64 /, 1859 / image-digest / 3:<<[ 1860 / algorithm-id / -16 / "sha256" /, 1861 / digest-bytes / h'aaabcccdeeef00012223444566678889' 1862 h'abbbcdddefff01112333455567778999' 1863 ]>> 1864 }, 1865 / condition-vendor-identifier / 1,15, 1866 / condition-class-identifier / 2,15 1867 ]>>, 1868 / dependency-resolution / 7:<<[ 1869 / directive-set-dependency-index / 13,0, 1870 / directive-set-parameters / 19,{ 1871 / uri / 21:'tam.teep.example/' 1872 'edd94cd8-9d9c-4cc8-' 1873 '9216-b3ad5a2d5b8a.suit', 1874 }, 1875 / directive-fetch / 21,2, 1876 / condition-image-match / 3,15 1877 ]>>, 1878 / install / 9:<<[ 1879 / directive-set-component-index / 12,0, 1880 / directive-set-parameters / 19,{ 1881 / uri / 21: 1882 'http://tam.teep.example/config.json', 1883 }, 1884 / directive-set-dependency-index / 13,0, 1885 / directive-process-dependency / 18,0, 1886 / directive-set-component-index / 12,0, 1887 / directive-fetch / 21,2, 1888 / condition-image-match / 3,15 1889 ]>>, 1890 / validate / 10:<<[ 1891 / directive-set-component-index / 12,0, 1892 / condition-image-match / 3,15, 1893 / directive-set-dependency-index / 13,0, 1894 / directive-process-dependency / 18,0 1895 ]>>, 1896 / run / 12:<<[ 1897 / directive-set-dependency-index / 13,0, 1898 / directive-process-dependency / 18,0 1899 ]>>, 1900 / text / 13:<<{ 1901 [h'4f502d544545', h'44f301', 1902 h'636f6e6669672e6a736f6e']:{ 1903 / model-name / 2: 'Personalised OP-TEE on TF-A on TrustZone', 1904 / vendor-domain / 3:'tam.teep.example', 1905 }, 1906 [ 1907 h'4f502d544545', 1908 h'44f301', 1909 h'edd94cd89d9c4cc89216b3ad5a2d5b8a', 1910 h'7461' 1911 ]:{ 1912 / model-name / 2:'OP-TEE on TF-A on TrustZone', 1913 / vendor-domain / 3:'teep.example' 1914 } 1915 }>> 1916 }>> 1917 }) 1919 E.2. Delete a Trusted Component 1921 This sample manifest removes a Trusted Component and its dependency. 1923 107({ 1924 / authentication-wrapper / 2:<<[ 1925 digest: <<[ 1926 / algorithm-id / -16 / "sha256" /, 1927 / digest-bytes / 1928 h'a6c4590ac53043a98e8c4106e1e31b305516d7cf0a655eddfac6d45c810e036a' 1929 ]>>, 1930 signature: <<18([ 1931 / protected / <<{ 1932 / alg / 1:-7 / "ES256" /, 1933 }>>, 1934 / unprotected / { 1935 }, 1936 / payload / F6 / nil /, 1937 / signature / h'd11a2dd9610fb62a707335f58407922570 1938 9f96e8117e7eeed98a2f207d05c8ecfba1755208f6abea977b8a6efe3bc2ca3215e119 1939 3be201467d052b42db6b7287' 1940 ])>> 1941 ] 1942 ]>>, 1943 / manifest / 3:<<{ 1944 / manifest-version / 1:1, 1945 / manifest-sequence-number / 2:0, 1946 / common / 3:<<{ 1947 / components / 2:[ 1948 [h'00'] 1949 ], 1950 / common-sequence / 4:<<[ 1951 / directive-override-parameters / 20,{ 1952 / vendor-id / 1953 1:h'fa6b4a53d5ad5fdfbe9de663e4d41ffe' / fa6b4a53-d5ad-5fdf- 1954 be9d-e663e4d41ffe /, 1955 / class-id / 1956 2:h'1492af1425695e48bf429b2d51f2ab45' / 1957 1492af14-2569-5e48-bf42-9b2d51f2ab45 /, 1958 / image-digest / 3:<<[ 1959 / algorithm-id / -16 / "sha256" /, 1960 / digest-bytes / 1961 h'00112233445566778899aabbccddeeff0123456789abcdeffedcba9876543210' 1962 ]>>, 1963 / image-size / 14:34768, 1964 } , 1965 / condition-vendor-identifier / 1,15 , 1966 / condition-class-identifier / 2,15 1967 ]>>, 1968 }>>, 1969 / validate / 10:<<[ 1970 / condition-image-match / 3,15 1971 ]>>, 1972 / run / 12:<<[ 1973 / directive-run / 23,2 1974 ]>>, 1975 }>>, 1976 }) 1978 Total size of Envelope without COSE authentication object: 161 1980 Envelope: 1982 d86ba2025827815824822f5820a6c4590ac53043a98e8c4106e1e31b3055 1983 16d7cf0a655eddfac6d45c810e036a035871a50101020003585fa2028181 1984 41000458568614a40150fa6b4a53d5ad5fdfbe9de663e4d41ffe02501492 1985 af1425695e48bf429b2d51f2ab45035824822f5820001122334455667788 1986 99aabbccddeeff0123456789abcdeffedcba98765432100e1987d0010f02 1987 0f0a4382030f0c43821702 1989 Total size of Envelope with COSE authentication object: 237 1991 Envelope with COSE authentication object: 1993 d86ba2025873825824822f5820a6c4590ac53043a98e8c4106e1e31b3055 1994 16d7cf0a655eddfac6d45c810e036a584ad28443a10126a0f65840d11a2d 1995 d9610fb62a707335f584079225709f96e8117e7eeed98a2f207d05c8ecfb 1996 a1755208f6abea977b8a6efe3bc2ca3215e1193be201467d052b42db6b72 1997 87035871a50101020003585fa202818141000458568614a40150fa6b4a53 1998 d5ad5fdfbe9de663e4d41ffe02501492af1425695e48bf429b2d51f2ab45 1999 035824822f582000112233445566778899aabbccddeeff0123456789abcd 2000 effedcba98765432100e1987d0010f020f0a4382030f0c43821702 2002 Authors' Addresses 2004 Hannes Tschofenig 2005 Arm Ltd. 2006 6067 Absam 2007 Austria 2009 Email: hannes.tschofenig@arm.com 2011 Mingliang Pei 2012 Broadcom 2013 350 Ellis St 2014 Mountain View, CA 94043 2015 United States of America 2017 Email: mingliang.pei@broadcom.com 2019 David Wheeler 2020 Amazon 2021 United States of America 2023 Email: davewhee@amazon.com 2025 Dave Thaler 2026 Microsoft 2027 United States of America 2029 Email: dthaler@microsoft.com 2031 Akira Tsukamoto 2032 AIST 2033 Japan 2035 Email: akira.tsukamoto@aist.go.jp