idnits 2.17.1 draft-ietf-teep-opentrustprotocol-02.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 (October 23, 2018) is 2005 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CA' is mentioned on line 502, but not defined == Missing Reference: 'Soc' is mentioned on line 504, but not defined == Missing Reference: 'OEM' is mentioned on line 516, but not defined Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEEP M. Pei 3 Internet-Draft Symantec 4 Intended status: Informational A. Atyeo 5 Expires: April 26, 2019 Intercede 6 N. Cook 7 ARM Ltd. 8 M. Yoo 9 IoTrust 10 H. Tschofenig 11 ARM Ltd. 12 October 23, 2018 14 The Open Trust Protocol (OTrP) 15 draft-ietf-teep-opentrustprotocol-02.txt 17 Abstract 19 This document specifies the Open Trust Protocol (OTrP), a protocol 20 that follows the Trust Execution Environment Provisioning (TEEP) 21 architecture and provides a message protocol that provisions and 22 manages Trusted Applications into a device with a Trusted Execution 23 Environment (TEE). 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 26, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 64 4. OTrP Entities and Trust Model . . . . . . . . . . . . . . . . 6 65 4.1. System Components . . . . . . . . . . . . . . . . . . . . 7 66 4.2. Trust Anchors in TEE . . . . . . . . . . . . . . . . . . 7 67 4.3. Trust Anchors in TAM . . . . . . . . . . . . . . . . . . 7 68 4.4. Keys and Certificate Types . . . . . . . . . . . . . . . 7 69 5. Protocol Scope and Entity Relations . . . . . . . . . . . . . 10 70 5.1. A Sample Device Setup Flow . . . . . . . . . . . . . . . 12 71 5.2. Derived Keys in The Protocol . . . . . . . . . . . . . . 12 72 5.3. Security Domain Hierarchy and Ownership . . . . . . . . . 13 73 5.4. SD Owner Identification and TAM Certificate Requirements 13 74 5.5. Service Provider Container . . . . . . . . . . . . . . . 14 75 6. OTrP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 6.1. Role of OTrP Broker . . . . . . . . . . . . . . . . . . . 15 77 6.2. OTrP Broker and Global Platform TEE Client API . . . . . 16 78 6.3. OTrP Broker Implementation Consideration . . . . . . . . 16 79 6.3.1. OTrP Broker Distribution . . . . . . . . . . . . . . 16 80 6.3.2. Number of OTrP Broker . . . . . . . . . . . . . . . . 16 81 6.4. OTrP Broker Interfaces for Client Applications . . . . . 17 82 6.4.1. ProcessOTrPMessage call . . . . . . . . . . . . . . . 17 83 6.4.2. GetTAInformation call . . . . . . . . . . . . . . . . 17 84 6.5. Sample End-to-End Client Application Flow . . . . . . . . 20 85 6.5.1. Case 1: A New Client Application Uses a TA . . . . . 20 86 6.5.2. Case 2: A Previously Installed Client Application 87 Calls a TA . . . . . . . . . . . . . . . . . . . . . 21 88 7. OTrP Messages . . . . . . . . . . . . . . . . . . . . . . . . 22 89 7.1. Message Format . . . . . . . . . . . . . . . . . . . . . 22 90 7.2. Message Naming Convention . . . . . . . . . . . . . . . . 22 91 7.3. Request and Response Message Template . . . . . . . . . . 23 92 7.4. Signed Request and Response Message Structure . . . . . . 23 93 7.4.1. Identifying Signing and Encryption Keys for JWS/JWE 94 Messaging . . . . . . . . . . . . . . . . . . . . . . 25 95 7.5. JSON Signing and Encryption Algorithms . . . . . . . . . 25 96 7.5.1. Supported JSON Signing Algorithms . . . . . . . . . . 27 97 7.5.2. Support JSON Encryption Algorithms . . . . . . . . . 27 98 7.5.3. Supported JSON Key Management Algorithms . . . . . . 27 99 7.6. Common Errors . . . . . . . . . . . . . . . . . . . . . . 28 100 7.7. OTrP Message List . . . . . . . . . . . . . . . . . . . . 28 101 7.8. OTrP Request Message Routing Rules . . . . . . . . . . . 29 102 7.8.1. SP Anonymous Attestation Key (SP AIK) . . . . . . . . 29 103 8. Transport Protocol Support . . . . . . . . . . . . . . . . . 29 104 9. Detailed Messages Specification . . . . . . . . . . . . . . . 30 105 9.1. GetDeviceState . . . . . . . . . . . . . . . . . . . . . 30 106 9.1.1. GetDeviceStateRequest message . . . . . . . . . . . . 30 107 9.1.2. Request processing requirements at a TEE . . . . . . 31 108 9.1.3. Firmware Signed Data . . . . . . . . . . . . . . . . 32 109 9.1.3.1. Supported Firmware Signature Methods . . . . . . 33 110 9.1.4. Post Conditions . . . . . . . . . . . . . . . . . . . 33 111 9.1.5. GetDeviceStateResponse Message . . . . . . . . . . . 33 112 9.1.6. Error Conditions . . . . . . . . . . . . . . . . . . 38 113 9.1.7. TAM Processing Requirements . . . . . . . . . . . . . 39 114 9.2. Security Domain Management . . . . . . . . . . . . . . . 40 115 9.2.1. CreateSD . . . . . . . . . . . . . . . . . . . . . . 40 116 9.2.1.1. CreateSDRequest Message . . . . . . . . . . . . . 40 117 9.2.1.2. Request Processing Requirements at a TEE . . . . 43 118 9.2.1.3. CreateSDResponse Message . . . . . . . . . . . . 44 119 9.2.1.4. Error Conditions . . . . . . . . . . . . . . . . 46 120 9.2.2. UpdateSD . . . . . . . . . . . . . . . . . . . . . . 46 121 9.2.2.1. UpdateSDRequest Message . . . . . . . . . . . . . 46 122 9.2.2.2. Request Processing Requirements at a TEE . . . . 49 123 9.2.2.3. UpdateSDResponse Message . . . . . . . . . . . . 51 124 9.2.2.4. Error Conditions . . . . . . . . . . . . . . . . 52 125 9.2.3. DeleteSD . . . . . . . . . . . . . . . . . . . . . . 53 126 9.2.3.1. DeleteSDRequest Message . . . . . . . . . . . . . 53 127 9.2.3.2. Request Processing Requirements at a TEE . . . . 55 128 9.2.3.3. DeleteSDResponse Message . . . . . . . . . . . . 56 129 9.2.3.4. Error Conditions . . . . . . . . . . . . . . . . 58 130 9.3. Trusted Application Management . . . . . . . . . . . . . 58 131 9.3.1. InstallTA . . . . . . . . . . . . . . . . . . . . . . 59 132 9.3.1.1. InstallTARequest Message . . . . . . . . . . . . 60 133 9.3.1.2. InstallTAResponse Message . . . . . . . . . . . . 62 134 9.3.1.3. Error Conditions . . . . . . . . . . . . . . . . 64 135 9.3.2. UpdateTA . . . . . . . . . . . . . . . . . . . . . . 64 136 9.3.2.1. UpdateTARequest Message . . . . . . . . . . . . . 65 137 9.3.2.2. UpdateTAResponse Message . . . . . . . . . . . . 67 138 9.3.2.3. Error Conditions . . . . . . . . . . . . . . . . 69 139 9.3.3. DeleteTA . . . . . . . . . . . . . . . . . . . . . . 69 140 9.3.3.1. DeleteTARequest Message . . . . . . . . . . . . . 69 141 9.3.3.2. Request Processing Requirements at a TEE . . . . 71 142 9.3.3.3. DeleteTAResponse Message . . . . . . . . . . . . 72 143 9.3.3.4. Error Conditions . . . . . . . . . . . . . . . . 73 144 10. Response Messages a TAM May Expect . . . . . . . . . . . . . 73 145 11. Basic Protocol Profile . . . . . . . . . . . . . . . . . . . 74 146 12. Attestation Implementation Consideration . . . . . . . . . . 75 147 12.1. OTrP Trusted Firmware . . . . . . . . . . . . . . . . . 75 148 12.1.1. Attestation signer . . . . . . . . . . . . . . . . . 75 149 12.1.2. TFW Initial Requirements . . . . . . . . . . . . . . 75 150 12.2. TEE Loading . . . . . . . . . . . . . . . . . . . . . . 76 151 12.3. Attestation Hierarchy . . . . . . . . . . . . . . . . . 76 152 12.3.1. Attestation Hierarchy Establishment: Manufacture . . 77 153 12.3.2. Attestation Hierarchy Establishment: Device Boot . . 77 154 12.3.3. Attestation Hierarchy Establishment: TAM . . . . . . 77 155 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77 156 13.1. Error Code List . . . . . . . . . . . . . . . . . . . . 78 157 13.1.1. TEE Signed Error Code List . . . . . . . . . . . . . 78 158 13.1.2. OTrP Broker Error Code List . . . . . . . . . . . . 79 159 14. Security Consideration . . . . . . . . . . . . . . . . . . . 79 160 14.1. Cryptographic Strength . . . . . . . . . . . . . . . . . 79 161 14.2. Message Security . . . . . . . . . . . . . . . . . . . . 80 162 14.3. TEE Attestation . . . . . . . . . . . . . . . . . . . . 80 163 14.4. TA Protection . . . . . . . . . . . . . . . . . . . . . 80 164 14.5. TA Personalization Data . . . . . . . . . . . . . . . . 81 165 14.6. TA Trust Check at TEE . . . . . . . . . . . . . . . . . 81 166 14.7. One TA Multiple SP Case . . . . . . . . . . . . . . . . 82 167 14.8. OTrP Broker Trust Model . . . . . . . . . . . . . . . . 82 168 14.9. OCSP Stapling Data for TAM Signed Messages . . . . . . . 82 169 14.10. Data Protection at TAM and TEE . . . . . . . . . . . . . 82 170 14.11. Privacy Consideration . . . . . . . . . . . . . . . . . 82 171 14.12. Threat Mitigation . . . . . . . . . . . . . . . . . . . 83 172 14.13. Compromised CA . . . . . . . . . . . . . . . . . . . . . 83 173 14.14. Compromised TAM . . . . . . . . . . . . . . . . . . . . 84 174 14.15. Certificate Renewal . . . . . . . . . . . . . . . . . . 84 175 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 84 176 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 84 177 16.1. Normative References . . . . . . . . . . . . . . . . . . 84 178 16.2. Informative References . . . . . . . . . . . . . . . . . 85 179 Appendix A. Sample Messages . . . . . . . . . . . . . . . . . . 85 180 A.1. Sample Security Domain Management Messages . . . . . . . 85 181 A.1.1. Sample GetDeviceState . . . . . . . . . . . . . . . . 85 182 A.1.1.1. Sample GetDeviceStateRequest . . . . . . . . . . 85 183 A.1.1.2. Sample GetDeviceStateResponse . . . . . . . . . . 86 184 A.1.2. Sample CreateSD . . . . . . . . . . . . . . . . . . . 89 185 A.1.2.1. Sample CreateSDRequest . . . . . . . . . . . . . 89 186 A.1.2.2. Sample CreateSDResponse . . . . . . . . . . . . . 92 187 A.1.3. Sample UpdateSD . . . . . . . . . . . . . . . . . . . 93 188 A.1.3.1. Sample UpdateSDRequest . . . . . . . . . . . . . 94 189 A.1.3.2. Sample UpdateSDResponse . . . . . . . . . . . . . 95 190 A.1.4. Sample DeleteSD . . . . . . . . . . . . . . . . . . . 95 191 A.1.4.1. Sample DeleteSDRequest . . . . . . . . . . . . . 95 192 A.1.4.2. Sample DeleteSDResponse . . . . . . . . . . . . . 97 194 A.2. Sample TA Management Messages . . . . . . . . . . . . . . 99 195 A.2.1. Sample InstallTA . . . . . . . . . . . . . . . . . . 99 196 A.2.1.1. Sample InstallTARequest . . . . . . . . . . . . . 99 197 A.2.1.2. Sample InstallTAResponse . . . . . . . . . . . . 100 198 A.2.2. Sample UpdateTA . . . . . . . . . . . . . . . . . . . 102 199 A.2.2.1. Sample UpdateTARequest . . . . . . . . . . . . . 102 200 A.2.2.2. Sample UpdateTAResponse . . . . . . . . . . . . . 103 201 A.2.3. Sample DeleteTA . . . . . . . . . . . . . . . . . . . 106 202 A.2.3.1. Sample DeleteTARequest . . . . . . . . . . . . . 106 203 A.2.3.2. Sample DeleteTAResponse . . . . . . . . . . . . . 108 204 A.3. Example OTrP Broker Option . . . . . . . . . . . . . . . 110 205 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 110 206 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 110 208 1. Introduction 210 The Trusted Execution Environment (TEE) concept has been designed to 211 separate a regular operating system, also referred as a Rich 212 Execution Environment (REE), from security-sensitive applications. 213 In an TEE ecosystem, different device vendors may use different TEE 214 implementations. Different application providers or device 215 administrators may choose to use different TAM providers. There 216 calls for an interoperable protocol for managing TAs running in 217 different TEEs of various devices is needed. 219 The Trusted Execution Environment Provisioning (TEEP) architecture 220 document [TEEPArch] has set to provide a design guidance for such an 221 interoperable protocol. This document specifies an Open Trust 222 Protocol (OTrP) that follows the architecture guidance. 224 OTrP defines a mutual trust message protocol between a TAM and a TEE 225 and relies on IETF-defined end-to-end security mechanisms, namely 226 JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Key 227 (JWK). Other message encoding methods may be supported. 229 This specification defines message payloads exchanged between devices 230 and a TAM. The messages are designed in anticipation of the use of 231 the most common transport methods such as HTTPS. 233 Each TA binary and configuration data can be from either of two 234 sources: 236 1. A TAM supplies the signed and encrypted TA binary and any 237 required configuration data 239 2. A Client Application supplies the TA binary 240 This specification considers the first case where TA binary and 241 configuration data are encrypted by recipient's public key that TAM 242 has to be involved. The second case will also be addressed 243 separately. 245 2. Requirements Language 247 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 248 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 249 document are to be interpreted as described in [RFC2119]. 251 3. Terminology 253 3.1. Definitions 255 The definitions provided below are defined as used in this document. 256 All the terms defined in the TEEP Architecture document [TEEPArch] 257 will be used, which are not repeated in this document. 259 OTrP Broker: It is the Broker as defined in the TEEP Architecture 260 document [TEEPArch]. 262 3.2. Abbreviations 264 CA Certificate Authority 266 OTrP Open Trust Protocol 268 REE Rich Execution Environment 270 SD Security Domain 272 SP Service Provider 274 TA Trusted Application 276 TEE Trusted Execution Environment 278 TFW Trusted Firmware 280 TAM Trusted Application Manager 282 4. OTrP Entities and Trust Model 283 4.1. System Components 285 The same system components as defined in the TEEP Architecture 286 document [TEEPArch] are used in OTrP, including TAM, CA, TEE, REE, 287 and OTrP Broker (a.k.a Broker). 289 Secure boot (for the purposes of OTrP) is optional in enabling 290 authenticity checking of TEEs by the TAM. A TAM provider can choose 291 it policy whether it trusts a TEE if the underlying firmware 292 attestation information is not included. 294 OTrP uses trust anchors to establish trust between TEEs and TAMs and 295 verifies that they communicate in a trusted way when performing 296 lifecycle management transactions. 298 4.2. Trust Anchors in TEE 300 This assumes the Trust Anchor specification defined in the TEEP 301 Architecture document [TEEPArch]. 303 Each TEE comes with a trust store that contains a whitelist of root 304 CA certificates that are used to validate a TAM's certificate. A TEE 305 will accept a TAM to create new Security Domains and install new TAs 306 on behalf of a SP only if the TAM's certificate is chained to one of 307 the root CA certificates in the TEE's trust store. 309 4.3. Trust Anchors in TAM 311 The Trust Anchor set in a TAM consists of a list of Certificate 312 Authority certificates that signs various device TEE certificates. A 313 TAM decides what TEE and optionally TFW it will trust when TFW 314 signature data is present in an attestation. 316 4.4. Keys and Certificate Types 318 OTrP leverages the following list of trust anchors and identities in 319 generating signed and encrypted command messages that are exchanged 320 between a device's TEE and a TAM. With these security artifacts, 321 OTrP Messages are able to deliver end-to-end security without relying 322 on any transport security. 324 +-------------+----------+--------+-------------------+-------------+ 325 | Key Entity | Location | Issuer | Trust Implication | Cardinality | 326 | Name | | | | | 327 +-------------+----------+--------+-------------------+-------------+ 328 | 1. TFW key | Device | FW CA | A whitelist of FW | 1 per | 329 | pair and | secure | | root CA trusted | device | 330 | certificate | storage | | by TAMs | | 331 | | | | | | 332 | 2. TEE key | Device | TEE CA | A whitelist of | 1 per | 333 | pair and | TEE | under | TEE root CA | device | 334 | certificate | | a root | trusted by TAMs | | 335 | | | CA | | | 336 | | | | | | 337 | 3. TAM key | TAM | TAM CA | A whitelist of | 1 or | 338 | pair and | provider | under | TAM root CA | multiple | 339 | certificate | | a root | embedded in TEE | can be used | 340 | | | CA | | by a TAM | 341 | | | | | | 342 | 4. SP key | SP | SP | TAM manages SP. | 1 or | 343 | pair and | | signer | TA trust is | multiple | 344 | certificate | | CA | delegated to TAM. | can be used | 345 | | | | TEE trusts TAM to | by a TAM | 346 | | | | ensure that a TA | | 347 | | | | is trustworthy. | | 348 +-------------+----------+--------+-------------------+-------------+ 350 Table 1: Key and Certificate Types 352 1. TFW key pair and certificate: A key pair and certificate for 353 evidence of trustworthy firmware in a device. This key pair is 354 optional. Some TEE may present its trusted attributes to a TAM 355 using signed attestation with a TFW key. For example, a platform 356 that uses a hardware based TEE can have attestation data signed 357 by a hardware protected TFW key. 359 Location: Device secure storage 361 Supported Key Type: RSA and ECC 363 Issuer: OEM CA 365 Trust Implication: A whitelist of FW root CA trusted by TAMs 367 Cardinality: One per device 369 2. TEE key pair and certificate: It is used for device attestation 370 to a remote TAM and SP. 372 This key pair is burned into the device at device manufacturer. 373 The key pair and its certificate are valid for the expected 374 lifetime of the device. 376 Location: Device TEE 378 Supported Key Type: RSA and ECC 380 Issuer: A CA that chains to a TEE root CA 382 Trust Implication: A whitelist of TEE root CA trusted by TAMs 384 Cardinality: One per device 386 3. TAM key pair and certificate: A TAM provider acquires a 387 certificate from a CA that a TEE trusts. 389 Location: TAM provider 391 Supported Key Type: RSA and ECC. 393 Supported Key Size: RSA 2048-bit, ECC P-256 and P-384. Other 394 sizes should be anticipated in future. 396 Issuer: TAM CA that chains to a root CA 398 Trust Implication: A whitelist of TAM root CA embedded in TEE 400 Cardinality: One or multiple can be used by a TAM 402 4. SP key pair and certificate: an SP uses its own key pair and 403 certificate to sign a TA. 405 Location: SP 407 Supported Key Type: RSA and ECC 409 Supported Key Size: RSA 2048-bit, ECC P-256 and P-384. Other 410 sizes should be anticipated in future. 412 Issuer: an SP signer CA that chains to a root CA 414 Trust Implication: TAM manages SP. TA trusts an SP by 415 validating trust against a TAM that the SP uses. A TEE trusts 416 TAM to ensure that a TA from the TAM is trustworthy. 418 Cardinality: One or multiple can be used by an SP 420 5. Protocol Scope and Entity Relations 422 This document specifies messages and key properties that can 423 establish mutual trust between a TEE and a TAM. The protocol 424 provides specifications for the following three entities: 426 1. Key and certificate types required for device firmware, TEEs, 427 TAs, SPs, and TAMs 429 2. Data message formats that should be exchanged between a TEE in a 430 device and a TAM 432 3. An OTrP Broker in the REE that can relay messages between a 433 Client Application and TEE 435 Figure 1: Protocol Scope and Entity Relationship 437 PKI CA -- CA CA -- 438 | | | 439 | | | 440 | | | 441 Device | | --- OTrP Broker / Client App --- | 442 SW | | | | | 443 | | | | | 444 | | | | | 445 OTrP | -- TEE TAM------- 446 | 447 | 448 FW 450 Figure 2: OTrP System Diagram 451 -------OTrP Message Protocol--- 452 | | 453 | | 454 -------------------- --------------- ---------- 455 | REE | TEE | | TAM | | SP | 456 | --- | --- | | --- | | -- | 457 | | | | | | | 458 | Client | SD (TAs)| | SD / TA | | TA | 459 | Apps | | | Mgmt | | | 460 | | | | | | | | 461 | | | List of | | List of | | | 462 | OTrP | Trusted | | Trusted | | | 463 | Broker | TAM/SP | | FW/TEE | | | 464 | | CAs | | CAs | | | 465 | | | | | | | 466 | |TEE Key/ | | TAM Key/ | | SP Key/| 467 | | Cert | | Cert | | Cert | 468 | | FW Key/ | | | | | 469 | | Cert | | | | | 470 -------------------- --------------- ---------- 471 | | | 472 | | | 473 ------------- ---------- --------- 474 | TEE CA | | TAM CA | | SP CA | 475 ------------- ---------- --------- 477 In the previous diagram, different Certificate Authorities can be 478 used respectively for different types of certificates. OTrP Messages 479 are always signed, where the signer keys is the message creator's 480 private key such as a FW's private key, a TEE's private key, or a 481 TAM's private key. 483 The main OTrP component consists of a set of standard JSON messages 484 created by a TAM to deliver device SD and TA management commands to a 485 device, and device attestation and response messages created by a TEE 486 that responds to a TAM's OTrP message. 488 The communication method of OTrP Messages between a TAM and TEE in a 489 device may vary between TAM and TEE providers. A mandatory transport 490 protocol is specified for a compliant TAM and a device TEE. 492 An OTrP Broker is used to bridge communication between a TAM and a 493 TEE. The OTrP Broker doesn't need to know the actual content of OTrP 494 Messages except for the TEE routing information. 496 5.1. A Sample Device Setup Flow 498 Step 1: Prepare Images for Devices 500 1. [TEE vendor] Deliver TEE Image (CODE Binary) to device OEM 502 2. [CA] Deliver root CA Whitelist 504 3. [Soc] Deliver TFW Image 506 Step 2: Inject Key Pairs and Images to Devices 508 1. [OEM] Generate Secure Boot Key Pair (May be shared among multiple 509 devices) 511 2. [OEM] Flash signed TFW Image and signed TEE Image onto devices 512 (signed by Secure Boot Key) 514 Step 3: Setup attestation key pairs in devices 516 1. [OEM] Flash TFW Public Key and a bootloader key. 518 2. [TFW/TEE] Generate a unique attestation key pair and get a 519 certificate for the device. 521 Step 4: Setup trust anchors in devices 523 1. [TFW/TEE] Store the key and certificate encrypted with the eFuse 524 key 526 2. [TEE vendor or OEM] Store trusted CA certificate list into 527 devices 529 5.2. Derived Keys in The Protocol 531 The protocol generates one key pair in run time to assist message 532 communication and anonymous verification between a TAM and a TEE. 534 TEE SP Anonymous Key (AIK): one derived key pair per SP in a device 536 The purpose of the key pair is to sign data by a TEE without using 537 its TEE device key for anonymous attestation to a Client Application. 538 This key pair is generated in the first SD creation for an SP. It is 539 deleted when all SDs are removed for a SP in a device. The public 540 key of the key pair is given to the caller Client Application and TAM 541 for future TEE returned data validation. The public key of this AIK 542 is also used by a TAM to encrypt TA binary data and personalization 543 data when it sends a TA to a device for installation. 545 5.3. Security Domain Hierarchy and Ownership 547 The primary job of a TAM is to help an SP to manage its trusted 548 application components. A TA is typically installed in an SD. An SD 549 is commonly created for an SP. 551 When an SP delegates its SD and TA management to a TAM, an SD is 552 created on behalf of a TAM in a TEE and the owner of the SD is 553 assigned to the TAM. An SD may be associated with an SP but the TAM 554 has full privilege to manage the SD for the SP. 556 Each SD for an SP is associated with only one TAM. When an SP 557 changes TAM, a new SP SD must be created to associate with the new 558 TAM. The TEE will maintain a registry of TAM ID and SP SD ID 559 mapping. 561 From an SD ownership perspective, the SD tree is flat and there is 562 only one level. An SD is associated with its owner. It is up to TEE 563 implementation how it maintains SD binding information for a TAM and 564 different SPs under the same TAM. 566 It is an important decision in this protocol specification that a TEE 567 doesn't need to know whether a TAM is authorized to manage the SD for 568 an SP. This authorization is implicitly triggered by an SP Client 569 Application, which instructs what TAM it wants to use. An SD is 570 always associated with a TAM in addition to its SP ID. A rogue TAM 571 isn't able to do anything on an unauthorized SP's SD managed by 572 another TAM. 574 Since a TAM may support multiple SPs, sharing the same SD name for 575 different SPs creates a dependency in deleting an SD. An SD can be 576 deleted only after all TAs associated with this SD is deleted. An SP 577 cannot delete a Security Domain on its own with a TAM if a TAM 578 decides to introduce such sharing. There are cases where multiple 579 virtual SPs belong to the same organization, and a TAM chooses to use 580 the same SD name for those SPs. This is totally up to the TAM 581 implementation and out of scope of this specification. 583 5.4. SD Owner Identification and TAM Certificate Requirements 585 There is a need of cryptographically binding proof about the owner of 586 an SD in a device. When an SD is created on behalf of a TAM, a 587 future request from the TAM must present itself as a way that the TEE 588 can verify it is the true owner. The certificate itself cannot 589 reliably used as the owner because TAM may change its certificate. 591 To this end, each TAM will be associated with a trusted identifier 592 defined as an attribute in the TAM certificate. This field is kept 593 the same when the TAM renew its certificates. A TAM CA is 594 responsible to vet the requested TAM attribute value. 596 This identifier value must not collide among different TAM providers, 597 and one TAM shouldn't be able to claim the identifier used by another 598 TAM provider. 600 The certificate extension name to carry the identifier can initially 601 use SubjectAltName:registeredID. A dedicated new extension name may 602 be registered later. 604 One common choice of the identifier value is the TAM's service URL. 605 A CA can verify the domain ownership of the URL with the TAM in the 606 certificate enrollment process. 608 A TEE can assign this certificate attribute value as the TAM owner ID 609 for the SDs that are created for the TAM. 611 An alternative way to represent an SD ownership by a TAM is to have a 612 unique secret key upon SD creation such that only the creator TAM is 613 able to produce a Proof-of-Possession (POP) data with the secret. 615 5.5. Service Provider Container 617 A sample Security Domain hierarchy for the TEE is shown below. 619 ---------- 620 | TEE | 621 ---------- 622 | 623 | ---------- 624 |----------| SP1 SD1 | 625 | ---------- 626 | ---------- 627 |----------| SP1 SD2 | 628 | ---------- 629 | ---------- 630 |----------| SP2 SD1 | 631 ---------- 633 OTrP segregates SDs and TAs such that a TAM can only manage or 634 retrieve data for SDs and TAs that it previously created for the SPs 635 it represents. 637 6. OTrP Broker 639 A TEE and TAs that run inside the TEE don't generally have capability 640 to communicate to the outside of the hosting device, for example, the 641 TEE specified by Global Platform groups [GPTEE]. This calls for a 642 software module in the REE world to handle the network communication. 643 Each Client Application in REE may carry this communication 644 functionality but it must also interact with the TEE for the message 645 exchange. The TEE interaction will vary according to different TEEs. 646 In order for a Client Application to transparently support different 647 TEEs, it is imperative to have a common interface for a Client 648 Application to invoke for exchanging messages with TEEs. 650 A shared OTrP Broker comes to meed this need. An OTrP Broker is a 651 Rich Application or SDK that facilitates communication between a TAM 652 and TEE. It also provides interfaces for TAM SDK or Client 653 Applications to query and trigger TA installation that the 654 application needs to use. 656 This interface for Client Applications may be commonly an Android 657 service call for an Android powered device. A Client Application 658 interacts with a TAM, and turns around to pass messages received from 659 TAM to OTrP Broker. 661 In all cases, a Client Application needs to be able to identify an 662 OTrP Broker that it can use. 664 6.1. Role of OTrP Broker 666 An OTrP Broker abstracts the message exchanges with the TEE in a 667 device. The input data is originated from a TAM that a Client 668 Application connects. A Client Application may also directly call 669 OTrP Broker for some TA query functions. 671 OTrP Broker may internally process a request from TAM. At least, it 672 needs to know where to route a message, e.g. TEE instance. It 673 doesn't need to process or verify message content. 675 OTrP Broker returns TEE / TFW generated response messages to the 676 caller. OTrP Broker isn't expected to handle any network connection 677 with an application or TAM. 679 OTrP Broker only needs to return an OTrP Broker error message if the 680 TEE is not reachable for some reason. Other errors are represented 681 as response messages returned from the TEE which will then be passed 682 to the TAM. 684 6.2. OTrP Broker and Global Platform TEE Client API 686 A Client Application may use Global Platform (GP) TEE API for TA 687 communication. OTrP may use the GP TEE Client API but it is internal 688 to OTrP implementation that converts given messages from TAM. More 689 details can be found at [GPTEECLAPI]. 691 6.3. OTrP Broker Implementation Consideration 693 A Provider should consider methods of distribution, scope and 694 concurrency on device and runtime options when implementing an OTrP 695 Broker. Several non-exhaustive options are discussed below. 696 Providers are encouraged to take advantage of the latest 697 communication and platform capabilities to offer the best user 698 experience. 700 6.3.1. OTrP Broker Distribution 702 OTrP Broker installation is commonly carried out at OEM time. A user 703 can dynamically download and install an OTrP Broker on-demand. 705 It is important to ensure a legitimate OTrP Broker is installed and 706 used. If an OTrP Broker is compromised it may send rogue messages to 707 TAM and TEE and introduce additional risks. 709 6.3.2. Number of OTrP Broker 711 We anticipate only one shared OTrP Broker instance in a device. The 712 device's TEE vendor will most probably supply one OTrP Broker. 713 Potentially we expect some open source. 715 With one shared OTrP Broker, the OTrP Broker provider is responsible 716 to allow multiple TAMs and TEE providers to achieve interoperability. 717 With a standard OTrP Broker interface, TAM can implement its own SDK 718 for its SP Client Applications to work with this OTrP Broker. 720 Multiple independent OTrP Broker providers can be used as long as 721 they have standard interface to a Client Application or TAM SDK. 722 Only one OTrP Broker is expected in a device. 724 TAM providers are generally expected to provide SDK for SP 725 applications to interact with an OTrP Broker for the TAM and TEE 726 interaction. 728 6.4. OTrP Broker Interfaces for Client Applications 730 A Client Application shall be responsible for relaying messages 731 between the OTrP Broker and the TAM. 733 If a failure occurs during calling OTrP Broker, an error message 734 described in "Common Errors" section (see Section 7.6) will be 735 returned. 737 6.4.1. ProcessOTrPMessage call 739 Description 741 A Client Application will use this method of the OTrP Broker in a 742 device to pass OTrP messages from a TAM. The method is 743 responsible for interacting with the TEE and for forwarding the 744 input message to the TEE. It also returns TEE generated response 745 message back to the Client Application. 747 Inputs: 749 TAMInMsg - OTrP message generated in a TAM that is passed to this 750 method from a Client Application. 752 Outputs: 754 A TEE-generated OTrP response message (which may be a successful 755 response or be a response message containing an error raised 756 within the TEE) for the client application to forward to the TAM. 757 In the event of the OTrP Broker not being able to communicate with 758 the TEE, a OTrPBrokerException shall be thrown. 760 6.4.2. GetTAInformation call 762 Description 764 A Client Application may quickly query local TEE about a 765 previously installed TA without requiring TAM each time if it has 766 had the TA's identifier and previously saved TEE SP AIK public key 767 for TA information integrity verification. 769 Inputs: 771 { 772 "TAQuery": { 773 "spid": "", 774 "taid": "" 775 } 776 } 778 Outputs: 780 The OTrP Broker is expected to return TA signer and TAM signer 781 certificate along with other metadata information about the TA 782 associated with the given identifier. It follows the underlying 783 TEE trust model for authoring the local TA query from a Client 784 Application. 786 The output is a JSON message that is generated by the TEE. It 787 contains the following information: 789 * tamid 791 * SP ID 793 * TA signer certificate 795 * TAM certificate 797 The message is signed with TEE SP AIK private key. 799 The Client Application is expected to consume the response as 800 follows. 802 The Client Application gets signed TA metadata, in particular, the 803 TA signer certificate. It is able to verify that the result is 804 from device by checking signer against TEE SP AIK public key it 805 gets in some earlier interaction with TAM. 807 If this is a new Client Application in the device that hasn't had 808 TEE SP AIK public key for the response verification, the 809 application can contact the TAM first to do GetDeviceState, and 810 TAM will return TEE SP AIK public key to the app for this 811 operation to proceed. 813 Output Message: 815 { 816 "TAInformationTBS": { 817 "taid": "", 818 "tamid": "", 820 "spid": "", 821 "signercert": "", 823 "signercacerts": [ < The full list of CA certificate chain 824 including the root CA> 825 ], 826 "cacert": "" 828 ], 829 "tamcert": "", 831 "tamcacerts": [ < The full list of CA certificate chain 832 including the root CA> 833 ], 834 "cacert":"" 836 ] 837 } 838 } 840 { 841 "TAInformation": { 842 "payload": "", 844 "protected": "", 845 "header": { 846 "signer": {""} 848 }, 849 "signature": "" 851 } 852 } 854 where the definitions of BASE64 and BASE64URL refer to [RFC4648]. 856 A sample JWK public key representation refers to an example in 857 [RFC7517]. 859 6.5. Sample End-to-End Client Application Flow 861 6.5.1. Case 1: A New Client Application Uses a TA 863 1. During the Client Application installation time, the Client 864 Application calls TAM to initialize the device preparation step. 866 A. The Client Application knows it wants to use a Trusted 867 Application TA1 but the application doesn't know whether TA1 868 has been installed or not. It can use GP TEE Client API 869 [GPTEECLAPI] to check the existence of TA1 first. If it 870 detects that TA1 doesn't exist, it will contact TAM to 871 initiate the installation of TA1. Note that TA1 could have 872 been previously installed by other Client Applications from 873 the same service provider in the device. 875 B. The Client Application sends the TAM the TA list that it 876 depends on. The TAM will query a device for the Security 877 Domains and TAs that have been installed, and instructs the 878 device to install any dependent TAs that have not been 879 installed. 881 C. In general, the TAM has the latest TA list and their status 882 in a device because all operations are instructed by TAM. 883 TAM has such visibility because all Security Domain deletion 884 and TA deletion are managed by the TAM; the TAM could have 885 stored the state when a TA is installed, updated and 886 deleted. There is also the possibility that an update 887 command is carried out inside TEE but a response is never 888 received in TAM. There is also possibility that some manual 889 local reset is done in a device that the TAM isn't aware of 890 the changes. 892 2. The TAM generates message: GetDeviceStateRequest 894 3. The Client Application passes the JSON message 895 GetDeviceStateRequest to OTrP Broker call ProcessOTrPMessage. 896 The communication between a Client Application and an OTrP 897 Broker is up to the implementation of the OTrP Broker. 899 4. The OTrP Broker routes the message to the active TEE. Multiple 900 TEE case: it is up to OTrP Broker to figure this out. This 901 specification limits the support to only one active TEE, which 902 is the typical case today. 904 5. The target active TEE processes the received OTrP message, and 905 returns a JSON message GetDeviceStateResponse. 907 6. The OTrP Broker passes the GetDeviceStateResponse to the Client 908 Application. 910 7. The Client Application sends GetDeviceStateResponse to the TAM. 912 8. The TAM processes the GetDeviceStateResponse. 914 A. Extract TEEspaik for the SP, signs TEEspaik with TAM signer 915 key 917 B. Examine SD list and TA list 919 9. The TAM continues to carry out other actions based on the need. 920 The next call could be instructing the device to install a 921 dependent TA. 923 A. Assume a dependent TA isn't in the device yet, the TAM may 924 do the following: (1) create an SD in which to install the 925 TA by sending a CreateSDRequest message. The message is 926 sent back to the Client Application, and then the OTrP 927 Broker and TEE to process; (2) install a TA with an 928 InstallTARequest message. 930 B. If a Client Application depends on multiple TAs, the Client 931 Application should expect multiple round trips of the TA 932 installation message exchanges. 934 10. At the last TAM and TEE operation, the TAM returns the signed 935 TEE SP AIK public key to the application. 937 11. The Client Application stores the TEEspaik for future loaded TA 938 trust check. 940 12. If the TAM finds that this is a fresh device that does not have 941 any SD for the SP yet, then the TAM may next create an SD for 942 the SP. 944 13. During Client Application installation, the application checks 945 whether required Trusted Applications are already installed, 946 which may have been provided by the TEE. If needed, it will 947 contact its TAM service to determine whether the device is ready 948 or install TA list that this application needs. 950 6.5.2. Case 2: A Previously Installed Client Application Calls a TA 952 1. The Client Application checks the device readiness: (a) whether 953 it has a TEE; (b) whether it has TA that it depends. It may 954 happen that TAM has removed the TA this application depends on. 956 2. The Client Application calls the OTrP Broker to query the TA. 958 3. The OTrP Broker queries the TEE to get TA information. If the 959 given TA doesn't exist, an error is returned. 961 4. The Client Application parses the TAInformation message. 963 5. If the TA doesn't exist, the Client Application calls its TAM to 964 install the TA. If the TA exists, the Client Application 965 proceeds to call the TA. 967 7. OTrP Messages 969 The main OTrP component is the set of standard JSON messages created 970 by a TAM to deliver device SD and TA management commands to a device, 971 and device attestation and response messages created by TEE to 972 respond to TAM OTrP Messages. 974 An OTrP Message is designed to provide end-to-end security. It is 975 always signed by its creator. In addition, an OTrP Message is 976 typically encrypted such that only the targeted device TEE or TAM is 977 able to decrypt and view the actual content. 979 7.1. Message Format 981 OTrP Messages use the JSON format for JSON's simple readability and 982 moderate data size in comparison with alternative TLV and XML 983 formats. More compact CBOR format may be used as an alternative 984 choice. 986 JSON Message security has developed JSON Web Signing and JSON Web 987 Encryption standard in the IETF Workgroup JOSE, see JWS [RFC7515] and 988 JWE [RFC7516]. The OTrP Messages in this protocol will leverage the 989 basic JWS and JWE to handle JSON signing and encryption. 991 7.2. Message Naming Convention 993 For each TAM command "xyz"", OTrP use the following naming convention 994 to represent its raw message content and complete request and 995 response messages: 997 +-----------------------+----------------+---------------------+ 998 | Purpose | Message Name | Example | 999 +-----------------------+----------------+---------------------+ 1000 | Request to be signed | xyzTBSRequest | CreateSDTBSRequest | 1001 | | | | 1002 | Request message | xyzRequest | CreateSDRequest | 1003 | | | | 1004 | Response to be signed | xyzTBSResponse | CreateSDTBSResponse | 1005 | | | | 1006 | Response message | xyzResponse | CreateSDResponse | 1007 +-----------------------+----------------+---------------------+ 1009 7.3. Request and Response Message Template 1011 An OTrP Request message uses the following format: 1013 { 1014 "TBSRequest": { 1015 1016 } 1017 } 1019 A corresponding OTrP Response message will be as follows. 1021 { 1022 "TBSResponse": { 1023 1024 } 1025 } 1027 7.4. Signed Request and Response Message Structure 1029 A signed request message will generally include only one signature, 1030 and uses the flattened JWS JSON Serialization Syntax, see 1031 Section 7.2.2 in [RFC7515]. 1033 A general JWS object looks like the following. 1035 { 1036 "payload": "", 1037 "protected": "", 1038 "header": { 1039 , 1040 }, 1041 "signature": "" 1042 } 1043 OTrP signed messages only require the signing algorithm as the 1044 mandate header in the property "protected". The "non-integrity- 1045 protected header contents" is optional. 1047 OTrP signed message will be given an explicit Request or Response 1048 property name. In other words, a signed Request or Response uses the 1049 following template. 1051 A general JWS object looks like the following. 1053 { 1054 "[Request | Response]": { 1055 TBS[Request | Response] 1056 } 1057 } 1059 With the standard JWS message format, a signed OTrP Message looks 1060 like the following. 1062 { 1063 "[Request | Response]": { 1064 "payload": "TBS[Request | Response]>", 1065 "protected": "", 1066 "header": , 1067 "signature": "" 1068 } 1069 } 1071 The top element "[Signed][Request|Response]" cannot be fully 1072 trusted to match the content because it doesn't participate in the 1073 signature generation. However, a recipient can always match it with 1074 the value associated with the property "payload". It purely serves 1075 to provide a quick reference for reading and method invocation. 1077 Furthermore, most properties in an unsigned OTrP messages are 1078 encrypted to provide end-to-end confidentiality. The only OTrP 1079 message that isn't encrypted is the initial device query message that 1080 asks for the device state information. 1082 Thus a typical OTrP Message consists of an encrypted and then signed 1083 JSON message. Some transaction data such as transaction ID and TEE 1084 information may need to be exposed to the OTrP Broker for routing 1085 purpose. Such information is excluded from JSON encryption. The 1086 device's signer certificate itself is encrypted. The overall final 1087 message is a standard signed JSON message. 1089 As required by JSW/JWE, those JWE and JWS related elements will be 1090 BASE64URL encoded. Other binary data elements specific to the OTrP 1091 specification are BASE64-encoded. This specification indicates 1092 elements that should be BASE64 and those elements that are to be 1093 BASE64URL encoded. 1095 7.4.1. Identifying Signing and Encryption Keys for JWS/JWE Messaging 1097 JWS and JWE messaging allow various options for identifying the 1098 signing and encryption keys, for example, it allows optional elements 1099 including "x5c", "x5t" and "kid" in the header to cover various 1100 possibilities. 1102 To protect privacy, it is important that the device's certificate is 1103 released only to a trusted TAM, and that it is encrypted. The TAM 1104 will need to know the device certificate, but untrusted parties must 1105 not be able to get the device certificate. All OTrP messaging 1106 conversations between a TAM and device begin with 1107 GetDeviceStateRequest / GetDeviceStateResponse. These messages have 1108 elements built into them to exchange signing certificates, described 1109 in the section Section 9. Any subsequent messages in the 1110 conversation that follow on from this implicitly use the same 1111 certificates for signing/encryption, and as a result the certificates 1112 or references may be omitted in those subsequent messages. 1114 In other words, the signing key identifier in the use of JWS and JWE 1115 here may be absent in the subsequent messages after the initial 1116 GetDeviceState query. 1118 This has an implication on the TEE and TAM implementation: they have 1119 to cache the signer certificates for the subsequent message signature 1120 validation in the session. It may be easier for a TAM service to 1121 cache transaction session information but not so for a TEE in a 1122 device. A TAM can get a device's capability by checking the response 1123 message from a TEE to decide whether it should include its TAM signer 1124 certificate and OCSP data in each subsequent request message. The 1125 device's caching capability is reported in GetDeviceStateResponse 1126 signerreq parameter. 1128 7.5. JSON Signing and Encryption Algorithms 1130 The OTrP JSON signing algorithm shall use SHA256 or a stronger hash 1131 method with respective key type. JSON Web Algorithm RS256 or ES256 1132 [RFC7518] SHALL be used for RSA with SHA256 and ECDSA with SHA256. 1133 If RSA with SHA256 is used, the JSON web algorithm representation is 1134 as follows. 1136 {"alg":"RS256"} 1138 The (BASE64URL encoded) "protected" header property in a signed 1139 message looks like the following: 1141 "protected":"eyJhbGciOiJSUzI1NiJ9" 1143 If ECSDA with P-256 curve and SHA256 are used for signing, the JSON 1144 signing algorithm representation is as follows. 1146 {"alg":"ES256"} 1148 The value for the "protected" field will be the following. 1150 eyJhbGciOiJFUzI1NiJ9 1152 Thus, a common OTrP signed message with ES256 looks like the 1153 following. 1155 { 1156 "payload": "", 1157 "protected": "eyJhbGciOiJFUzI1NiJ9", 1158 "signature": "" 1159 } 1161 The OTrP JSON message encryption algorithm SHOULD use one of the 1162 supported algorithms defined in the later chapter of this document. 1163 JSON encryption uses a symmetric key as its "Content Encryption Key 1164 (CEK)". This CEK is encrypted or wrapped by a recipient's key. The 1165 OTrP recipient typically has an asymmetric key pair. Therefore, the 1166 CEK will be encrypted by the recipient's public key. 1168 A compliant implementation shall support the following symmetric 1169 encryption algorithm and anticipate future new algorithms. 1171 {"enc":"A128CBC-HS256"} 1173 This algorithm represents encryption with AES 128 in CBC mode with 1174 HMAC SHA 256 for integrity. The value of the property "protected" in 1175 a JWE message will be 1177 eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0 1179 An encrypted JSON message looks like the following. 1181 { 1182 "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0", 1183 "recipients": [ 1184 { 1185 "header": { 1186 "alg": "" 1187 }, 1188 "encrypted_key": "" 1189 } 1190 ], 1191 "iv": "", 1192 "ciphertext": "", 1194 "tag": "" 1195 } 1197 OTrP doesn't use JWE AAD (Additional Authenticated Data) because each 1198 message is always signed after the message is encrypted. 1200 7.5.1. Supported JSON Signing Algorithms 1202 The following JSON signature algorithm is mandatory support in the 1203 TEE and TAM: 1205 o RS256 1207 ES256 is optional to support. 1209 7.5.2. Support JSON Encryption Algorithms 1211 The following JSON authenticated encryption algorithm is mandatory 1212 support in TEE and TAM. 1214 o A128CBC-HS256 1216 A256CBC-HS512 is optional to support. 1218 7.5.3. Supported JSON Key Management Algorithms 1220 The following JSON key management algorithm is mandatory support in 1221 TEE and TAM. 1223 o RSA1_5 1225 ECDH-ES+A128KW and ECDH-ES+A256KW are optional to support. 1227 7.6. Common Errors 1229 An OTrP Response message typically needs to report the operation 1230 status and error causes if an operation fails. The following JSON 1231 message elements should be used across all OTrP Messages. 1233 "status": "pass | fail" 1235 "reason": { 1236 "error-code": "", 1237 "error-message": "" 1238 } 1240 "ver": "" 1242 7.7. OTrP Message List 1244 The following table lists the OTrP commands and therefore 1245 corresponding Request and Response messages defined in this 1246 specification. Additional messages may be added in the future when 1247 new task messages are needed. 1249 GetDeviceState - 1250 A TAM queries a device's current state with a message 1251 GetDeviceStateRequest. A device TEE will report its version, its 1252 FW version, and list of all SDs and TAs in the device that is 1253 managed by the requesting TAM. TAM may determine whether the 1254 device is trustworthy and decide to carry out additional commands 1255 according to the response from this query. 1257 CreateSD - 1258 A TAM instructs a device TEE to create an SD for an SP. The 1259 recipient TEE will check whether the requesting TAM is 1260 trustworthy. 1262 UpdateSD - 1263 A TAM instructs a device TEE to update an existing SD. A typical 1264 update need comes from SP certificate change, TAM certificate 1265 change and so on. The recipient TEE will verify whether the TAM 1266 is trustworthy and owns the SD. 1268 DeleteSD - 1269 A TAM instructs a device TEE to delete an existing SD. A TEE 1270 conditionally deletes TAs loaded in the SD according to a request 1271 parameter. An SD cannot be deleted until all TAs in this SD are 1272 deleted. If this is the last SD for an SP, TEE MAY also delete 1273 TEE SP AIK key for this SP. 1275 InstallTA - 1276 A TAM instructs a device to install a TA into an SD for a SP. 1277 The TEE in a device will check whether the TAM and TA are 1278 trustworthy. 1280 UpdateTA - 1281 A TAM instructs a device to update a TA into an SD for an SP. 1282 The change may commonly be bug fix for a previously installed TA. 1284 DeleteTA - 1285 A TAM instructs a device to delete a TA. The TEE in a device 1286 will check whether the TAM and TA are trustworthy. 1288 7.8. OTrP Request Message Routing Rules 1290 For each command that a TAM wants to send to a device, the TAM 1291 generates a request message. This is typically triggered by a Client 1292 Application that uses the TAM. The Client Application initiates 1293 contact with the TAM and receives TAM OTrP Request messages according 1294 to the TAM's implementation. The Client Application forwards the 1295 OTrP message to an OTrP Broker in the device, which in turn sends the 1296 message to the active TEE in the device. 1298 The current version of this specification assumes that each device 1299 has only one active TEE, and the OTrP Broker is responsible to 1300 connect to the active TEE. This is the case today with devices in 1301 the market. 1303 When the TEE responds to a request, the OTrP Broker gets the OTrP 1304 response messages back to the Client Application that sent the 1305 request. In case the target TEE fails to respond to the request, the 1306 OTrP Broker will be responsible to generate an error message to reply 1307 the Client Application. The Client Application forwards any data it 1308 received to its TAM. 1310 7.8.1. SP Anonymous Attestation Key (SP AIK) 1312 When the first new Security Domain is created in a TEE for an SP, a 1313 new key pair is generated and associated with this SP. This key pair 1314 is used for future device attestation to the service provider instead 1315 of using the device's TEE key pair. 1317 8. Transport Protocol Support 1319 The OTrP message exchange between a TEE device and TAM generally 1320 takes place between a Client Application in REE and TAM. A device 1321 that is capable to run a TEE and PKI based cryptographic attestation 1322 isn't generally resource constraint to carry out standard HTTPS 1323 connections. A compliant device and TAM SHOULD support HTTPs. 1325 9. Detailed Messages Specification 1327 For each message in the following sections all JSON elements are 1328 mandatory if not explicitly indicated as optional. 1330 9.1. GetDeviceState 1332 This is the first command that a TAM will send to a device. This 1333 command is triggered when an SP's Client Application contacts its TAM 1334 to check whether the underlying device is ready for TA operations. 1336 This command queries a device's current TEE state. A device TEE will 1337 report its version, its FW version, and list of all SDs and TAs in 1338 the device that is managed by the requesting TAM. TAM may determine 1339 whether the device is trustworthy and decide to carry out additional 1340 commands according to the response from this query. 1342 The request message of this command is signed by the TAM. The 1343 response message from the TEE is encrypted. A random message 1344 encryption key (MK) is generated by TEE, and this encrypted key is 1345 encrypted by the TAM's public key such that only the TAM that sent 1346 the request is able to decrypt and view the response message. 1348 9.1.1. GetDeviceStateRequest message 1350 { 1351 "GetDeviceStateTBSRequest": { 1352 "ver": "1.0", 1353 "rid": "", 1354 "tid": "", 1355 "ocspdat": ["], 1356 "supportedsigalgs": [] 1357 } 1358 } 1360 The request message consists of the following data elements: 1362 ver - version of the message format 1364 rid - a unique request ID generated by the TAM 1366 tid - a unique transaction ID to trace request and response. This 1367 can be from a prior transaction's tid field, and can be used in 1368 subsequent message exchanges in this TAM session. The 1369 combination of rid and tid MUST be made unique. 1371 ocspdat - A list of OCSP stapling data respectively for the TAM 1372 certificate and each of the CA certificates up to the root 1373 certificate. The TAM provides OCSP data such that a recipient 1374 TEE can validate the TAM certificate chain revocation status 1375 without making its own external OCSP service call. A TEE MAY 1376 cache the CA OCSP data such that the array may contain only the 1377 OCSP stapling data for the TAM certificate in subsequent 1378 exchanges. This is a mandatory field. 1380 supportedsigalgs - an optional property to list the signing 1381 algorithms that the TAM is able to support. A recipient TEE MUST 1382 choose an algorithm in this list to sign its response message if 1383 this property is present in a request. If it is absent, the TEE 1384 may use any compliant signing algorithm that is listed as 1385 mandatory support in this specification. 1387 The final request message is JSON signed message of the above raw 1388 JSON data with TAM's certificate. 1390 { 1391 "GetDeviceStateRequest": { 1392 "payload": "", 1394 "protected": "", 1395 "header": { 1396 "x5c": "" 1398 }, 1399 "signature":"" 1400 } 1401 } 1403 The signing algorithm SHOULD use SHA256 with respective key type. 1404 The mandatory algorithm support is the RSA signing algorithm. The 1405 signer header "x5c" is used to include the TAM signer certificate up 1406 to the root CA certificate. 1408 9.1.2. Request processing requirements at a TEE 1410 Upon receiving a request message GetDeviceStateRequest at a TEE, the 1411 TEE MUST validate a request: 1413 1. Validate JSON message signing. If it doesn't pass, an error 1414 message is returned. 1416 2. Validate that the request TAM certificate is chained to a trusted 1417 CA that the TEE embeds as its trust anchor. 1419 * Cache the CA OCSP stapling data and certificate revocation 1420 check status for other subsequent requests. 1422 * A TEE can use its own clock time for the OCSP stapling data 1423 validation. 1425 3. Optionally collect Firmware signed data 1427 * This is a capability in ARM architecture that allows a TEE to 1428 query Firmware to get FW signed data. It isn't required for 1429 all TEE implementations. When TFW signed data is absent, it 1430 is up to a TAM's policy how it will trust a TEE. 1432 4. Collect SD information for the SD owned by this TAM 1434 9.1.3. Firmware Signed Data 1436 Firmware isn't expected to process or produce JSON data. It is 1437 expected to just sign some raw bytes of data. 1439 The data to be signed by TFW key needs be some unique random data 1440 each time. The (UTF-8 encoded) "tid" value from the 1441 GetDeviceStateTBSRequest shall be signed by the firmware. TAM isn't 1442 expected to parse TFW data except the signature validation and signer 1443 trust path validation. 1445 It is possible that a TEE can get some valid TFW signed data from 1446 another device. The TEE is responsible to validate TFW integrity to 1447 ensure that the underlying device firmware is trustworthy. In some 1448 cases, a TEE isn't able to get a TFW signed data, in which case the 1449 TEE trust validation is up to a TAM to decide. A TAM may opt to 1450 trust a TEE basing on the TEE signer and additional information about 1451 a TEE out-of-band. 1453 When TFW signed data is available, a TAM validates the TEE and trusts 1454 that a trusted TEE has carried out appropriate trust check about a 1455 TFW. 1457 TfwData: { 1458 "tbs": "", 1459 "cert": "", 1460 "sigalg": "Signing method", 1461 "sig": "" 1462 } 1464 It is expected that a FW uses standard signature methods for maximal 1465 interoperability with TAM providers. The mandatory support list of 1466 signing algorithm is RSA with SHA256. 1468 The JSON object above is constructed by a TEE with data returned from 1469 the FW. It isn't a standard JSON signed object. The signer 1470 information and data to be signed must be specially processed by a 1471 TAM according to the definition given here. The data to be signed is 1472 the raw data. 1474 9.1.3.1. Supported Firmware Signature Methods 1476 TAM providers shall support the following signature methods. A 1477 firmware provider can choose one of the methods in signature 1478 generation. 1480 o RSA with SHA256 1482 o ECDSA with SHA 256 1484 The value of "sigalg" in the TfwData JSON message SHOULD use one of 1485 the following: 1487 o RS256 1489 o ES256 1491 9.1.4. Post Conditions 1493 Upon successful request validation, the TEE information is collected. 1494 There is no change in the TEE in the device. 1496 The response message shall be encrypted where the encryption key 1497 shall be a symmetric key that is wrapped by TAM's public key. The 1498 JSON Content Encryption Key (CEK) is used for this purpose. 1500 9.1.5. GetDeviceStateResponse Message 1502 The message has the following structure. 1504 { 1505 "GetDeviceTEEStateTBSResponse": { 1506 "ver": "1.0", 1507 "status": "pass | fail", 1508 "rid": "", 1509 "tid": "", 1510 "signerreq": true | false // about whether TAM needs to send 1511 signer data again in subsequent messages, 1512 "edsi": "" 1513 } 1514 } 1516 where 1518 signerreq - true if the TAM should send its signer certificate and 1519 OCSP data again in the subsequent messages. The value may be 1520 "false" if the TEE caches the TAM's signer certificate and OCSP 1521 status. 1523 rid - the request ID from the request message 1525 tid - the tid from the request message 1527 edsi - the main data element whose value is JSON encrypted message 1528 over the following Device State Information (DSI). 1530 The Device State Information (DSI) message consists of the following. 1532 { 1533 "dsi": { 1534 "tfwdata": { 1535 "tbs": "" 1536 "cert": "", 1537 "sigalg": "Signing method", 1538 "sig": "" 1539 }, 1540 "tee": { 1541 "name": "", 1542 "ver": "", 1543 "cert": "", 1544 "cacert": "", 1546 "sdlist": { 1547 "cnt": "", 1548 "sd": [ 1549 { 1550 "name": "", 1551 "spid": "", 1552 "talist": [ 1553 { 1554 "taid": "", 1555 "taname": "" // optional 1557 } 1558 ] 1559 } 1560 ] 1561 }, 1562 "teeaiklist": [ 1563 { 1564 "spaik": "", 1565 "spaiktype": "", 1566 "spid": "" 1567 } 1568 ] 1569 } 1570 } 1571 } 1573 The encrypted JSON message looks like the following. 1575 { 1576 "protected": "", 1578 "recipients": [ 1579 { 1580 "header": { 1581 "alg": "RSA1_5" 1582 }, 1583 "encrypted_key": "" 1584 } 1585 ], 1586 "iv": "", 1587 "ciphertext": "", 1589 "tag": "" 1590 } 1592 Assume we encrypt plaintext with AES 128 in CBC mode with HMAC SHA 1593 256 for integrity, the encryption algorithm header is: 1595 {"enc":"A128CBC-HS256"} 1597 The value of the property "protected" in the above JWE message will 1598 be 1600 eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0 1602 In other words, the above message looks like the following: 1604 { 1605 "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0", 1606 "recipients": [ 1607 { 1608 "header": { 1609 "alg": "RSA1_5" 1610 }, 1611 "encrypted_key": "" 1612 } 1613 ], 1614 "iv": "", 1615 "ciphertext": "", 1617 "tag": "" 1618 } 1620 The full response message looks like the following: 1622 { 1623 "GetDeviceTEEStateTBSResponse": { 1624 "ver": "1.0", 1625 "status": "pass | fail", 1626 "rid": "", 1627 "tid": "", 1628 "signerreq": "true | false", 1629 "edsi": { 1630 "protected": "", 1632 "recipients": [ 1633 { 1634 "header": { 1635 "alg": "RSA1_5" 1636 }, 1637 "encrypted_key": "" 1638 } 1639 ], 1640 "iv": "", 1641 "ciphertext": "", 1643 "tag": "" 1644 } 1645 } 1646 } 1648 The CEK will be encrypted by the TAM public key in the device. The 1649 TEE signed message has the following structure. 1651 { 1652 "GetDeviceTEEStateResponse": { 1653 "payload": "", 1655 "protected": "", 1656 "signature": "" 1657 } 1658 } 1660 The signing algorithm shall use SHA256 with respective key type, see 1661 Section 7.5.1. 1663 The final GetDeviceStateResponse response message consists of an 1664 array of TEE responses. 1666 { 1667 "GetDeviceStateResponse": [ // JSON array 1668 {"GetDeviceTEEStateResponse": ...}, 1669 ... 1670 {"GetDeviceTEEStateResponse": ...} 1671 ] 1672 } 1674 9.1.6. Error Conditions 1676 An error may occur if a request isn't valid or the TEE runs into some 1677 error. The list of possible error conditions is the following. 1679 ERR_REQUEST_INVALID The TEE meets the following conditions with a 1680 request message: (1) The request from a TAM has an invalid message 1681 structure; mandatory information is absent in the message; or an 1682 undefined member or structure is included. (2) TEE fails to verify 1683 the signature of the message or fails to decrypt its contents. 1685 ERR_UNSUPPORTED_MSG_VERSION The TEE receives a version of message 1686 that the TEE can't deal with. 1688 ERR_UNSUPPORTED_CRYPTO_ALG The TEE receives a request message 1689 encoded with a cryptographic algorithm that the TEE doesn't 1690 support. 1692 ERR_TFW_NOT_TRUSTED The TEE considers the underlying device firmware 1693 be not trustworthy. 1695 ERR_TAM_NOT_TRUSTED The TEE needs to make sure whether the TAM is 1696 trustworthy by checking the validity of the TAM certificate and 1697 OCSP stapling data and so on. If the TEE finds the TAM is not 1698 reliable, it returns this error code. 1700 ERR_TEE_FAIL If the TEE fails to process a request because of its 1701 internal error but is able to sign an error response message, it 1702 will return this error code. 1704 ERR_AGENT_TEE_FAIL The TEE failed to respond to a TAM request. The 1705 OTrP Broker will construct an error message in responding to the 1706 TAM's request. The error message will not be signed. 1708 The response message will look like the following if the TEE signing 1709 can work to sign the error response message. 1711 { 1712 "GetDeviceTEEStateTBSResponse": { 1713 "ver": "1.0", 1714 "status": "fail", 1715 "rid": "", 1716 "tid": "", 1717 "reason": {"error-code":""} 1718 "supportedsigalgs": [] 1720 } 1721 } 1723 where 1725 supportedsigalgs - an optional property to list the JWS signing 1726 algorithms that the active TEE supports. When a TAM sends a 1727 signed message that the TEE isn't able to validate, it can 1728 include signature algorithms that it is able to consume in this 1729 status report. A TAM can generate a new request message to retry 1730 the management task with a TEE-supported signing algorithm. 1732 If the TEE isn't able to sign an error message due to an internal 1733 device error, a general error message should be returned by the OTrP 1734 Broker. 1736 9.1.7. TAM Processing Requirements 1738 Upon receiving a GetDeviceStateResponse message at a TAM, the TAM 1739 MUST validate the following. 1741 o Parse to get list of GetDeviceTEEStateResponse JSON objects 1743 o Parse the JSON "payload" property and decrypt the JSON element 1744 "edsi". The decrypted message contains the TEE signer 1745 certificate. 1747 o Validate the GetDeviceTEEStateResponse JSON signature. The signer 1748 certificate is extracted from the decrypted message in the last 1749 step. 1751 o Extract TEE information and check it against its TEE acceptance 1752 policy. 1754 o Extract the TFW signed element, and check the signer and data 1755 integration against its TFW policy. 1757 o Check the SD list and TA list and prepare for a subsequent command 1758 such as "CreateSD" if it needs to have a new SD for an SP. 1760 9.2. Security Domain Management 1762 9.2.1. CreateSD 1764 This command is typically preceded with a GetDeviceState command that 1765 has acquired the device information of the target device by the TAM. 1766 The TAM sends such a command to instruct a TEE to create a new 1767 Security Domain for an SP. 1769 A TAM sends an OTrP CreateSDRequest Request message to a device TEE 1770 to create a Security Domain for an SP. Such a request is signed by 1771 the TAM where the TAM signer may or may not be the same as the SP's 1772 TA signer certificate. The resulting SD is associated with two 1773 identifiers for future management: 1775 o TAM as the owner. The owner identifier is a registered unique TAM 1776 ID that is stored in the TAM certificate. 1778 o SP identified by its TA signer certificate as the authorization. 1779 A TAM can add more than one SP certificate to an SD. 1781 A Trusted Application that is signed by a matching SP signer 1782 certificate for an SD is eligible to be installed into that SD. The 1783 TA installation into an SD by a subsequent InstallTARequest message 1784 may be instructed from a TAM. 1786 9.2.1.1. CreateSDRequest Message 1787 The request message for CreateSD has the following JSON format. 1789 { 1790 "CreateSDTBSRequest": { 1791 "ver": "1.0", 1792 "rid": "", 1793 "tid": "", // this may be from prior message 1794 "tee": "", 1795 "nextdsi": true | false, 1796 "dsihash": "", 1797 "content": ENCRYPTED { // this piece of JSON data will be 1798 // encrypted 1799 "spid": "", 1800 "sdname": "", 1801 "spcert": "", 1802 "tamid": "", 1804 "did": "" 1805 } 1806 } 1807 } 1809 In the message, 1811 rid - A unique value to identify this request 1813 tid - A unique value to identify this transaction. It can have the 1814 same value for the tid in the preceding GetDeviceStateRequest. 1816 tee - TEE ID returned from the previous GetDeviceStateResponse. 1818 nextdsi - Indicates whether the up-to-date Device State Information 1819 (DSI) is expected in the response from the TEE to this request. 1821 dsihash - The BASE64-encoded SHA256 hash value of the DSI data 1822 returned in the prior TAM operation with this target TEE. This 1823 value is always included such that a receiving TEE can check 1824 whether the device state has changed since its last query. It 1825 helps enforce SD update order in the right sequence without 1826 accidentally overwriting an update that was done simultaneously. 1828 content - The "content" is a JSON encrypted message that includes 1829 actual input for the SD creation. The encryption key is TAMmk that 1830 is encrypted by the target TEE's public key. The entire message is 1831 signed by the TAM private key TAMpriv. A separate TAMmk isn't used 1832 in the latest specification because JSON encryption will use a 1833 content encryption key for exactly the same purpose. 1835 spid - A unique id assigned by the TAM for its SP. It should be 1836 unique within a TAM namespace. 1838 sdname - a name unique to the SP. TAM should ensure it is unique 1839 for each SP. 1841 spcert - The SP's TA signer certificate is included in the request. 1842 This certificate will be stored by the device TEE which uses it to 1843 check against TA installation. Only if a TA is signed by a 1844 matching spcert associated with an SD will the TA be installed into 1845 the SD. 1847 tamid - SD owner claim by TAM - an SD owned by a TAM will be 1848 associated with a trusted identifier defined as an attribute in the 1849 signer TAM certificate. TEE will be responsible to assign this ID 1850 to the SD. The TAM certificate attribute for this attribute tamid 1851 MUST be vetted by the TAM signer issuing CA. With this trusted 1852 identifier, the SD query at TEE can be fast upon TAM signer 1853 verification. 1855 did - The SHA256 hash of the binary-encoded device TEE certificate. 1856 The encryption key CEK will be encrypted the recipient TEE's public 1857 key. This hash value in the "did" property allows the recipient 1858 TEE to check whether it is the expected target to receive such a 1859 request. If this isn't given, an OTrP message for device 2 could 1860 be sent to device 1. It is optional for the TEE to check because 1861 the successful decryption of the request message with this device's 1862 TEE private key already proves it is the target. This explicit 1863 hash value makes the protocol not dependent on message encryption 1864 method in future. 1866 A CreateSDTBSRequest message is signed to generate a final 1867 CreateSDRequest message as follows. 1869 { 1870 "CreateSDRequest": { 1871 "payload": "", 1872 "protected": "", 1873 "header": "", 1874 "signature": "" 1875 } 1876 } 1878 The TAM signer certificate is included in the "header" property. 1880 9.2.1.2. Request Processing Requirements at a TEE 1882 Upon receiving a CreateSDRequest request message at a TEE, the TEE 1883 MUST do the following: 1885 1. Validate the JSON request message as follows 1887 * Validate JSON message signing. 1889 * Validate that the request TAM certificate is chained to a 1890 trusted CA that the TEE embeds as its trust anchor. 1892 * Compare dsihash with its current state to make sure nothing 1893 has changed since this request was sent. 1895 * Decrypt to get the plaintext of the content: (a) spid, (b) sd 1896 name, (c) did. 1898 * Check that an SPID is supplied. 1900 * spcert check: check it is a valid certificate (signature and 1901 format verification only). 1903 * Check "did" is the SHA256 hash of its TEEcert BER raw binary 1904 data. 1906 * Check whether the requested SD already exists for the SP. 1908 * Check that the tamid in the request matches the TAM 1909 certificate's TAM ID attribute. 1911 2. If the request was valid, create action 1913 * Create an SD for the SP with the given name. 1915 * Assign the tamid from the TAMCert to this SD. 1917 * Assign the SPID and SPCert to this SD. 1919 * Check whether a TEE SP AIK key pair already exists for the 1920 given SP ID. 1922 * Create TEE SP AIK key pair if it doesn't exist for the given 1923 SP ID. 1925 * Generate new DSI data if the request asks for updated DSI. 1927 3. Construct a CreateSDResponse message 1928 * Create raw content 1930 + Operation status 1932 + "did" or full signer certificate information, 1934 + TEE SP AIK public key if DSI isn't going to be included 1936 + Updated DSI data if requested 1938 * The response message is encrypted with the same JWE CEK of the 1939 request without recreating a new content encryption key. 1941 * The encrypted message is signed with TEEpriv. The signer 1942 information ("did" or TEEcert) is encrypted. 1944 4. Deliver the response message. (a) The OTrP Broker returns this to 1945 the Client Application; (b) The Client App passes this back to 1946 the TAM. 1948 5. TAM processing. (a) The TAM processes the response message; (b) 1949 the TAM can look up signer certificate from the device ID "did". 1951 If a request is illegitimate or signature doesn't pass, a "status" 1952 property in the response will indicate the error code and cause. 1954 9.2.1.3. CreateSDResponse Message 1956 The response message for a CreateSDRequest contains the following 1957 content. 1959 { 1960 "CreateSDTBSResponse": { 1961 "ver": "1.0", 1962 "status": "", 1963 "rid": "", 1964 "tid": "", 1965 "content": ENCRYPTED { 1966 "reason": "", // optional 1967 "did": "", 1968 "sdname": "", 1969 "teespaik": "", 1970 "dsi": "" 1972 } 1973 } 1974 } 1975 In the response message, the following fields MUST be supplied. 1977 did - The SHA256 hash of the device TEE certificate. This shows 1978 the device ID explicitly to the receiving TAM. 1980 teespaik - The newly generated SP AIK public key for the given SP. 1981 This is an optional value if the device has had another domain for 1982 the SP that has triggered TEE SP AIK key pair for this specific SP. 1984 There is a possible extreme error case where the TEE isn't reachable 1985 or the TEE final response generation itself fails. In this case, the 1986 TAM might still receive a response from the OTrP Broker if the OTrP 1987 Broker is able to detect such error from TEE. In this case, a 1988 general error response message should be returned by the OTrP Broker, 1989 assuming OTrP Broker even doesn't know any content and information 1990 about the request message. 1992 In other words, the TAM should expect to receive a TEE successfully 1993 signed JSON message, a general "status" message, or none when a 1994 client experiences a network error. 1996 { 1997 "CreateSDResponse": { 1998 "payload": "", 1999 "protected": { 2000 "" 2001 }, 2002 "signature": "" 2004 } 2005 } 2007 A response message type "status" will be returned when the TEE fails 2008 to respond. The OTrP Broker is responsible to create this message. 2010 { 2011 "status": { 2012 "result": "fail", 2013 "error-code": "ERR_AGENT_TEE_FAIL", 2014 "error-message": "TEE fails to respond" 2015 } 2016 } 2018 9.2.1.4. Error Conditions 2020 An error might occur if a request isn't valid or the TEE runs into 2021 some error. The list of possible errors are as follows. Refer to 2022 the Error Code List (Section 13.1) for detailed causes and actions. 2024 ERR_AGENT_TEE_BUSY 2026 ERR_AGENT_TEE_FAIL 2028 ERR_AGENT_TEE_UNKNOWN 2030 ERR_REQUEST_INVALID 2032 ERR_UNSUPPORTED_MSG_VERSION 2034 ERR_UNSUPPORTED_CRYPTO_ALG 2036 ERR_DEV_STATE_MISMATCH 2038 ERR_SD_ALREADY_EXIST 2040 ERR_SD_NOT_FOUND 2042 ERR_SPCERT_INVALID 2044 ERR_TEE_FAIL 2046 ERR_TAM_NOT_AUTHORIZED 2048 ERR_TAM_NOT_TRUSTED 2050 9.2.2. UpdateSD 2052 This TAM initiated command can update an SP's SD that it manages for 2053 any of the following needs: (a) Update an SP signer certificate; (b) 2054 Add an SP signer certificate when an SP uses multiple to sign TA 2055 binaries; (c) Update an SP ID. 2057 The TAM presents the proof of the SD ownership to the TEE, and 2058 includes related information in its signed message. The entire 2059 request is also encrypted for end-to-end confidentiality. 2061 9.2.2.1. UpdateSDRequest Message 2062 The UpdateSD request message has the following JSON format. 2064 { 2065 "UpdateSDTBSRequest": { 2066 "ver": "1.0", 2067 "rid": "", 2068 "tid": "", // this may be from prior message 2069 "tee": "", 2070 "nextdsi": true | false, 2071 "dsihash": "", 2072 "content": ENCRYPTED { // this piece of JSON will be encrypted 2073 "tamid": "", 2074 "spid": "", 2075 "sdname": "", 2076 "changes": { 2077 "newsdname": "", 2078 // Optional 2079 "newspid": "", 2080 // Optional 2081 "spcert": [""], 2082 // Optional 2083 "deloldspcert": [""], 2085 // Optional 2086 "renewteespaik": true | false 2087 } 2088 } 2089 } 2090 } 2092 In the message, 2094 rid - A unique value to identify this request 2096 tid - A unique value to identify this transaction. It can have the 2097 same value as the tid in the preceding GetDeviceStateRequest. 2099 tee - TEE ID returned from the previous GetDeviceStateResponse 2101 nextdsi - Indicates whether the up-to-date Device State Information 2102 (DSI) is expected to be returned in the response from the TEE to 2103 this request. 2105 dsihash - The BASE64-encoded SHA256 hash value of the DSI data 2106 returned in the prior TAM operation with this target TEE. This 2107 value is always included such that a receiving TEE can check 2108 whether the device state has changed since its last query. It 2109 helps enforce SD update order in the right sequence without 2110 accidentally overwriting an update that was done simultaneously. 2112 content - The "content" is a JSON encrypted message that includes 2113 actual input for the SD update. The standard JSON content 2114 encryption key (CEK) is used, and the CEK is encrypted by the 2115 target TEE's public key. 2117 tamid - SD owner claim by TAM - an SD owned by a TAM will be 2118 associated with a trusted identifier defined as an attribute in the 2119 signer TAM certificate. 2121 spid - the identifier of the SP whose SD will be updated. This 2122 value is still needed because the SD name is considered unique only 2123 within an SP. 2125 sdname - the name of the target SD to be updated. 2127 changes - its content consists of changes are to be updated in the 2128 given SD. 2130 newsdname - the new name of the target SD to be assigned if this 2131 value is present. 2133 newspid - the new SP ID of the target SD to be assigned if this 2134 value is present. 2136 spcert - a new TA signer certificate of this SP to be added to the 2137 SD if this is present. 2139 deloldspcert - an SP certificate assigned into the SD is to be 2140 deleted if this is present. The value is the SHA256 fingerprint of 2141 the old SP certificate. 2143 renewteespaik - the value should be true or false. If it is present 2144 and the value is true, the TEE MUST regenerate TEE SP AIK for this 2145 SD's owner SP. The newly generated TEE SP AIK for the SP must be 2146 returned in the response message of this request. If there is more 2147 than one SD for the SP, a new SPID for one of the domains will 2148 always trigger a new teespaik generation as if a new SP were 2149 introduced to the TEE. 2151 The UpdateSDTBSRequest message is signed to generate the final 2152 UpdateSDRequest message. 2154 { 2155 "UpdateSDRequest": { 2156 "payload": "", 2157 "protected": "", 2158 "header": "", 2159 "signature":"" 2160 } 2161 } 2163 TAM signer certificate is included in the "header" property. 2165 9.2.2.2. Request Processing Requirements at a TEE 2167 Upon receiving a request message UpdateSDRequest at a TEE, the TEE 2168 must validate a request: 2170 1. Validate the JSON request message 2172 * Validate JSON message signing 2174 * Validate that the request TAM certificate is chained to a 2175 trusted CA that the TEE embeds as its trust anchor.The TAM 2176 certificate status check is generally not needed anymore in 2177 this request. The prior request should have validated the TAM 2178 certificate's revocation status. 2180 * Compare dsihash with the TEE cached last response DSI data to 2181 this TAM. 2183 * Decrypt to get the plaintext of the content. 2185 * Check that the target SD name is supplied. 2187 * Check whether the requested SD exists. 2189 * Check that the TAM owns this TAM by verifying tamid in the SD 2190 matches TAM certificate's TAM ID attribute. 2192 * Now the TEE is ready to carry out update listed in the 2193 "content" message. 2195 2. If the request is valid, update action 2197 * If "newsdname" is given, replace the SD name for the SD to the 2198 new value 2200 * If "newspid" is given, replace the SP ID assigned to this SD 2201 with the given new value 2203 * If "spcert" is given, add this new SP certificate to the SD. 2205 * If "deloldspcert" is present in the content, check previously 2206 assigned SP certificates to this SD, and delete the one that 2207 matches the given certificate hash value. 2209 * If "renewteespaik" is given and has a value of 'true', 2210 generate a new TEE SP AIK key pair, and replace the old one 2211 with this. 2213 * Generate new DSI data if the request asks for updated DSI 2215 * Now the TEE is ready to construct the response message 2217 3. Construct UpdateSDResponse message 2219 * Create raw content 2221 + Operation status 2223 + "did" or full signer certificate information, 2225 + TEE SP AIK public key if DSI isn't going to be included 2227 + Updated DSI data if requested 2229 * The response message is encrypted with the same JWE CEK of the 2230 request without recreating a new content encryption key. 2232 * The encrypted message is signed with TEEpriv. The signer 2233 information ("did" or TEEcert) is encrypted. 2235 4. Deliver response message. (a) The OTrP Broker returns this to the 2236 app; (b) The app passes this back to the TAM. 2238 5. TAM processing. (a) The TAM processes the response message; (b) 2239 The TAM can look up the signer certificate from the device ID 2240 "did". 2242 If a request is illegitimate or the signature doesn't pass, a 2243 "status" property in the response will indicate the error code and 2244 cause. 2246 9.2.2.3. UpdateSDResponse Message 2248 The response message for a UpdateSDRequest contains the following 2249 content. 2251 { 2252 "UpdateSDTBSResponse": { 2253 "ver": "1.0", 2254 "status": "", 2255 "rid": "", 2256 "tid": "", 2257 "content": ENCRYPTED { 2258 "reason": "", // optional 2259 "did": "", 2260 "cert": "", // optional 2261 "teespaik": "", 2262 "teespaiktype": "", 2263 "dsi": "" 2265 } 2266 } 2267 } 2269 In the response message, the following fields MUST be supplied. 2271 did - The request should have known the signer certificate of this 2272 device from a prior request. This hash value of the device TEE 2273 certificate serves as a quick identifier only. A full device 2274 certificate isn't necessary. 2276 teespaik - the newly generated SP AIK public key for the given SP 2277 if the TEE SP AIK for the SP is asked to be renewed in the request. 2278 This is an optional value if "dsi" is included in the response, 2279 which will contain all up-to-date TEE SP AIK key pairs. 2281 Similar to the template for the creation of the encrypted and signed 2282 CreateSDResponse, the final UpdateSDResponse looks like the 2283 following. 2285 { 2286 "UpdateSDResponse": { 2287 "payload": "", 2288 "protected": { 2289 "" 2290 }, 2291 "signature": "" 2293 } 2294 } 2296 A response message type "status" will be returned when the TEE fails 2297 to respond. The OTrP Broker is responsible to create this message. 2299 { 2300 "status": { 2301 "result": "fail", 2302 "error-code": "ERR_AGENT_TEE_FAIL", 2303 "error-message": "" 2304 } 2305 } 2307 9.2.2.4. Error Conditions 2309 An error may occur if a request isn't valid or the TEE runs into some 2310 error. The list of possible errors are as follows. Refer to the 2311 Error Code List (Section 13.1) for detailed causes and actions. 2313 ERR_AGENT_TEE_BUSY 2315 ERR_AGENT_TEE_FAIL 2317 ERR_AGENT_TEE_UNKNOWN 2319 ERR_REQUEST_INVALID 2321 ERR_UNSUPPORTED_MSG_VERSION 2323 ERR_UNSUPPORTED_CRYPTO_ALG 2325 ERR_DEV_STATE_MISMATCH 2327 ERR_SD_NOT_FOUND 2329 ERR_SDNAME_ALREADY_USED 2331 ERR_SPCERT_INVALID 2332 ERR_TEE_FAIL 2334 ERR_TAM_NOT_AUTHORIZED 2336 ERR_TAM_NOT_TRUSTED 2338 9.2.3. DeleteSD 2340 A TAM sends a DeleteSDRequest message to a TEE to delete a specified 2341 SD that it owns. An SD can be deleted only if there is no TA 2342 associated with this SD in the device. The request message can 2343 contain a flag to instruct the TEE to delete all related TAs in an SD 2344 and then delete the SD. 2346 The target TEE will operate with the following logic. 2348 1. Look up the given SD specified in the request message 2350 2. Check that the TAM owns the SD 2352 3. Check that the device state hasn't changed since the last 2353 operation 2355 4. Check whether there are TAs in this SD 2357 5. If TA exists in an SD, check whether the request instructs 2358 whether the TA should be deleted. If the request instructs the 2359 TEE to delete TAs, delete all TAs in this SD. If the request 2360 doesn't instruct the TEE to delete TAs, return an error 2361 "ERR_SD_NOT_EMPTY". 2363 6. Delete the SD 2365 7. If this is the last SD of this SP, delete the TEE SP AIK key. 2367 9.2.3.1. DeleteSDRequest Message 2368 The request message for DeleteSD has the following JSON format. 2370 { 2371 "DeleteSDTBSRequest": { 2372 "ver": "1.0", 2373 "rid": "", 2374 "tid": "", // this may be from prior message 2375 "tee": "", 2376 "nextdsi": true | false, 2377 "dsihash": "", 2378 "content": ENCRYPTED { // this piece of JSON will be encrypted 2379 "tamid": "", 2380 "sdname": "", 2381 "deleteta": true | false 2382 } 2383 } 2384 } 2386 In the message, 2388 rid - A unique value to identify this request 2390 tid - A unique value to identify this transaction. It can have the 2391 same value for the tid in the preceding GetDeviceStateRequest. 2393 tee - TEE ID returned from the previous response 2394 GetDeviceStateResponse 2396 nextdsi - Indicates whether the up-to-date Device State Information 2397 (DSI) is to be returned in the response to this request. 2399 dsihash - The BASE64-encoded SHA256 hash value of the DSI data 2400 returned in the prior TAM operation with this target TEE. This 2401 value is always included such that a receiving TEE can check 2402 whether the device state has changed since its last query. It 2403 helps enforce SD update order in the right sequence without 2404 accidentally overwriting an update that was done simultaneously. 2406 content - The "content" is a JSON encrypted message that includes 2407 actual input for the SD update. The standard JSON content 2408 encryption key (CEK) is used, and the CEK is encrypted by the 2409 target TEE's public key. 2411 tamid - SD owner claim by TAM - an SD owned by a TAM will be 2412 associated with a trusted identifier defined as an attribute in the 2413 signer TAM certificate. 2415 sdname - the name of the target SD to be updated. 2417 deleteta - the value should be boolean 'true' or 'false'. If it is 2418 present and the value is 'true', the TEE should delete all TAs 2419 associated with the SD in the device. 2421 According to the OTrP message template, the full request 2422 DeleteSDRequest is a signed message over the DeleteSDTBSRequest as 2423 follows. 2425 { 2426 "DeleteSDRequest": { 2427 "payload": "", 2428 "protected": "", 2429 "header": "", 2430 "signature": "" 2431 } 2432 } 2434 TAM signer certificate is included in the "header" property. 2436 9.2.3.2. Request Processing Requirements at a TEE 2438 Upon receiving a request message DeleteSDRequest at a TEE, the TEE 2439 must validate a request: 2441 1. Validate the JSON request message 2443 * Validate JSON message signing 2445 * Validate that the request TAM certificate is chained to a 2446 trusted CA that the TEE embeds as its trust anchor. The TAM 2447 certificate status check is generally not needed anymore in 2448 this request. The prior request should have validated the TAM 2449 certificate's revocation status. 2451 * Compare dsihash with the TEE cached last response DSI data to 2452 this TAM 2454 * Decrypt to get the plaintext of the content 2456 * Check that the target SD name is supplied 2458 * Check whether the requested SD exists 2460 * Check that the TAM owns this TAM by verifying that the tamid 2461 in the SD matches the TAM certificate's TAM ID attribute 2463 * Now the TEE is ready to carry out the update listed in the 2464 "content" message 2466 2. If the request is valid, deletion action 2468 * Check TA existence in this SD 2470 * If "deleteta" is "true", delete all TAs in this SD. If the 2471 value of "deleteta" is false and some TA exists, return an 2472 error "ERR_SD_NOT_EMPTY" 2474 * Delete the SD 2476 * Delete the TEE SP AIK key pair if this SD is the last one for 2477 the SP 2479 * Now the TEE is ready to construct the response message 2481 3. Construct a DeleteSDResponse message 2483 * Create response content 2485 + Operation status 2487 + "did" or full signer certificate information, 2489 + Updated DSI data if requested 2491 * The response message is encrypted with the same JWE CEK of the 2492 request without recreating a new content encryption key. 2494 * The encrypted message is signed with TEEpriv. The signer 2495 information ("did" or TEEcert) is encrypted. 2497 4. Deliver response message. (a) The OTrP Broker returns this to the 2498 app; (b) The app passes this back to the TAM 2500 5. TAM processing. (a) The TAM processes the response message; (b) 2501 The TAM can look up signer certificate from the device ID "did". 2503 If a request is illegitimate or the signature doesn't pass, a 2504 "status" property in the response will indicate the error code and 2505 cause. 2507 9.2.3.3. DeleteSDResponse Message 2509 The response message for a DeleteSDRequest contains the following 2510 content. 2512 { 2513 "DeleteSDTBSResponse": { 2514 "ver": "1.0", 2515 "status": "", 2516 "rid": "", 2517 "tid": "", 2518 "content": ENCRYPTED { 2519 "reason": "", // optional 2520 "did": "", 2521 "dsi": "" 2523 } 2524 } 2525 } 2527 In the response message, the following fields MUST be supplied. 2529 did - The request should have known the signer certificate of this 2530 device from a prior request. This hash value of the device TEE 2531 certificate serves as a quick identifier only. A full device 2532 certificate isn't necessary. 2534 The final DeleteSDResponse looks like the following. 2536 { 2537 "DeleteSDResponse": { 2538 "payload": "", 2539 "protected": { 2540 "" 2541 }, 2542 "signature": "" 2544 } 2545 } 2547 A response message type "status" will be returned when the TEE fails 2548 to respond. The OTrP Broker is responsible to create this message. 2550 { 2551 "status": { 2552 "result": "fail", 2553 "error-code": "ERR_AGENT_TEE_FAIL", 2554 "error-message": "TEE fails to respond" 2555 } 2556 } 2558 9.2.3.4. Error Conditions 2560 An error may occur if a request isn't valid or the TEE runs into some 2561 error. The list of possible errors is as follows. Refer to the 2562 Error Code List (Section 13.1) for detailed causes and actions. 2564 ERR_AGENT_TEE_BUSY 2566 ERR_AGENT_TEE_FAIL 2568 ERR_AGENT_TEE_UNKNOWN 2570 ERR_REQUEST_INVALID 2572 ERR_UNSUPPORTED_MSG_VERSION 2574 ERR_UNSUPPORTED_CRYPTO_ALG 2576 ERR_DEV_STATE_MISMATCH 2578 ERR_SD_NOT_EMPTY 2580 ERR_SD_NOT_FOUND 2582 ERR_TEE_FAIL 2584 ERR_TAM_NOT_AUTHORIZED 2586 ERR_TAM_NOT_TRUSTED 2588 9.3. Trusted Application Management 2590 This protocol doesn't introduce a TA container concept. All TA 2591 authorization and management will be up to the TEE implementation. 2593 The following three TA management commands are supported. 2595 o InstallTA - provision a TA by TAM 2597 o UpdateTA - update a TA by TAM 2599 o DeleteTA - remove TA registration information with an SD, remove 2600 the TA binary and all TA-related data in a TEE 2602 9.3.1. InstallTA 2604 TA binary data and related personalization data if there is any can 2605 be from two sources: 2607 1. A TAM supplies the signed and encrypted TA binary 2609 2. A Client Application supplies the TA binary 2611 This specification primarily considers the first case where a TAM 2612 supplies a TA binary. This is to ensure that a TEE can properly 2613 validate whether a TA is trustworthy. Further, TA personalization 2614 data will be encrypted by the TEE device's SP public key for end-to- 2615 end protection. A Client Application bundled TA case will be 2616 addressed separately later. 2618 A TAM sends the following information in a InstallTARequest message 2619 to a target TEE: 2621 o The target SD information: SP ID and SD name 2623 o Encrypted TA binary data. TA data is encrypted with the TEE SP 2624 AIK. 2626 o TA metadata. It is optional to include the SP signer certificate 2627 for the SD to add if the SP has changed signer since the SD was 2628 created. 2630 The TEE processes the command given by the TAM to install a TA into 2631 an SP's SD. It does the following: 2633 o Validation 2635 * The TEE validates the TAM message authenticity 2637 * Decrypt to get request content 2639 * Look up the SD with the SD name 2641 * Checks that the TAM owns the SD 2643 * Checks that the DSI hash matches which shows that the device 2644 state hasn't changed 2646 o If the request is valid, continue to do the TA validation 2648 * Decrypt to get the TA binary data and any personalization data 2649 with the "TEE SP AIK private key" 2651 * Check that SP ID is the one that is registered with the SP SD 2653 * Check that the TA signer is either a newly given SP certificate 2654 or the one that is already trusted by the SD from the previous 2655 TA installation. The TA signing method is specific to a TEE. 2656 This specification doesn't define how a TA should be signed; a 2657 TAM should support TEE specific TA signing when it supports 2658 that TEE. 2660 * If a TA signer is given in the request, add this signer into 2661 the SD. 2663 o If the above validation passed, continue to do TA installation 2665 * The TEE re-encrypts the TA binary and its personalization data 2666 with its own method. 2668 * The TEE enrolls and stores the TA in a secure storage. 2670 o Construct a response message. This involves signing encrypted 2671 status information for the requesting TAM. 2673 9.3.1.1. InstallTARequest Message 2674 The request message for InstallTA has the following JSON format. 2676 { 2677 "InstallTATBSRequest": { 2678 "ver": "1.0", 2679 "rid": "", 2680 "tid": "", 2681 "tee": "", 2682 "nextdsi": true | false, 2683 "dsihash": "", 2684 "content": ENCRYPTED { 2685 "tamid": "", 2686 "spid": "", 2687 "sdname": "", 2688 "spcert": "", // optional 2689 "taid": "" 2690 }, 2691 "encrypted_ta": { 2692 "key": "", 2694 "iv": "", 2695 "alg": "", 2697 "cipherpdata": "" 2699 } 2700 } 2701 } 2703 In the message, 2705 rid - A unique value to identify this request 2707 tid - A unique value to identify this transaction. It can have the 2708 same value for the tid in the preceding GetDeviceStateRequest. 2710 tee - TEE ID returned from the previous GetDeviceStateResponse 2712 nextdsi - Indicates whether the up-to-date Device State Information 2713 (DSI) is to be returned in the response to this request. 2715 dsihash - The BASE64-encoded SHA256 hash value of the DSI data 2716 returned in the prior TAM operation with this target TEE. This 2717 value is always included such that a receiving TEE can check 2718 whether the device state has changed since its last query. It 2719 helps enforce SD update order in the right sequence without 2720 accidentally overwriting an update that was done simultaneously. 2722 content - The "content" is a JSON encrypted message that includes 2723 actual input for the SD update. The standard JSON content 2724 encryption key (CEK) is used, and the CEK is encrypted by the 2725 target TEE's public key. 2727 tamid - SD owner claim by TAM - An SD owned by a TAM will be 2728 associated with a trusted identifier defined as an attribute in the 2729 signer TAM certificate. 2731 spid - SP identifier of the TA owner SP 2733 sdname - the name of the target SD where the TA is to be installed 2735 spcert - an optional field to specify the SP certificate that signed 2736 the TA. This is sent if the SP has a new certificate that hasn't 2737 been previously registered with the target SD where the TA should 2738 be installed. 2740 taid - the identifier of the TA application to be installed 2742 encrypted_ta - the message portion contains encrypted TA binary data 2743 and personalization data. The TA data encryption key is placed in 2744 "key", which is encrypted by the recipient's public key, using JWE 2745 enveloped structure. The TA data encryption uses symmetric key 2746 based encryption such as AESCBC. 2748 According to the OTrP message template, the full request 2749 InstallTARequest is a signed message over the InstallTATBSRequest as 2750 follows. 2752 { 2753 "InstallTARequest": { 2754 "payload": "", 2755 "protected": "", 2756 "header": "", 2757 "signature": "" 2758 } 2759 } 2761 9.3.1.2. InstallTAResponse Message 2763 The response message for a InstallTARequest contains the following 2764 content. 2766 { 2767 "InstallTATBSResponse": { 2768 "ver": "1.0", 2769 "status": "", 2770 "rid": "", 2771 "tid": "", 2772 "content": ENCRYPTED { 2773 "reason":"", // optional 2774 "did": "", 2775 "dsi": "" 2777 } 2778 } 2779 } 2781 In the response message, the following fields MUST be supplied. 2783 did - the SHA256 hash of the device TEE certificate. This shows 2784 the device ID explicitly to the receiving TAM. 2786 The final message InstallTAResponse looks like the following. 2788 { 2789 "InstallTAResponse": { 2790 "payload":"", 2791 "protected": { 2792 "" 2793 }, 2794 "signature": "" 2796 } 2797 } 2799 A response message type "status" will be returned when the TEE fails 2800 to respond. The OTrP Broker is responsible to create this message. 2802 { 2803 "status": { 2804 "result": "fail", 2805 "error-code": "ERR_AGENT_TEE_FAIL", 2806 "error-message": "TEE fails to respond" 2807 } 2808 } 2810 9.3.1.3. Error Conditions 2812 An error may occur if a request isn't valid or the TEE runs into some 2813 error. The list of possible errors are as follows. Refer to the 2814 Error Code List (Section 13.1) for detailed causes and actions. 2816 ERR_AGENT_TEE_BUSY 2818 ERR_AGENT_TEE_FAIL 2820 ERR_AGENT_TEE_UNKNOWN 2822 ERR_REQUEST_INVALID 2824 ERR_UNSUPPORTED_MSG_VERSION 2826 ERR_UNSUPPORTED_CRYPTO_ALG 2828 ERR_DEV_STATE_MISMATCH 2830 ERR_SD_NOT_FOUND 2832 ERR_TA_INVALID 2834 ERR_TA_ALREADY_INSTALLED 2836 ERR_TEE_FAIL 2838 ERR_TEE_RESOURCE_FULL 2840 ERR_TAM_NOT_AUTHORIZED 2842 ERR_TAM_NOT_TRUSTED 2844 9.3.2. UpdateTA 2846 This TAM-initiated command can update a TA and its data in an SP's SD 2847 that it manages for the following purposes. 2849 1. Update TA binary 2851 2. Update TA's personalization data 2853 The TAM presents the proof of the SD ownership to a TEE, and includes 2854 related information in its signed message. The entire request is 2855 also encrypted for end-to-end confidentiality. 2857 The TEE processes the command from the TAM to update the TA of an SP 2858 SD. It does the following: 2860 o Validation 2862 * The TEE validates the TAM message authenticity 2864 * Decrypt to get request content 2866 * Look up the SD with the SD name 2868 * Checks that the TAM owns the SD 2870 * Checks DSI hash matches that the device state hasn't changed 2872 o TA validation 2874 * Both TA binary and personalization data are optional, but at 2875 least one of them shall be present in the message 2877 * Decrypt to get the TA binary and any personalization data with 2878 the "TEE SP AIK private key" 2880 * Check that SP ID is the one that is registered with the SP SD 2882 * Check that the TA signer is either a newly given SP certificate 2883 or the one in SD. 2885 * If a TA signer is given in the request, add this signer into 2886 the SD. 2888 o If the above validation passes, continue to do TA update 2890 * The TEE re-encrypts the TA binary and its personalization data 2891 with its own method 2893 * The TEE replaces the existing TA binary and its personalization 2894 data with the new binary and data. 2896 o Construct a response message. This involves signing a encrypted 2897 status information for the requesting TAM. 2899 9.3.2.1. UpdateTARequest Message 2900 The request message for UpdateTA has the following JSON format. 2902 { 2903 "UpdateTATBSRequest": { 2904 "ver": "1.0", 2905 "rid": "", 2906 "tid": "", 2907 "tee": "", 2908 "nextdsi": true | false, 2909 "dsihash": "", 2910 "content": ENCRYPTED { 2911 "tamid": "", 2912 "spid": "", 2913 "sdname": "", 2914 "spcert": "", // optional 2915 "taid": "" 2916 }, 2917 "encrypted_ta": { 2918 "key": "", 2920 "iv": "", 2921 "alg": "", 2924 "ciphernewpdata": "" 2926 // optional 2927 } 2928 } 2929 } 2931 In the message, 2933 rid - A unique value to identify this request 2935 tid - A unique value to identify this transaction. It can have the 2936 same value for the tid in the preceding GetDeviceStateRequest. 2938 tee - TEE ID returned from the previous GetDeviceStateResponse 2940 nextdsi - Indicates whether the up-to-date Device State Information 2941 (DSI) is to be returned in the response to this request. 2943 dsihash - The BASE64-encoded SHA256 hash value of the DSI data 2944 returned in the prior TAM operation with this target TEE. This 2945 value is always included such that a receiving TEE can check 2946 whether the device state has changed since its last query. It 2947 helps enforce SD update order in the right sequence without 2948 accidentally overwriting an update that was done simultaneously. 2950 content - The "content" is a JSON encrypted message that includes 2951 actual input for the SD update. The standard JSON content 2952 encryption key (CEK) is used, and the CEK is encrypted by the 2953 target TEE's public key. 2955 tamid - SD owner claim by TAM - an SD owned by a TAM will be 2956 associated with a trusted identifier defined as an attribute in the 2957 signer TAM certificate. 2959 spid - SP identifier of the TA owner SP 2961 spcert - an optional field to specify the SP certificate that signed 2962 the TA. This is sent if the SP has a new certificate that hasn't 2963 been previously registered with the target SD where the TA is to be 2964 installed. 2966 sdname - the name of the target SD where the TA should be updated 2968 taid - an identifier for the TA application to be updated 2970 encrypted_ta - the message portion contains newly encrypted TA 2971 binary data and personalization data. 2973 According to the OTrP message template, the full request 2974 UpdateTARequest is a signed message over the UpdateTATBSRequest as 2975 follows. 2977 { 2978 "UpdateTARequest": { 2979 "payload": "", 2980 "protected": "", 2981 "header": "", 2982 "signature": "" 2983 } 2984 } 2986 9.3.2.2. UpdateTAResponse Message 2988 The response message for a UpdateTARequest contains the following 2989 content. 2991 { 2992 "UpdateTATBSResponse": { 2993 "ver": "1.0", 2994 "status": "", 2995 "rid": "", 2996 "tid": "", 2997 "content": ENCRYPTED { 2998 "reason": "", // optional 2999 "did": "", 3000 "dsi": "" 3002 } 3003 } 3004 } 3006 In the response message, the following fields MUST be supplied. 3008 did - the SHA256 hash of the device TEE certificate. This shows 3009 the device ID explicitly to the receiving TAM. 3011 The final message UpdateTAResponse looks like the following. 3013 { 3014 "UpdateTAResponse": { 3015 "payload":"", 3016 "protected": { 3017 "" 3018 }, 3019 "signature": "" 3021 } 3022 } 3024 A response message type "status" will be returned when the TEE fails 3025 to respond. The OTrP Broker is responsible to create this message. 3027 { 3028 "status": { 3029 "result": "fail", 3030 "error-code": "ERR_AGENT_TEE_FAIL", 3031 "error-message": "TEE fails to respond" 3032 } 3033 } 3035 9.3.2.3. Error Conditions 3037 An error may occur if a request isn't valid or the TEE runs into some 3038 error. The list of possible errors are as follows. Refer to the 3039 Error Code List (Section 13.1) for detailed causes and actions. 3041 ERR_AGENT_TEE_BUSY 3043 ERR_AGENT_TEE_FAIL 3045 ERR_AGENT_TEE_UNKNOWN 3047 ERR_REQUEST_INVALID 3049 ERR_UNSUPPORTED_MSG_VERSION 3051 ERR_UNSUPPORTED_CRYPTO_ALG 3053 ERR_DEV_STATE_MISMATCH 3055 ERR_SD_NOT_FOUND 3057 ERR_TA_INVALID 3059 ERR_TA_NOT_FOUND 3061 ERR_TEE_FAIL 3063 ERR_TAM_NOT_AUTHORIZED 3065 ERR_TAM_NOT_TRUSTED 3067 9.3.3. DeleteTA 3069 This operation defines OTrP messages that allow a TAM to instruct a 3070 TEE to delete a TA for an SP in a given SD. A TEE will delete a TA 3071 from an SD and also TA data in the TEE. A Client Application cannot 3072 directly access TEE or OTrP Broker to delete a TA. 3074 9.3.3.1. DeleteTARequest Message 3075 The request message for DeleteTA has the following JSON format. 3077 { 3078 "DeleteTATBSRequest": { 3079 "ver": "1.0", 3080 "rid": "", 3081 "tid": "", 3082 "tee": "", 3083 "nextdsi": true | false, 3084 "dsihash": "", 3085 "content": ENCRYPTED { 3086 "tamid": "", 3087 "sdname": "", 3088 "taid": "" 3090 } 3091 } 3092 } 3094 In the message, 3096 rid - A unique value to identify this request 3098 tid - A unique value to identify this transaction. It can have the 3099 same value for the tid in the preceding GetDeviceStateRequest. 3101 tee - The TEE ID returned from the previous GetDeviceStateResponse 3103 nextdsi - Indicates whether the up-to-date Device State Information 3104 (DSI) is to be returned in the response to this request. 3106 dsihash - The BASE64-encoded SHA256 hash value of the DSI data 3107 returned in the prior TAM operation with this target TEE. This 3108 value is always included such that a receiving TEE can check 3109 whether the device state has changed since its last query. It 3110 helps enforce SD update order in the right sequence without 3111 accidentally overwriting an update that was done simultaneously. 3113 content - The "content" is a JSON encrypted message that includes 3114 actual input for the SD update. The standard JSON content 3115 encryption key (CEK) is used, and the CEK is encrypted by the 3116 target TEE's public key. 3118 tamid - SD owner claim by TAM - an SD owned by a TAM will be 3119 associated with a trusted identifier defined as an attribute in the 3120 signer TAM certificate. 3122 sdname - the name of the target SD where the TA is installed 3123 taid - an identifier for the TA application to be deleted 3125 According to the OTrP message template, the full request 3126 DeleteTARequest is a signed message over the DeleteTATBSRequest as 3127 follows. 3129 { 3130 "DeleteTARequest": { 3131 "payload": "", 3132 "protected": "", 3133 "header": "", 3134 "signature": "" 3136 } 3137 } 3139 9.3.3.2. Request Processing Requirements at a TEE 3141 A TEE processes a command from a TAM to delete a TA of an SP SD. It 3142 does the following: 3144 1. Validate the JSON request message 3146 * The TEE validates TAM message authenticity 3148 * Decrypt to get request content 3150 * Look up the SD and the TA with the given SD name and TA ID 3152 * Checks that the TAM owns the SD, and TA is installed in the SD 3154 * Checks that the DSI hash matches and the the device state 3155 hasn't changed 3157 2. Deletion action 3159 * If all the above validation points pass, the TEE deletes the 3160 TA from the SD 3162 * The TEE SHOULD also delete all personalization data for the TA 3164 3. Construct DeleteTAResponse message. 3166 If a request is illegitimate or the signature doesn't pass, a 3167 "status" property in the response will indicate the error code and 3168 cause. 3170 9.3.3.3. DeleteTAResponse Message 3172 The response message for a DeleteTARequest contains the following 3173 content. 3175 { 3176 "DeleteTATBSResponse": { 3177 "ver": "1.0", 3178 "status": "", 3179 "rid": "", 3180 "tid": "", 3181 "content": ENCRYPTED { 3182 "reason": "", // optional 3183 "did": "", 3184 "dsi": "" 3186 } 3187 } 3188 } 3190 In the response message, the following fields MUST be supplied. 3192 did - the SHA256 hash of the device TEE certificate. This shows 3193 the device ID explicitly to the receiving TAM. 3195 The final message DeleteTAResponse looks like the following. 3197 { 3198 "DeleteTAResponse": { 3199 "payload": "", 3200 "protected": { 3201 "" 3202 }, 3203 "signature": "" 3205 } 3206 } 3208 A response message type "status" will be returned when the TEE fails 3209 to respond. The OTrP Broker is responsible to create this message. 3211 { 3212 "status": { 3213 "result": "fail", 3214 "error-code": "ERR_AGENT_TEE_FAIL", 3215 "error-message": "TEE fails to respond" 3216 } 3217 } 3219 9.3.3.4. Error Conditions 3221 An error may occur if a request isn't valid or the TEE runs into some 3222 error. The list of possible errors are as follows. Refer to the 3223 Error Code List (Section 13.1) for detailed causes and actions. 3225 ERR_AGENT_TEE_BUSY 3227 ERR_AGENT_TEE_FAIL 3229 ERR_AGENT_TEE_UNKNOWN 3231 ERR_REQUEST_INVALID 3233 ERR_UNSUPPORTED_MSG_VERSION 3235 ERR_UNSUPPORTED_CRYPTO_ALG 3237 ERR_DEV_STATE_MISMATCH 3239 ERR_SD_NOT_FOUND 3241 ERR_TA_NOT_FOUND 3243 ERR_TEE_FAIL 3245 ERR_TAM_NOT_AUTHORIZED 3247 ERR_TAM_NOT_TRUSTED 3249 10. Response Messages a TAM May Expect 3251 A TAM expects some feedback from a remote device when a request 3252 message is delivered to a device. The following three types of 3253 responses SHOULD be supplied. 3255 Type 1: Expect a valid TEE-generated response message 3257 A valid TEE signed response may contain errors detected by a TEE, 3258 e.g. a TAM is trusted but some TAM-supplied data is missing, for 3259 example, SP ID doesn't exist. TEE MUST be able to sign and 3260 encrypt. 3262 If a TEE isn't able to sign a response, the TEE returns an error 3263 to the OTrP Broker without giving any other internal information. 3264 The OTrP Broker will be generating the response. 3266 Type 2: The OTrP Broker generated error message when TEE fails. 3267 OTrP Broker errors will be defined in this document. 3269 A Type 2 message has the following format. 3271 { 3272 "OTrPBrokerError": { 3273 "ver": "1.0", 3274 "rid": "", 3275 "tid": "", 3276 "errcode": "ERR_AGENT_TEE_UNKNOWN | ERR_AGENT_TEE_BUSY" 3277 } 3278 } 3280 Type 3: OTrP Broker itself isn't reachable or fails. A Client 3281 Application is responsible to handle error and respond the TAM in 3282 its own way. This is out of scope for this specification. 3284 11. Basic Protocol Profile 3286 This section describes a baseline for interoperability among the 3287 protocol entities, mainly, the TAM and TEE. 3289 A TEE MUST support RSA algorithms. It is optional to support ECC 3290 algorithms. A TAM SHOULD use a RSA certificate for TAM message 3291 signing. It may use an ECC certificate if it detects that the TEE 3292 supports ECC according to the field "supportedsigalgs" in a TEE 3293 response. 3295 A TAM MUST support both RSA 2048-bit algorithm and ECC P-256 3296 algorithms. With this, a TEE and TFW certificate can be either RSA 3297 or ECC type. 3299 JSON signing algorithms 3301 o RSA PKCS#1 with SHA256 signing : "RS256" 3303 o ECDSA with SHA256 signing : "ES256" 3305 JSON asymmetric encryption algorithms (describes key-exchange or key- 3306 agreement algorithm for sharing symmetric key with TEE): 3308 o RSA PKCS#1 : "RSA1_5" 3310 o ECDH using TEE ECC P-256 key and ephemeral ECC key generated by 3311 TAM : "ECDH-ES+A128W" 3313 JSON symmetric encryption algorithms (describes symmetric algorithm 3314 for encrypting body of data, using symmetric key transferred to TEE 3315 using asymmetric encryption): 3317 o Authenticated encryption AES 128 CBC with SHA256 : 3318 {"enc":"A128CBC-HS256"} 3320 12. Attestation Implementation Consideration 3322 It is important to know that the state of a device is appropriate 3323 before trusting that a device is what it says it is. The attestation 3324 scheme for OTrP must also be able to cope with different TEEs, 3325 including those that are OTrP compliant and those that use another 3326 mechanism. In the initial version, only one active TEE is assumed. 3328 It is out of scope how the TAM and the device implement the trust 3329 hierarchy verification. However, it is helpful to understand what 3330 each system provider should do in order to properly implement an OTrP 3331 trust hierarchy. 3333 In this section, we provide some implementation reference 3334 consideration. 3336 12.1. OTrP Trusted Firmware 3338 12.1.1. Attestation signer 3340 It is proposed that attestation for OTrP is based on the TFW layer, 3341 and that further attestation is not performed within the TEE itself 3342 during Security Domain operations. The rationale is that the device 3343 boot process will be defined to start with a secure bootloader 3344 protected with a harden key in eFUSE. The process releases 3345 attestation signing capabilities into the TFW once a trust boot has 3346 been established. In this way the release of the attestation signer 3347 can be considered the first "platform configuration metric", using 3348 Trust Computing Group (TCG) terminology. 3350 12.1.2. TFW Initial Requirements 3352 R1 The TFW must be possible for verification during boot 3354 R2 The TFW must allow a public / private key pair to be generated 3355 during device manufacture 3357 R3 The public key and certificate must be possible to store securely 3359 R4 The private key must be possible to store encrypted at rest 3361 R5 The private key must only be visible to the TFW when it is 3362 decrypted 3364 R6 The TFW must be able to read a list of root and intermediate 3365 certificates that it can use to check certificate chains with. 3366 The list must be stored such that it cannot be tampered with 3368 R7 Need to allow a TEE to access its unique TEE specific private key 3370 12.2. TEE Loading 3372 During boot, the TFW is required to start all of the root TEEs. 3373 Before loading them, the TFW must first determine whether the code 3374 sign signature of the TEE is valid. If TEE integrity is confirmed, 3375 the TEE may be started. The TFW must then be able to receive the 3376 identity certificate from the TEE (if that TEE is OTrP compliant). 3377 The identity certificate and keys will need to be baked into the TEE 3378 image, and therefore also covered by the code signer hash during the 3379 manufacturing process. The private key for the identity certificate 3380 must be securely protected. The private key for a TEE identity must 3381 never be released no matter how the public key and certificate are 3382 released to the TFW. 3384 Once the TFW has successfully booted a TEE and retrieved the identity 3385 certificate, the TFW will commit this to the platform configuration 3386 register (PCR) set, for later use during attestation. At minimum, 3387 the following data must be committed to the PCR for each TEE: 3389 1. Public key and certificate for the TEE 3391 2. TEE identifier that can be used later by a TAM to identify this 3392 TEE 3394 12.3. Attestation Hierarchy 3396 The attestation hierarchy and seed required for TAM protocol 3397 operation must be built into the device at manufacture. Additional 3398 TEEs can be added post-manufacture using the scheme proposed, but it 3399 is outside of the current scope of this document to detail that. 3401 It should be noted that the attestation scheme described is based on 3402 signatures. The only decryption that may take place is through the 3403 use of a bootloader key. 3405 12.3.1. Attestation Hierarchy Establishment: Manufacture 3407 During manufacture the following steps are required: 3409 1. A device-specific TFW key pair and certificate are burnt into the 3410 device. This key pair will be used for signing operations 3411 performed by the TFW. 3413 2. TEE images are loaded and include a TEE instance-specific key 3414 pair and certificate. The key pair and certificate are included 3415 in the image and covered by the code signing hash. 3417 3. The process for TEE images is repeated for any subordinate TEEs, 3418 which are additional TEEs after the root TEE that some devices 3419 have. 3421 12.3.2. Attestation Hierarchy Establishment: Device Boot 3423 During device boot the following steps are required: 3425 1. The boot module releases the TFW private key by decrypting it 3426 with the bootloader key. 3428 2. The TFW verifies the code-signing signature of the active TEE and 3429 places its TEE public key into a signing buffer, along with its 3430 identifier for later access. For a non-OTrP TEE, the TFW leaves 3431 the TEE public key field blank. 3433 3. The TFW signs the signing buffer with the TFW private key. 3435 4. Each active TEE performs the same operation as the TFW, building 3436 up their own signed buffer containing subordinate TEE 3437 information. 3439 12.3.3. Attestation Hierarchy Establishment: TAM 3441 Before a TAM can begin operation in the marketplace to support 3442 devices of a given TEE, it must obtain a TAM certificate from a CA 3443 that is registered in the trust store of devices with that TEE. In 3444 this way, the TEE can check the intermediate and root CA and verify 3445 that it trusts this TAM to perform operations on the TEE. 3447 13. IANA Considerations 3449 The error code listed in the next section will be registered. 3451 13.1. Error Code List 3453 This section lists error codes that could be reported by a TA or TEE 3454 in a device in responding to a TAM request, and a separate list that 3455 OTrP Broker may return when the TEE fails to respond. 3457 13.1.1. TEE Signed Error Code List 3459 ERR_DEV_STATE_MISMATCH - A TEE will return this error code if the 3460 DSI hash value from TAM doesn't match the has value of the device's 3461 current DSI. 3463 ERR_SD_ALREADY_EXISTS - This error will occur if an SD to be created 3464 already exists in the TEE. 3466 ERR_SD_NOT_EMPTY - This is reported if a target SD isn't empty. 3468 ERR_SDNAME_ALREADY_USED A TEE will return this error code if the new 3469 SD name already exists in the TEE. 3471 ERR_REQUEST_INVALID - This error will occur if the TEE meets any of 3472 the following conditions with a request message: (1) The request 3473 from a TAM has an invalid message structure; mandatory information 3474 is absent in the message. undefined member or structure is 3475 included. (2) TEE fails to verify signature of the message or 3476 fails to decrypt its contents. 3478 ERR_SPCERT_INVALID - If a new SP certificate for the SD to be 3479 updated is not valid, then the TEE will return this error code. 3481 ERR_TA_ALREADY_INSTALLED - While installing a TA, a TEE will return 3482 this error if the TA has already been installed in the SD. 3484 ERR_TA_INVALID - This error will occur when a TEE meets any of 3485 following conditions while checking validity of TA: (1) The TA 3486 binary has a format that the TEE can't recognize. (2) The TEE fails 3487 to decrypt the encoding of the TA binary and personalization data. 3488 (3) If an SP isn't registered with the SP SD where the TA will be 3489 installed. 3491 ERR_TA_NOT_FOUND - This error will occur when the target TA doesn't 3492 exist in the SD. 3494 ERR_TEE_FAIL - If the TEE fails to process a request because of an 3495 internal error, it will return this error code. 3497 ERR_TEE_RESOURCE_FULL - This error is reported when a device 3498 resource isn't available anymore such as storage space is full. 3500 ERR_TFW_NOT_TRUSTED - A TEE is responsible for determining that the 3501 underlying device firmware is trustworthy. If the TEE determines 3502 the TFW is not trustworthy, then this error will occur. 3504 ERR_TAM_NOT_TRUSTED - Before processing a request, a TEE needs to 3505 make sure whether the sender TAM is trustworthy by checking the 3506 validity of the TAM certificate, etc. If the TEE finds that the 3507 TAM is not trustworthy, then it will return this error code. 3509 ERR_UNSUPPORTED_CRYPTO_ALG - This error will occur if a TEE receives 3510 a request message encoded with cryptographic algorithms that the 3511 TEE doesn't support. 3513 ERR_UNSUPPORTED_MSG_VERSION - This error will occur if a TEE 3514 receives a message version that the TEE can't deal with. 3516 13.1.2. OTrP Broker Error Code List 3518 ERR_AGENT_TEE_UNKNOWN - This error will occur if the receiver TEE is 3519 not supposed to receive the request. That will be determined by 3520 checking the TEE name or device id in the request message. 3522 ERR_AGENT_TEE_BUSY - The device TEE is busy. The request can be 3523 generally sent again to retry. 3525 ERR_AGENT_TEE_FAIL - The TEE fails to respond to a TAM request. The 3526 OTrP Broker will construct an error message in responding to the 3527 TAM's request. 3529 14. Security Consideration 3531 14.1. Cryptographic Strength 3533 The strength of the cryptographic algorithms, using the measure of 3534 'bits of security' defined in NIST SP800-57 allowed for OTrP is: 3536 o At a minimum, 112 bits of security. The limiting factor for this 3537 is the RSA-2048 algorithm, which is indicated as providing 112 3538 bits of symmetric key strength in SP800-57. It is important that 3539 RSA is supported in order to enhance the interoperability of the 3540 protocol. 3542 o The option exists to choose algorithms providing 128 bits of 3543 security. This requires using TEE devices that support ECC P256. 3545 The available algorithms and key sizes specified in this document are 3546 based on industry standards. Over time the recommended or allowed 3547 cryptographic algorithms may change. It is important that the OTrP 3548 allows for crypto-agility. In this specification, TAM and TEE can 3549 negotiate an agreed upon algorithm where both include their supported 3550 algorithm in OTrP message. 3552 14.2. Message Security 3554 OTrP messages between the TAM and TEE are protected by message 3555 security using JWS and JWE. The 'Basic protocol profile' section of 3556 this document describes the algorithms used for this. All OTrP TEE 3557 devices and OTrP TAMs must meet the requirements of the basic 3558 profile. In the future additional 'profiles' can be added. 3560 PKI is used to ensure that the TEE will only communicate with a 3561 trusted TAM, and to ensure that the TAM will only communicate with a 3562 trusted TEE. 3564 14.3. TEE Attestation 3566 It is important that the TAM can trust that it is talking to a 3567 trusted TEE. This is achieved through attestation. The TEE has a 3568 private key and certificate built into it at manufacture, which is 3569 used to sign data supplied by the TAM. This allows the TAM to verify 3570 that the TEE is trusted. 3572 It is also important that the TFW (trusted firmware) can be checked. 3573 The TFW has a private key and certificate built into it at 3574 manufacture, which allows the TEE to check that that the TFW is 3575 trusted. 3577 The GetDeviceState message therefore allows the TAM to check that it 3578 trusts the TEE, and the TEE at this point will check whether it 3579 trusts the TFW. 3581 14.4. TA Protection 3583 A TA will be delivered in an encrypted form. This encryption is an 3584 additional layer within the message encryption described in the 3585 Section 11 of this document. The TA binary is encrypted for each 3586 target device with the device's TEE SP AIK public key. A TAM can 3587 either do this encryption itself or provide the TEE SP AIK public key 3588 to an SP such that the SP encrypts the encrypted TA for distribution 3589 to the TEE. 3591 The encryption algorithm can use a random AES 256 key "taek" with a 3592 16 byte random IV, and the "taek" is encrypted by the "TEE SP AIK 3593 public key". The following encrypted TA data structure is expected 3594 by a TEE: 3596 "encrypted_ta_bin": { 3597 "key": "", 3599 "iv": ", 3600 "alg": "AESCBC", 3601 "cipherdata": "" 3602 } 3604 14.5. TA Personalization Data 3606 An SP or TAM can supply personalization data for a TA to initialize 3607 for a device. Such data is passed through an InstallTA command from 3608 a TAM. The personalization data itself is (or can be) opaque to the 3609 TAM. The data can be from the SP without being revealed to the TAM. 3610 The data is sent in an encrypted manner in a request to a device such 3611 that only the device can decrypt. A device's TEE SP AIK public key 3612 for an SP is used to encrypt the data. Here JWE enveloping is used 3613 to carry all encryption key parameters along with encrypted data. 3615 "encrypted_ta_data": { // "TA personalization data" 3616 "key": "", 3618 "iv": "", 3619 "alg": "AESCBC", 3620 "cipherdata": "" 3622 } 3624 14.6. TA Trust Check at TEE 3626 A TA binary is signed by a TA signer certificate. This TA signing 3627 certificate/private key belongs to the SP, and may be self-signed 3628 (i.e., it need not participate in a trust hierarchy). It is the 3629 responsibility of the TAM to only allow verified TAs from trusted SPs 3630 into the system. Delivery of that TA to the TEE is then the 3631 responsibility of the TEE, using the security mechanisms provided by 3632 the OTrP. 3634 We allow a way for an (untrusted) application to check the 3635 trustworthiness of a TA. OTrP Broker has a function to allow a 3636 Client Application to query the information about a TA. 3638 An application in the Rich O/S may perform verification of the TA by 3639 verifying the signature of the TA. The GetTAInformation function is 3640 available to return the TEE supplied TA signer and TAM signer 3641 information to the application. An application can do additional 3642 trust checks on the certificate returned for this TA. It might trust 3643 the TAM, or require additional SP signer trust chaining. 3645 14.7. One TA Multiple SP Case 3647 A TA for multiple SPs must have a different identifier per SP. A TA 3648 will be installed in a different SD for each respective SP. 3650 14.8. OTrP Broker Trust Model 3652 An OTrP Broker could be malware in the vulnerable REE. A Client 3653 Application will connect its TAM provider for required TA 3654 installation. It gets command messages from the TAM, and passes the 3655 message to the OTrP Broker. 3657 The OTrP is a conduit for enabling the TAM to communicate with the 3658 device's TEE to manage SDs and TAs. All TAM messages are signed and 3659 sensitive data is encrypted such that the OTrP Broker cannot modify 3660 or capture sensitive data. 3662 14.9. OCSP Stapling Data for TAM Signed Messages 3664 The GetDeviceStateRequest message from a TAM to a TEE shall include 3665 OCSP stapling data for the TAM's signer certificate and for 3666 intermediate CA certificates up to the root certificate so that the 3667 TEE can verify the signer certificate's revocation status. 3669 A certificate revocation status check on a TA signer certificate is 3670 OPTIONAL by a TEE. A TAM is responsible for vetting a TA and the SP 3671 before it distributes them to devices. A TEE will trust a TA signer 3672 certificate's validation status done by a TAM when it trusts the TAM. 3674 14.10. Data Protection at TAM and TEE 3676 The TEE implementation provides protection of data on the device. It 3677 is the responsibility of the TAM to protect data on its servers. 3679 14.11. Privacy Consideration 3681 Devices are issued with a unique TEE certificate to attest the 3682 device's validity. This uniqueness also creates a privacy and 3683 tracking risk that must be mitigated. 3685 The TEE will only release the TEE certificate to a trusted TAM (it 3686 must verify the TAM certificate before proceeding). OTrP is designed 3687 such that only a TAM can obtain the TEE device certificate and 3688 firmware certificate - the GetDeviceState message requires signature 3689 checks to validate the TAM is trusted, and OTrP delivers the device's 3690 certificate(s) encrypted such that only that TAM can decrypt the 3691 response. A Client Application will never see the device 3692 certificate. 3694 An SP-specific TEE SP AIK (TEE SP Anonymous Key) is generated by the 3695 protocol for Client Applications. This provides a way for the Client 3696 Application to validate some data that the TEE may send without 3697 requiring the TEE device certificate to be released to the client 3698 device rich O/S , and to optionally allow an SP to encrypt a TA for a 3699 target device without the SP needing to be supplied with the TEE 3700 device certificate. 3702 14.12. Threat Mitigation 3704 A rogue application may perform excessive TA loading. An OTrP Broker 3705 implementation should protect against excessive calls. 3707 Rogue applications might request excessive SD creation. The TAM is 3708 responsible to ensure this is properly guarded against. 3710 Rogue OTrP Broker could replay or send TAM messages out of sequence: 3711 e.g., a TAM sends update1 and update2. The OTrP Broker replays 3712 update2 and update1 again, creating an unexpected result that a 3713 client wants. "dsihash" is used to mitigate this. The TEE MUST store 3714 DSI state and check that the DSI state matches before it does another 3715 update. 3717 Concurrent calls from a TAM to a TEE MUST be handled properly by a 3718 TEE. If multiple concurrent TAM operations take place, these could 3719 fail due to the "dsihash" being modified by another concurrent 3720 operation. The TEE is responsible for resolve any locking such that 3721 one application cannot lock other applications from using the TEE, 3722 except for a short term duration of the TAM operation taking place. 3723 For example, an OTrP operation that starts but never completes (e.g. 3724 loss of connectivity) must not prevent subsequent OTrP messages from 3725 being executed. 3727 14.13. Compromised CA 3729 A root CA for TAM certificates might get compromised. Some TEE trust 3730 anchor update mechanism is expected from device OEMs. A compromised 3731 intermediate CA is covered by OCSP stapling and OCSP validation check 3732 in the protocol. A TEE should validate certificate revocation about 3733 a TAM certificate chain. 3735 If the root CA of some TEE device certificates is compromised, these 3736 devices might be rejected by a TAM, which is a decision of the TAM 3737 implementation and policy choice. Any intermediate CA for TEE device 3738 certificates SHOULD be validated by TAM with a Certificate Revocation 3739 List (CRL) or Online Certificate Status Protocol (OCSP) method. 3741 14.14. Compromised TAM 3743 The TEE SHOULD use validation of the supplied TAM certificates and 3744 OCSP stapled data to validate that the TAM is trustworthy. 3746 Since PKI is used, the integrity of the clock within the TEE 3747 determines the ability of the TEE to reject an expired TAM 3748 certificate, or revoked TAM certificate. Since OCSP stapling 3749 includes signature generation time, certificate validity dates are 3750 compared to the current time. 3752 14.15. Certificate Renewal 3754 TFW and TEE device certificates are expected to be long lived, longer 3755 than the lifetime of a device. A TAM certificate usually has a 3756 moderate lifetime of 2 to 5 years. A TAM should get renewed or 3757 rekeyed certificates. The root CA certificates for a TAM, which are 3758 embedded into the trust anchor store in a device, should have long 3759 lifetimes that don't require device trust anchor update. On the 3760 other hand, it is imperative that OEMs or device providers plan for 3761 support of trust anchor update in their shipped devices. 3763 15. Acknowledgements 3765 We thank Alin Mutu for his contribution to many discussion that 3766 helped to design the trust flow mechanisms, and the creation of the 3767 flow diagrams. We also thank the following people (in alphabetical 3768 order) for their input and review: Sangsu Baek, Rob Coombs, Dapeng 3769 Liu, Dave Thaler, and Pengfei Zhao. 3771 16. References 3773 16.1. Normative References 3775 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3776 Requirement Levels", BCP 14, RFC 2119, 3777 DOI 10.17487/RFC2119, March 1997, . 3780 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 3781 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 3782 . 3784 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 3785 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 3786 2015, . 3788 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 3789 RFC 7516, DOI 10.17487/RFC7516, May 2015, 3790 . 3792 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 3793 DOI 10.17487/RFC7517, May 2015, . 3796 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 3797 DOI 10.17487/RFC7518, May 2015, . 3800 [TEEPArch] 3801 Pei, M., Tschofenig, H., Atyeo, A., and D. Liu, "Trusted 3802 Execution Environment Provisioning (TEEP) Architecture", 3803 2018, . 3806 16.2. Informative References 3808 [GPTEE] Global Platform, "Global Platform, GlobalPlatform Device 3809 Technology: TEE System Architecture, v1.0", 2013. 3811 [GPTEECLAPI] 3812 Global Platform, "Global Platform, GlobalPlatform Device 3813 Technology: TEE Client API Specification, v1.0", 2013. 3815 Appendix A. Sample Messages 3817 A.1. Sample Security Domain Management Messages 3819 A.1.1. Sample GetDeviceState 3821 A.1.1.1. Sample GetDeviceStateRequest 3823 The TAM builds a "GetDeviceStateTBSRequest" message. 3825 { 3826 "GetDeviceStateTBSRequest": { 3827 "ver": "1.0", 3828 "rid": "8C6F9DBB-FC39-435c-BC89-4D3614DA2F0B", 3829 "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE", 3830 "ocspdat": "c2FtcGxlIG9jc3BkYXQgQjY0IGVuY29kZWQgQVNOMQ==", 3831 "icaocspdat": "c2FtcGxlIGljYW9jc3BkYXQgQjY0IGVuY29kZWQgQVNOMQ==", 3832 "supportedsigalgs": "RS256" 3833 } 3834 } 3836 The TAM signs "GetDeviceStateTBSRequest", creating 3837 "GetDeviceStateRequest" 3839 { 3840 "GetDeviceStateRequest": { 3841 "payload":" 3842 ewoJIkdldERldmljZVN0YXRlVEJTUmVxdWVzdCI6IHsKCQkidmVyIjogIjEuMCIsCgkJ 3843 InJpZCI6IHs4QzZGOURCQi1GQzM5LTQzNWMtQkM4OS00RDM2MTREQTJGMEJ9LAoJCSJ0 3844 aWQiOiAiezRGNDU0QTdGLTAwMkQtNDE1Ny04ODRFLUIwREQxQTA2QThBRX0iLAoJCSJv 3845 Y3NwZGF0IjogImMyRnRjR3hsSUc5amMzQmtZWFFnUWpZMElHVnVZMjlrWldRZ1FWTk9N 3846 UT09IiwKCQkiaWNhb2NzcGRhdCI6ICJjMkZ0Y0d4bElHbGpZVzlqYzNCa1lYUWdRalkw 3847 SUdWdVkyOWtaV1FnUVZOT01RPT0iLAoJCSJzdXBwb3J0ZWRzaWdhbGdzIjogIlJTMjU2 3848 IgoJfQp9", 3849 "protected": "eyJhbGciOiJSUzI1NiJ9", 3850 "header": { 3851 "x5c": ["ZXhhbXBsZSBBU04xIHNpZ25lciBjZXJ0aWZpY2F0ZQ==", 3852 "ZXhhbXBsZSBBU04xIENBIGNlcnRpZmljYXRl"] 3853 }, 3854 "signature":"c2FtcGxlIHNpZ25hdHVyZQ" 3855 } 3856 } 3858 A.1.1.2. Sample GetDeviceStateResponse 3860 The TAM sends "GetDeviceStateRequest" to the OTrP Broker 3862 The OTrP Broker obtains "dsi" from each TEE. (In this example there 3863 is a single TEE.) 3865 The TEE obtains signed "fwdata" from firmware. 3867 The TEE builds "dsi" - summarizing device state of the TEE. 3869 { 3870 "dsi": { 3871 "tfwdata": { 3872 "tbs": "ezRGNDU0QTdGLTAwMkQtNDE1Ny04ODRFLUIwREQxQTA2QThBRX0=", 3873 "cert": "ZXhhbXBsZSBGVyBjZXJ0aWZpY2F0ZQ==", 3874 "sigalg": "RS256", 3875 "sig": "c2FtcGxlIEZXIHNpZ25hdHVyZQ==" 3876 }, 3877 "tee": { 3878 "name": "Primary TEE", 3879 "ver": "1.0", 3880 "cert": "c2FtcGxlIFRFRSBjZXJ0aWZpY2F0ZQ==", 3881 "cacert": [ 3882 "c2FtcGxlIENBIGNlcnRpZmljYXRlIDE=", 3883 "c2FtcGxlIENBIGNlcnRpZmljYXRlIDI=" 3884 ], 3885 "sdlist": { 3886 "cnt": "1", 3887 "sd": [ 3888 { 3889 "name": "default.acmebank.com", 3890 "spid": "acmebank.com", 3891 "talist": [ 3892 { 3893 "taid": "acmebank.secure.banking", 3894 "taname": "Acme secure banking app" 3895 }, 3896 { 3897 "taid": "acmebank.loyalty.rewards", 3898 "taname": "Acme loyalty rewards app" 3899 } 3900 ] 3901 } 3902 ] 3903 }, 3904 "teeaiklist": [ 3905 { 3906 "spaik": "c2FtcGxlIEFTTjEgZW5jb2RlZCBQS0NTMSBwdWJsaWNrZXk=", 3907 "spaiktype": "RSA", 3908 "spid": "acmebank.com" 3909 } 3910 ] 3911 } 3912 } 3913 } 3915 The TEE encrypts "dsi", and embeds it into a 3916 "GetDeviceTEEStateTBSResponse" message. 3918 { 3919 "GetDeviceTEEStateTBSResponse": { 3920 "ver": "1.0", 3921 "status": "pass", 3922 "rid": "{8C6F9DBB-FC39-435c-BC89-4D3614DA2F0B}", 3923 "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}", 3924 "signerreq":"false", 3925 "edsi": { 3926 "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0K", 3927 "recipients": [ 3928 { 3929 "header": { 3930 "alg": "RSA1_5" 3931 }, 3932 "encrypted_key": 3933 " 3934 QUVTMTI4IChDRUspIGtleSwgZW5jcnlwdGVkIHdpdGggVFNNIFJTQSBwdWJsaWMg 3935 a2V5LCB1c2luZyBSU0ExXzUgcGFkZGluZw" 3936 } 3937 ], 3938 "iv": "ySGmfZ69YlcEilNr5_SGbA", 3939 "ciphertext": 3940 " 3941 c2FtcGxlIGRzaSBkYXRhIGVuY3J5cHRlZCB3aXRoIEFFUzEyOCBrZXkgZnJvbSByZW 3942 NpcGllbnRzLmVuY3J5cHRlZF9rZXk", 3943 "tag": "c2FtcGxlIGF1dGhlbnRpY2F0aW9uIHRhZw" 3944 } 3945 } 3946 } 3948 The TEE signs "GetDeviceTEEStateTBSResponse" and returns it to the 3949 OTrP Broker. The OTrP Broker encodes "GetDeviceTEEStateResponse" 3950 into an array to form "GetDeviceStateResponse". 3952 { 3953 "GetDeviceStateResponse": [ 3954 { 3955 "GetDeviceTEEStateResponse": { 3956 "payload": 3957 " 3958 ewogICJHZXREZXZpY2VURUVTdGF0ZVRCU1Jlc3BvbnNlIjogewogICAgInZlciI6 3959 ICIxLjAiLAogICAgInN0YXR1cyI6ICJwYXNzIiwKICAgICJyaWQiOiAiezhDNkY5 3960 REJCLUZDMzktNDM1Yy1CQzg5LTREMzYxNERBMkYwQn0iLAogICAgInRpZCI6ICJ7 3961 NEY0NTRBN0YtMDAyRC00MTU3LTg4NEUtQjBERDFBMDZBOEFFfSIsCgkic2lnbmVy 3962 cmVxIjoiZmFsc2UiLAogICAgImVkc2kiOiB7CiAgICAgICJwcm90ZWN0ZWQiOiAi 3963 ZXlKbGJtTWlPaUpCTVRJNFEwSkRMVWhUTWpVMkluMEsiLAogICAgICAicmVjaXBp 3964 ZW50cyI6IFsKICAgICAgICB7CiAgICAgICAgICAiaGVhZGVyIjogewogICAgICAg 3965 ICAgImFsZyI6ICJSU0ExXzUiCiAgICAgICAgfSwKICAgICAgICAiZW5jcnlwdGVk 3966 X2tleSI6CiAgICAgICAgIgogICAgICAgIFFVVlRNVEk0SUNoRFJVc3BJR3RsZVN3 3967 Z1pXNWpjbmx3ZEdWa0lIZHBkR2dnVkZOTklGSlRRU0J3ZFdKc2FXTWcKICAgICAg 3968 ICBhMlY1TENCMWMybHVaeUJTVTBFeFh6VWdjR0ZrWkdsdVp3IgogICAgICAgIH0K 3969 ICAgICAgXSwKICAgICAgIml2IjogInlTR21mWjY5WWxjRWlsTnI1X1NHYkEiLAog 3970 ICAgICAiY2lwaGVydGV4dCI6CiAgICAgICIKICAgICAgYzJGdGNHeGxJR1J6YVNC 3971 a1lYUmhJR1Z1WTNKNWNIUmxaQ0IzYVhSb0lFRkZVekV5T0NCclpYa2dabkp2YlNC 3972 eVpXCiAgICAgIE5wY0dsbGJuUnpMbVZ1WTNKNWNIUmxaRjlyWlhrIiwKICAgICAg 3973 InRhZyI6ICJjMkZ0Y0d4bElHRjFkR2hsYm5ScFkyRjBhVzl1SUhSaFp3IgogICAg 3974 fQogIH0KfQ", 3975 "protected": "eyJhbGciOiJSUzI1NiJ9", 3976 "signature": "c2FtcGxlIHNpZ25hdHVyZQ" 3977 } 3978 } 3979 ] 3980 } 3982 The TEE returns "GetDeviceStateResponse" back to the OTrP Broker, 3983 which returns message back to the TAM. 3985 A.1.2. Sample CreateSD 3987 A.1.2.1. Sample CreateSDRequest 3988 { 3989 "CreateSDTBSRequest": { 3990 "ver":"1.0", 3991 "rid":"req-01", 3992 "tid":"tran-01", 3993 "tee":"SecuriTEE", 3994 "nextdsi":"false", 3995 "dsihash":"Iu-c0-fGrpMmzbbtiWI1U8u7wMJE7IK8wkJpsVuf2js", 3996 "content":{ 3997 "spid":"bank.com", 3998 "sdname":"sd.bank.com", 3999 "spcert":"MIIDFjCCAn- 4000 gAwIBAgIJAIk0Tat0tquDMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNVBAYTAkTAMQ4wD 4001 AYDVQQIDAVTZW91bDESMBAGA1UEBwwJR3Vyby1kb25nMRAwDgYDVQQKDAdTb2xhY2l 4002 hMRAwDgYDVQQLDAdTb2xhY2lhMRUwEwYDVQQDDAxTb2xhLWNpYS5jb20wHhcNMTUwN 4003 zAyMDg1MTU3WhcNMjAwNjMwMDg1MTU3WjBsMQswCQYDVQQGEwJLUjEOMAwGA1UECAw 4004 FU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU29sYWNpYTEQMA4GA 4005 1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tMIGfMA0GCSqGSIb3DQE 4006 BAQUAA4GNADCBiQKBgQDYWLrFf2OFMEciwSYsyhaLY4kslaWcXA0hCWJRaFzt5mU- 4007 lpSJ4jeu92inBbsXcI8PfRbaItsgW1TD1Wg4gQH4MX_YtaBoOepE-- 4008 3JoZZyPyCWS3AaLYWrDmqFXdbzaO1i8GxB7zz0gWw55bZ9jyzcl5gQzWSqMRpx_dca 4009 d2SP2wIDAQABo4G_MIG8MIGGBgNVHSMEfzB9oXCkbjBsMQswCQYDVQQGEwJLUjEOMA 4010 wGA1UECAwFU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU29sYWNp 4011 YTEQMA4GA1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tggkAiTRNq3 4012 S2q4MwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0lAQH_BAwwCgYIKwYB 4013 BQUHAwMwDQYJKoZIhvcNAQEFBQADgYEAEFMhRwEQ- 4014 LDa9O7P1N0mcLORpo6fW3QuJfuXbRQRQGoXddXMKazI4VjbGaXhey7Bzvk6TZYDa- 4015 GRiZby1J47UPaDQR3UiDzVvXwCOU6S5yUhNJsW_BeMViYj4lssX28iPpNwLUCVm1QV 4016 THILI6afLCRWXXclc1L5KGY290OwIdQ", 4017 "tamid":"TAM_x.acme.com", 4018 "did":"zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM" 4019 } 4020 } 4021 } 4023 Below is a sample message after the content is encrypted and encoded 4025 { 4026 "CreateSDRequest": { 4027 "payload":" 4028 eyJDcmVhdGVTRFRCU1JlcXVlc3QiOnsidmVyIjoiMS4wIiwicmlkIjoicmVxLTAxIiwidG 4029 lkIjoidHJhbi0wMSIsInRlZSI6IlNlY3VyaVRFRSIsIm5leHRkc2kiOiJmYWxzZSIsImRz 4030 aWhhc2giOiIyMmVmOWNkM2U3YzZhZTkzMjZjZGI2ZWQ4OTYyMzU1M2NiYmJjMGMyNDRlYz 4031 gyYmNjMjQyNjliMTViOWZkYTNiIiwiY29udGVudCI6eyJwcm90ZWN0ZWQiOiJlLUtBbkdW 4032 dVktS0FuVHJpZ0p4Qk1USTRRMEpETFVoVE1qVTI0b0NkZlEiLCJyZWNpcGllbnRzIjpbey 4033 JoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0sImVuY3J5cHRlZF9rZXkiOiJTUzE2NTl4Q2FJ 4034 c1dUeUlsVTZPLUVsZzU4UUhvT1pCekxVRGptVG9vanBaWE54TVpBakRMcWtaSTdEUzhOVG 4035 FIWHcxczFvZjgydVhsM0d6NlVWMkRoZDJ3R2l6Y2VEdGtXc1RwZDg4QVYwaWpEYTNXa3lk 4036 dEpSVmlPOGdkSlEtV29NSUVJRUxzVGthblZCb25wQkF4ZHE0ckVMbl9TZlliaFg4Zm9ub2 4037 gxUVUifV0sIml2IjoiQXhZOERDdERhR2xzYkdsamIzUm9aUSIsImNpcGhlcnRleHQiOiI1 4038 bmVWZXdndm55UXprR3hZeWw5QlFrZTJVNjVaOHp4NDdlb3NzM3FETy0xY2FfNEpFY3NLcj 4039 ZhNjF5QzBUb0doYnJOQWJXbVRSemMwSXB5bTF0ZjdGemp4UlhBaTZBYnVSM2gzSUpRS1Bj 4040 UUVvRUlkZ2tWX0NaZTM2eTBkVDBpRFBMclg0QzFkb0dmMEdvaWViRC1yVUg1VUtEY3BsTW 4041 9lTjZvUnFyd0dnNUhxLTJXM3B4MUlzY0h4SktRZm11dkYxMTJ4ajBmZFNZX0N2WFE1NTJr 4042 TVRDUW1ZbzRPaGF2R0ZvaG9TZVVnaGZSVG1LYWp3OThkTzdhREdrUEpRUlBtYVVHWllEMW 4043 JXd01nMXFRV3RPd19EZlIyZDNzTzVUN0pQMDJDUFprVXBiQ3dZYVcybW9HN1c2Zlc2U3V5 4044 Q2lpd2pQWmZSQmIzSktTVTFTd1kxYXZvdW02OWctaDB6by12TGZvbHRrWFV2LVdPTXZTY0 4045 JzR25NRzZYZnMzbXlTWnJ1WTNRR09wVVRzdjFCQ0JqSTJpdjkwb2U2aXFCcVpxQVBxbzdi 4046 ajYwVlJGQzZPTlNLZExGQTIyU3pqRHo1dmtnTXNEaHkwSzlDeVhYN1Z6MkNLTXJvQjNiUE 4047 xFZF9abTZuVWlkTFN5cVJ5cXJxTmVnN1lmQng3aV93X0dzRW9rX1VYZXd6RGtneHp6RjZj 4048 XzZ6S0s3UFktVnVmYUo0Z2dHZmlpOHEwMm9RZ1VEZTB2Vm1FWDc0c2VQX2RxakVpZVVOYm 4049 xBZE9sS2dBWlFGdEs4dy1xVUMzSzVGTjRoUG9yeDc2b3lPVUpOQTVFZVV2Qy1jR2tMcTNQ 4050 UG1GRmQyaUtOTElCTEJzVWl6c1h3RERvZVA5SmktWGt5ZEQtREN1SHdpcno0OEdNNWVLSj 4051 Q5WVdqRUtFQko2T01NNUNmZHZ4cDNmVG1uUTdfTXcwZ3FZVDRiOUJJSnBfWjA3TTctNUpE 4052 emg0czhyU3dsQzFXU3V2RmhRWlJCcXJtX2RaUlRIb0VaZldXc1VCSWVNWWdxNG1zb0JqTj 4053 NXSzhnRWYwZGI5a3Z6UG9LYmpJRy10UUE2R2l1X3pHaFVfLXFBV1lLemVKMDZ6djRIWlBO 4054 dHktQXRyTGF0WGhtUTdOQlVrX0hvbjdOUWxhU1g1ZHVNVmN4bGs1ZHVrWFZNMDgxa09wYV 4055 kzbDliQVFfYVhTM0FNaFFTTVVsT3dnTDZJazFPYVpaTGFMLUE3ejlITnlESmFEWTVhakZK 4056 TWFDV1lfOG94YlNoQUktNXA2MmNuT0xzV0dNWWNKTlBGVTZpcWlMR19oc3JfNlNKMURhbD 4057 VtQ0YycnBJLUItMlhuckxZR01ZS0NEZ2V2dGFnbi1DVUV6RURwR3ozQ2VLcWdQU0Vqd3BK 4058 N0M3NXduYTlCSmtTUkpOdDNla3hoWElrcnNEazRHVVpMSDdQYzFYZHdRTXhxdWpzNmxJSV 4059 EycjM1NWEtVkotWHdPcFpfY3RPdW96LTA4WHdYQ3RkTEliSFFVTG40RjlMRTRtanU0dUxS 4060 bjNSc043WWZ1S3dCVmVEZDJ6R3NBY0s5SVlDa3hOaDk3dDluYW1iMDZqSXVoWXF5QkhWRU 4061 9nTkhici1rMDY1bW9OVk5lVVUyMm5OdVNKS0ZxVnIxT0dKNGVfNXkzYkNwTmxTeEFPV1Bn 4062 RnJzU0Flc2JJOWw4eVJtVTAwenJYdGc4OWt5SjlCcXN2eXA1RE8wX2FtS1JyMXB1MVJVWF 4063 lFZzB2ampKS1FSdDVZbXRUNFJzaWpqdGRDWDg3UUxJaUdSY0hDdlJzUzZSdDJESmNYR1ht 4064 UGQyc0ZmNUZyNnJnMkFzX3BmUHN3cnF1WlAxbVFLc3RPMFVkTXpqMTlyb2N1NHVxVXlHUD 4065 lWWU54cHVnWVdNSjRYb1dRelJtWGNTUEJ4VEtnenFPS2s3UnRzWWVMNXl4LVM4NjV0cHVz 4066 dTA0bXpzYUJRZ21od1ZFVXBRdWNrcG1YWkNLNHlJUXktaHNFQUlJSmVxdFB3dVAySXF0X2 4067 I5dlk0bzExeXdzeXhzdmp2RnNKN0VVZU1MaGE2R2dSanBSbnU5RWIzRnlJZ0U5M0VVNEEw 4068 T0lUMWlOSGNRYWc0eWtOc3dPdkxQbjZIZ21zQ05ESlgwekc2RlFDMTZRdjBSQ25SVTdfV2 4069 VvblhSTUZwUzZRZ1JiSk45R1NMckN5bklJSWxUcDBxNHBaS05zM0tqQ2tMUzJrb3Bhd2Y0 4070 WF9BUllmTko3a0s5eW5BR0dCcktnUWJNRWVxUEFmMDBKMlYtVXpuU1JMZmQ4SGs3Y2JEdk 4071 5RQlhHQW9BR0ViaGRwVUc0RXFwMlVyQko3dEtyUUVSRlh4RTVsOFNHY2czQ1RmN2Zoazdx 4072 VEFBVjVsWEFnOUtOUDF1c1ZRZk1fUlBleHFNTG9WQVVKV2syQkF6WF9uSEhkVVhaSVBIOG 4073 hLeDctdEFRV0dTWUd0R2FmanZJZzI2c082TzloQWZVd3BpSV90MzF6SkZORDU0OTZURHBz 4074 QmNnd2dMLU1UcVhCRUJ2NEhvQld5SG1DVjVFMUwiLCJ0YWciOiJkbXlEeWZJVlNJUi1Ren 4075 ExOEgybFRIeEMxbl9HZEtrdnZNMDJUcHdsYzQwIn19fQ", 4076 "protected":"e-KAnGFsZ-KAnTrigJxSUzI1NuKAnX0", //RSAwithSHA256 4077 "header": { 4078 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4079 "signer":" 4080 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA 4081 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4082 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh 4083 cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p 4084 YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy 4085 BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4086 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4087 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3 4088 c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4089 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA 4090 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4091 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR 4092 MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq 4093 hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G 4094 SZ1MdyIZV8fwdEmD90IvtMHgtzK- 4095 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA 4096 UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4097 }, 4098 "signature":"nuQUsCTEBLeaRzuwd7q1iPIYEJ2eJfurO5sT5Y- 4099 N03zFRcv1jvrqMHtx_pw0Y9YWjmpoWfpfelhwGEko9SgeeBnznmkZbp7kjS6MmX4CKz 4100 9OApe3-VI7yL9Yp0WNdRh3425eYfuapCy3lcXFln5JBAUnU_OzUg3RWxcU_yGnFsw" 4101 } 4102 } 4104 A.1.2.2. Sample CreateSDResponse 4106 { 4107 "CreateSDTBSResponse": { 4108 "ver":"1.0", 4109 "status":"pass", 4110 "rid":"req-01", 4111 "tid":"tran-01", 4112 "content":{ 4113 "did":"zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM", 4114 "sdname":"sd.bank.com", 4115 "teespaik":"AQABjY9KiwH3hkMmSAAN6CLXot525U85WNlWKAQz5TOdfe_CM8h- 4116 X6_EHX1gOXoyRXaBiKMqWb0YZLCABTw1ytdXy2kWa525imRho8Vqn6HDGsJDZPDru9 4117 GnZR8pZX5ge_dWXB_uljMvDttc5iAWEJ8ZgcpLGtBTGLZnQoQbjtn1lIE", 4118 } 4119 } 4120 } 4122 Below is the response message after the content is encrypted and 4123 encoded. 4125 { 4126 "CreateSDResponse": { 4127 "payload":" 4128 eyJDcmVhdGVTRFRCU1Jlc3BvbnNlIjp7InZlciI6IjEuMCIsInN0YXR1cyI6InBhc3Mi 4129 LCJyaWQiOiJyZXEtMDEiLCJ0aWQiOiJ0cmFuLTAxIiwiY29udGVudCI6eyJwcm90ZWN0 4130 ZWQiOiJlLUtBbkdWdVktS0FuVHJpZ0p4Qk1USTRRMEpETFVoVE1qVTI0b0NkZlEiLCJy 4131 ZWNpcGllbnRzIjpbeyJoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0sImVuY3J5cHRlZF9r 4132 ZXkiOiJOX0I4R3pldUlfN2hwd0wwTFpHSTkxVWVBbmxJRkJfcndmZU1yZERrWnFGak1s 4133 VVhjdlI0XzhhOGhyeFI4SXR3aEtFZnVfRWVLRDBQb0dqQ2pCSHcxdG1ULUN6eWhsbW5v 4134 Slk3LXllWnZzRkRpc2VNTkd0eGE0OGZJYUs2VWx5NUZMYXBCZVc5T1I5bmktOU9GQV9j 4135 aFVuWWl3b2Q4ZTJFa0Vpd0JEZ1EzMk0ifV0sIml2IjoiQXhZOERDdERhR2xzYkdsamIz 4136 Um9aUSIsImNpcGhlcnRleHQiOiJsalh6Wk5JTmR1WjFaMXJHVElkTjBiVUp1RDRVV2xT 4137 QVptLWd6YnJINFVDYy1jMEFQenMtMWdWSFk4NTRUR3VMYkdyRmVHcDFqM2Fsb1lacWZp 4138 ZnE4aEt3Ty16RFlBN2tmVFhBZHp6czM4em9xeG4zbHoyM2w1RUlGUWhrOHBRWTRYTHRW 4139 M3ZBQWlNYnlrQ1Q3VS1CWDdWcjBacVNhYWZTQVZ4OFBLQ1RIU3hHN3hHVko0NkxxRzJS 4140 RE54WXQ4RC1SQ3lZUi1zRTM0MUFKZldEc2FLaGRRbzJXcjNVN1hTOWFqaXJtWjdqTlJ4 4141 cVRodHJBRWlIY1ctOEJMdVFHWEZ1YUhLMTZrenJKUGl4d0VXbzJ4cmw4cmkwc3ZRcHpl 4142 Z2M3MEt2Z0I0NUVaNHZiNXR0YlUya25hN185QU1Wcm4wLUJaQ1Bnb280MWlFblhuNVJn 4143 TXY2c2V2Y1JPQ2xHMnpWSjFoRkVLYjk2akEiLCJ0YWciOiIzOTZISTk4Uk1NQnR0eDlo 4144 ZUtsODROaVZLd0lJSzI0UEt2Z1RGYzFrbEJzIn19fQ", 4145 "protected": "e-KAnGFsZ-KAnTrigJxSUzI1NuKAnX0", 4146 "header": { 4147 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4148 "signer":" 4149 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJ 4150 BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp 4151 Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcN 4152 MTUwNzAyMDkwMTE4WhcNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzET 4153 MBEGA1UECAwKQ2FsaWZvcm5pYTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8G 4154 A1UECgwYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIGfMA0GCSqGSIb3DQEB 4155 AQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4156 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4157 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA 4158 6b_ZI3c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4159 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJ 4160 BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp 4161 Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX 4162 9nxZBNQWDjAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8E 4163 DDAKBggrBgEFBQcDAzANBgkqhkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4iv 4164 em4cIckfxzTBBiPHCjrrjB2X8Ktn8GSZ1MdyIZV8fwdEmD90IvtMHgtzK- 4165 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fV 4166 rJvnYAUBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4167 }, 4168 "signature":"jnJtaB0vFFwrE-qKOR3Pu9pf2gNoI1s67GgPCTq0U- 4169 qrz97svKpuh32WgCP2MWCoQPEswsEX-nxhIx_siTe4zIPO1nBYn- 4170 R7b25rQaF87O8uAOOnBN5Yl2Jk3laIbs- 4171 hGE32aRZDhrVoyEdSvIFrT6AQqD20bIAZGqTR-zA-900" 4172 } 4173 } 4175 A.1.3. Sample UpdateSD 4176 A.1.3.1. Sample UpdateSDRequest 4178 { 4179 "UpdateSDTBSRequest": { 4180 "ver": "1.0", 4181 "rid": "1222DA7D-8993-41A4-AC02-8A2807B31A3A", 4182 "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE", 4183 "tee": "Primary TEE ABC", 4184 "nextdsi": "false", 4185 "dsihash": 4186 " 4187 IsOvwpzDk8Onw4bCrsKTJsONwrbDrcKJYjVTw4vCu8OAw4JEw6zCgsK8w4JCacKxW8Kf 4188 w5o7", 4189 "content": { // NEEDS to BE ENCRYPTED 4190 "tamid": "id1.TAMxyz.com", 4191 "spid": "com.acmebank.spid1", 4192 "sdname": "com.acmebank.sdname1", 4193 "changes": { 4194 "newsdname": "com.acmebank.sdname2", 4195 "newspid": "com.acquirer.spid1", 4196 "spcert": 4197 "MIIDFjCCAn- 4198 gAwIBAgIJAIk0Tat0tquDMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNVBAYTAkTAMQ4 4199 wDAYDVQQIDAVTZW91bDESMBAGA1UEBwwJR3Vyby1kb25nMRAwDgYDVQQKDAdTb2x 4200 hY2lhMRAwDgYDVQQLDAdTb2xhY2lhMRUwEwYDVQQDDAxTb2xhLWNpYS5jb20wHhc 4201 NMTUwNzAyMDg1MTU3WhcNMjAwNjMwMDg1MTU3WjBsMQswCQYDVQQGEwJLUjEOMAw 4202 GA1UECAwFU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU29sYWN 4203 pYTEQMA4GA1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tMIGfMA0 4204 GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDYWLrFf2OFMEciwSYsyhaLY4kslaWcXA0 4205 hCWJRaFzt5mU- 4206 lpSJ4jeu92inBbsXcI8PfRbaItsgW1TD1Wg4gQH4MX_YtaBoOepE-- 4207 3JoZZyPyCWS3AaLYWrDmqFXdbzaO1i8GxB7zz0gWw55bZ9jyzcl5gQzWSqMRpx_d 4208 cad2SP2wIDAQABo4G_MIG8MIGGBgNVHSMEfzB9oXCkbjBsMQswCQYDVQQGEwJLUj 4209 EOMAwGA1UECAwFU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU2 4210 9sYWNpYTEQMA4GA1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tgg 4211 kAiTRNq3S2q4MwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0lAQH_BA 4212 wwCgYIKwYBBQUHAwMwDQYJKoZIhvcNAQEFBQADgYEAEFMhRwEQ- 4213 LDa9O7P1N0mcLORpo6fW3QuJfuXbRQRQGoXddXMKazI4VjbGaXhey7Bzvk6TZYDa 4214 - 4215 GRiZby1J47UPaDQR3UiDzVvXwCOU6S5yUhNJsW_BeMViYj4lssX28iPpNwLUCVm1 4216 QVTHILI6afLCRWXXclc1L5KGY290OwIdQ", 4217 "renewteespaik": "0" 4218 } 4219 } 4220 } 4221 } 4222 A.1.3.2. Sample UpdateSDResponse 4224 { 4225 "UpdateSDTBSResponse": { 4226 "ver": "1.0", 4227 "status": "pass", 4228 "rid": "1222DA7D-8993-41A4-AC02-8A2807B31A3A", 4229 "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE", 4230 "content": { 4231 "did": "MTZENTE5Qzc0Qzk0NkUxMzYxNzk0NjY4NTc3OTY4NTI=", 4232 "teespaik": 4233 "AQABjY9KiwH3hkMmSAAN6CLXot525U85WNlWKAQz5TOdfe_CM8h- 4234 X6_EHX1gOXoyRXaBiKMqWb0YZLCABTw1ytdXy2kWa525imRho8Vqn6HDGsJDZPDru9 4235 GnZR8pZX5ge_dWXB_uljMvDttc5iAWEJ8ZgcpLGtBTGLZnQoQbjtn1lIE", 4236 "teespaiktype": "RSA" 4237 } 4238 } 4239 } 4241 A.1.4. Sample DeleteSD 4243 A.1.4.1. Sample DeleteSDRequest 4245 The TAM builds message - including data to be encrypted. 4247 { 4248 "DeleteSDTBSRequest": { 4249 "ver": "1.0", 4250 "rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}", 4251 "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}", 4252 "tee": "Primary TEE", 4253 "nextdsi": "false", 4254 "dsihash": "AAECAwQFBgcICQoLDA0ODwABAgMEBQYHCAkKCwwNDg8=", 4255 "content": ENCRYPTED { 4256 "tamid": "TAM1.com", 4257 "sdname": "default.acmebank.com", 4258 "deleteta": "1" 4259 } 4260 } 4261 } 4263 The TAM encrypts the "content". 4265 { 4266 "DeleteSDTBSRequest": { 4267 "ver": "1.0", 4268 "rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}", 4269 "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}", 4270 "tee": "Primary TEE", 4271 "nextdsi": "false", 4272 "dsihash": "AAECAwQFBgcICQoLDA0ODwABAgMEBQYHCAkKCwwNDg8=", 4273 "content": { 4274 "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0", 4275 "recipients": [ 4276 { 4277 "header": { 4278 "alg": "RSA1_5" 4279 }, 4280 "encrypted_key": 4281 " 4282 QUVTMTI4IChDRUspIGtleSwgZW5jcnlwdGVkIHdpdGggVFNNIFJTQSBwdWJsaWMga2 4283 V5LCB1c2luZyBSU0ExXzUgcGFkZGluZw" 4284 } 4285 ], 4286 "iv": "rWO5DVmQX9ogelMLBIogIA", 4287 "ciphertext": 4288 " 4289 c2FtcGxlIGRzaSBkYXRhIGVuY3J5cHRlZCB3aXRoIEFFUzEyOCBrZXkgZnJvbSByZWNp 4290 cGllbnRzLmVuY3J5cHRlZF9rZXk", 4291 "tag": "c2FtcGxlIGF1dGhlbnRpY2F0aW9uIHRhZw" 4292 } 4293 } 4294 } 4296 The TAM signs the "DeleteSDTBSRequest" to form a "DeleteSDRequest" 4297 { 4298 "DeleteSDRequest": { 4299 "payload":" 4300 ewoJIkRlbGV0ZVNEVEJTUmVxdWVzdCI6IHsKCQkidmVyIjogIjEuMCIsCgkJInJp 4301 ZCI6ICJ7NzEyNTUxRjUtREZCMy00M2YwLTlBNjMtNjYzNDQwQjkxRDQ5fSIsCgkJ 4302 InRpZCI6ICJ7NEY0NTRBN0YtMDAyRC00MTU3LTg4NEUtQjBERDFBMDZBOEFFfSIs 4303 CgkJInRlZSI6ICJQcmltYXJ5IFRFRSIsCgkJIm5leHRkc2kiOiAiZmFsc2UiLAoJ 4304 CSJkc2loYXNoIjogIkFBRUNBd1FGQmdjSUNRb0xEQTBPRHdBQkFnTUVCUVlIQ0Fr 4305 S0N3d05EZzg9IiwKCQkiY29udGVudCI6IHsKCQkJInByb3RlY3RlZCI6ICJleUps 4306 Ym1NaU9pSkJNVEk0UTBKRExVaFRNalUySW4wIiwKCQkJInJlY2lwaWVudHMiOiBb 4307 ewoJCQkJImhlYWRlciI6IHsKCQkJCQkiYWxnIjogIlJTQTFfNSIKCQkJCX0sCgkJ 4308 CQkiZW5jcnlwdGVkX2tleSI6ICJRVVZUTVRJNElDaERSVXNwSUd0bGVTd2daVzVq 4309 Y25sd2RHVmtJSGRwZEdnZ1ZGTk5JRkpUUVNCd2RXSnNhV01nYTJWNUxDQjFjMmx1 4310 WnlCU1UwRXhYelVnY0dGa1pHbHVadyIKCQkJfV0sCgkJCSJpdiI6ICJyV081RFZt 4311 UVg5b2dlbE1MQklvZ0lBIiwKCQkJImNpcGhlcnRleHQiOiAiYzJGdGNHeGxJR1J6 4312 YVNCa1lYUmhJR1Z1WTNKNWNIUmxaQ0IzYVhSb0lFRkZVekV5T0NCclpYa2dabkp2 4313 YlNCeVpXTnBjR2xsYm5SekxtVnVZM0o1Y0hSbFpGOXJaWGsiLAoJCQkidGFnIjog 4314 ImMyRnRjR3hsSUdGMWRHaGxiblJwWTJGMGFXOXVJSFJoWnciCgkJfQoJfQp9", 4315 "protected":"eyJhbGciOiJSUzI1NiJ9", 4316 "header": { 4317 "x5c": ["ZXhhbXBsZSBBU04xIHNpZ25lciBjZXJ0aWZpY2F0ZQ==", 4318 "ZXhhbXBsZSBBU04xIENBIGNlcnRpZmljYXRl"] 4319 }, 4320 "signature":"c2FtcGxlIHNpZ25hdHVyZQ" 4321 } 4322 } 4324 A.1.4.2. Sample DeleteSDResponse 4326 The TEE creates a "DeleteSDTBSResponse" to respond to the 4327 "DeleteSDRequest" message from the TAM, including data to be 4328 encrypted. 4330 { 4331 "DeleteSDTBSResponse": { 4332 "ver": "1.0", 4333 "status": "pass", 4334 "rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}", 4335 "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}", 4336 "content": ENCRYPTED { 4337 "did": "MTZENTE5Qzc0Qzk0NkUxMzYxNzk0NjY4NTc3OTY4NTI=", 4338 } 4339 } 4340 } 4342 The TEE encrypts the "content" for the TAM. 4344 { 4345 "DeleteSDTBSResponse": { 4346 "ver": "1.0", 4347 "status": "pass", 4348 "rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}", 4349 "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}", 4350 "content": { 4351 "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0K", 4352 "recipients": [ 4353 { 4354 "header": { 4355 "alg": "RSA1_5" 4356 }, 4357 "encrypted_key": 4358 " 4359 QUVTMTI4IChDRUspIGtleSwgZW5jcnlwdGVkIHdpdGggVFNNIFJTQSBwdWJsaWMg 4360 a2V5LCB1c2luZyBSU0ExXzUgcGFkZGluZw" 4361 } 4362 ], 4363 "iv": "ySGmfZ69YlcEilNr5_SGbA", 4364 "ciphertext": 4365 " 4366 c2FtcGxlIGRzaSBkYXRhIGVuY3J5cHRlZCB3aXRoIEFFUzEyOCBrZXkgZnJvbSByZW 4367 NpcGllbnRzLmVuY3J5cHRlZF9rZXk", 4368 "tag": "c2FtcGxlIGF1dGhlbnRpY2F0aW9uIHRhZw" 4369 } 4370 } 4371 } 4373 The TEE signs "DeleteSDTBSResponse" to form a "DeleteSDResponse" 4374 { 4375 "DeleteSDResponse": { 4376 "payload":" 4377 ewoJIkRlbGV0ZVNEVEJTUmVzcG9uc2UiOiB7CgkJInZlciI6ICIxLjAiLAoJCSJz 4378 dGF0dXMiOiAicGFzcyIsCgkJInJpZCI6ICJ7NzEyNTUxRjUtREZCMy00M2YwLTlB 4379 NjMtNjYzNDQwQjkxRDQ5fSIsCgkJInRpZCI6ICJ7NEY0NTRBN0YtMDAyRC00MTU3 4380 LTg4NEUtQjBERDFBMDZBOEFFfSIsCgkJImNvbnRlbnQiOiB7CgkJCSJwcm90ZWN0 4381 ZWQiOiAiZXlKbGJtTWlPaUpCTVRJNFEwSkRMVWhUTWpVMkluMEsiLAoJCQkicmVj 4382 aXBpZW50cyI6IFt7CgkJCQkiaGVhZGVyIjogewoJCQkJCSJhbGciOiAiUlNBMV81 4383 IgoJCQkJfSwKCQkJCSJlbmNyeXB0ZWRfa2V5IjogIlFVVlRNVEk0SUNoRFJVc3BJ 4384 R3RsZVN3Z1pXNWpjbmx3ZEdWa0lIZHBkR2dnVkZOTklGSlRRU0J3ZFdKc2FXTWdh 4385 MlY1TENCMWMybHVaeUJTVTBFeFh6VWdjR0ZrWkdsdVp3IgoJCQl9XSwKCQkJIml2 4386 IjogInlTR21mWjY5WWxjRWlsTnI1X1NHYkEiLAoJCQkiY2lwaGVydGV4dCI6ICJj 4387 MkZ0Y0d4bElHUnphU0JrWVhSaElHVnVZM0o1Y0hSbFpDQjNhWFJvSUVGRlV6RXlP 4388 Q0JyWlhrZ1puSnZiU0J5WldOcGNHbGxiblJ6TG1WdVkzSjVjSFJsWkY5clpYayIs 4389 CgkJCSJ0YWciOiAiYzJGdGNHeGxJR0YxZEdobGJuUnBZMkYwYVc5dUlIUmhadyIK 4390 CQl9Cgl9Cn0", 4391 "protected":"eyJhbGciOiJSUzI1NiJ9", 4392 "signature":"c2FtcGxlIHNpZ25hdHVyZQ" 4393 } 4394 } 4396 The TEE returns "DeleteSDResponse" back to the OTrP Broker, which 4397 returns the message back to the TAM. 4399 A.2. Sample TA Management Messages 4401 A.2.1. Sample InstallTA 4403 A.2.1.1. Sample InstallTARequest 4404 { 4405 "InstallTATBSRequest": { 4406 "ver": "1.0", 4407 "rid": "24BEB059-0AED-42A6-A381-817DFB7A1207", 4408 "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE", 4409 "tee": "Primary TEE ABC", 4410 "nextdsi": "true", 4411 "dsihash": 4412 " 4413 IsOvwpzDk8Onw4bCrsKTJsONwrbDrcKJYjVTw4vCu8OAw4JEw6zCgsK8w4JCacKxW8Kf 4414 w5o7", 4415 "content": { 4416 "tamid": "id1.TAMxyz.com", 4417 "spid": "com.acmebank.spid1", 4418 "sdname": "com.acmebank.sdname1", 4419 "taid": "com.acmebank.taid.banking" 4420 }, 4421 "encrypted_ta": { 4422 "key": 4423 "mLBjodcE4j36y64nC/nEs694P3XrLAOokjisXIGfs0H7lOEmT5FtaNDYEMcg9RnE 4424 ftlJGHO7N0lgcNcjoXBmeuY9VI8xzrsZM9gzH6VBKtVONSx0aw5IAFkNcyPZwDdZ 4425 MLwhvrzPJ9Fg+bZtrCoJz18PUz+5aNl/dj8+NM85LCXXcBlZF74btJer1Mw6ffzT 4426 /grPiEQTeJ1nEm9F3tyRsvcTInsnPJ3dEXv7sJXMrhRKAeZsqKzGX4eiZ3rEY+FQ 4427 6nXULC8cAj5XTKpQ/EkZ/iGgS0zcXR7KUJv3wFEmtBtPD/+ze08NILLmxM8olQFj 4428 //Lq0gGtq8vPC8r0oOfmbQ==", 4429 "iv": "4F5472504973426F726E496E32303135", 4430 "alg": "AESCBC", 4431 "ciphertadata": 4432 "......0x/5KGCXWfg1Vrjm7zPVZqtYZ2EovBow+7EmfOJ1tbk......=", 4433 "cipherpdata": "0x/5KGCXWfg1Vrjm7zPVZqtYZ2EovBow+7EmfOJ1tbk=" 4434 } 4435 } 4436 } 4438 A.2.1.2. Sample InstallTAResponse 4440 A sample to-be-signed response of InstallTA looks as follows. 4442 { 4443 "InstallTATBSResponse": { 4444 "ver": "1.0", 4445 "status": "pass", 4446 "rid": "24BEB059-0AED-42A6-A381-817DFB7A1207", 4447 "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE", 4448 "content": { 4449 "did": "MTZENTE5Qzc0Qzk0NkUxMzYxNzk0NjY4NTc3OTY4NTI=", 4450 "dsi": { 4451 "tfwdata": { 4452 "tbs": "ezRGNDU0QTdGLTAwMkQtNDE1Ny04ODRFLUIwREQxQTA2QThBRX0=" 4453 "cert": "ZXhhbXBsZSBGVyBjZXJ0aWZpY2F0ZQ==", 4454 "sigalg": "UlMyNTY=", 4455 "sig": "c2FtcGxlIEZXIHNpZ25hdHVyZQ==" 4456 }, 4457 "tee": { 4458 "name": "Primary TEE", 4459 "ver": "1.0", 4460 "cert": "c2FtcGxlIFRFRSBjZXJ0aWZpY2F0ZQ==", 4461 "cacert": [ 4462 "c2FtcGxlIENBIGNlcnRpZmljYXRlIDE=", 4463 "c2FtcGxlIENBIGNlcnRpZmljYXRlIDI=" 4464 ], 4465 "sdlist": { 4466 "cnt": "1", 4467 "sd": [ 4468 { 4469 "name": "com.acmebank.sdname1", 4470 "spid": "com.acmebank.spid1", 4471 "talist": [ 4472 { 4473 "taid": "com.acmebank.taid.banking", 4474 "taname": "Acme secure banking app" 4475 }, 4476 { 4477 "taid": "acom.acmebank.taid.loyalty.rewards", 4478 "taname": "Acme loyalty rewards app" 4479 } 4480 ] 4481 } 4482 ] 4483 }, 4484 "teeaiklist": [ 4485 { 4486 "spaik": 4487 "c2FtcGxlIEFTTjEgZW5jb2RlZCBQS0NTMSBwdWJsaWNrZXk=", 4488 "spaiktype": "RSA" 4489 "spid": "acmebank.com" 4490 } 4491 ] 4492 } 4493 } 4494 } 4495 } 4496 } 4498 A.2.2. Sample UpdateTA 4500 A.2.2.1. Sample UpdateTARequest 4502 { 4503 "UpdateTATBSRequest": { 4504 "ver": "1.0", 4505 "rid": "req-2", 4506 "tid": "tran-01", 4507 "tee": "SecuriTEE", 4508 "nextdsi": " false", 4509 "dsihash": "gwjul_9MZks3pqUSN1-eL1aViwGXNAxk0AIKW79dn4U", 4510 "content": { 4511 "tamid": "TAM1.acme.com", 4512 "spid": "bank.com", 4513 "sdname": "sd.bank.com", 4514 "taid": "sd.bank.com.ta" 4515 }, 4516 "encrypted_ta": { 4517 "key": 4518 " 4519 XzmAn_RDVk3IozMwNWhiB6fmZlIs1YUvMKlQAv_UDoZ1fvGGsRGo9bT0A440aYMgLt 4520 GilKypoJjCgijdaHgamaJgRSc4Je2otpnEEagsahvDNoarMCC5nGQdkRxW7Vo2NKgL 4521 A892HGeHkJVshYm1cUlFQ-BhiJ4NAykFwlqC_oc", 4522 "iv": "AxY8DCtDaGlsbGljb3RoZQ", 4523 "alg": "AESCBC", 4524 "ciphernewtadata": 4525 "KHqOxGn7ib1F_14PG4_UX9DBjOcWkiAZhVE-U- 4526 67NsKryHGokeWr2spRWfdU2KWaaNncHoYGwEtbCH7XyNbOFh28nzwUmstep4nHWbAl 4527 XZYTNkENcABPpuw_G3I3HADo" 4528 } 4529 } 4530 } 4532 { 4533 "UpdateTARequest": { 4534 "payload" : 4535 " 4536 eyJVcGRhdGVUQVRCU1JlcXVlc3QiOnsidmVyIjoiMS4wIiwicmlkIjoicmVxLTIiLCJ0 4537 aWQiOiJ0cmFuLTAxIiwidGVlIjoiU2VjdXJpVEVFIiwibmV4dGRzaSI6ImZhbHNlIiwi 4538 ZHNpaGFzaCI6Imd3anVsXzlNWmtzM3BxVVNOMS1lTDFhVml3R1hOQXhrMEFJS1c3OWRu 4539 NFUiLCJjb250ZW50Ijp7InByb3RlY3RlZCI6ImV5SmxibU1pT2lKQk1USTRRMEpETFVo 4540 VE1qVTJJbjAiLCJyZWNpcGllbnRzIjpbeyJoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0s 4541 ImVuY3J5cHRlZF9rZXkiOiJYem1Bbl9SRFZrM0lvek13TldoaUI2Zm1abElzMVlVdk1L 4542 bFFBdl9VRG9aMWZ2R0dzUkdvOWJUMEE0NDBhWU1nTHRHaWxLeXBvSmpDZ2lqZGFIZ2Ft 4543 YUpnUlNjNEplMm90cG5FRWFnc2FodkROb2FyTUNDNW5HUWRrUnhXN1ZvMk5LZ0xBODky 4544 SEdlSGtKVnNoWW0xY1VsRlEtQmhpSjROQXlrRndscUNfb2MifV0sIml2IjoiQXhZOERD 4545 dERhR2xzYkdsamIzUm9aUSIsImNpcGhlcnRleHQiOiJIYTcwVXRZVEtWQmtXRFJuMi0w 4546 SF9IdkZtazl5SGtoVV91bk1OLWc1T3BqLWF1NGFUb2lxWklMYzVzYTdENnZZSjF6eW04 4547 QW1JOEJIVXFqc2l5Z0tOcC1HdURJUjFzRXc0a2NhMVQ5ZENuU0RydHhSUFhESVdrZmt3 4548 azZlR1NQWiIsInRhZyI6Im9UN01UTE41eWtBTFBoTDR0aUh6T1pPTGVFeU9xZ0NWaEM5 4549 MXpkcldMU0UifSwiZW5jcnlwdGVkX3RhIjp7ImtleSI6Ilh6bUFuX1JEVmszSW96TXdO 4550 V2hpQjZmbVpsSXMxWVV2TUtsUUF2X1VEb1oxZnZHR3NSR285YlQwQTQ0MGFZTWdMdEdp 4551 bEt5cG9KakNnaWpkYUhnYW1hSmdSU2M0SmUyb3RwbkVFYWdzYWh2RE5vYXJNQ0M1bkdR 4552 ZGtSeFc3Vm8yTktnTEE4OTJIR2VIa0pWc2hZbTFjVWxGUS1CaGlKNE5BeWtGd2xxQ19v 4553 YyIsIml2IjoiQXhZOERDdERhR2xzYkdsamIzUm9aUSIsImFsZyI6IkFFU0NCQyIsImNp 4554 cGhlcm5ld3RhZGF0YSI6IktIcU94R243aWIxRl8xNFBHNF9VWDlEQmpPY1draUFaaFZF 4555 LVUtNjdOc0tyeUhHb2tlV3Iyc3BSV2ZkVTJLV2FhTm5jSG9ZR3dFdGJDSDdYeU5iT0Zo 4556 MjhuendVbXN0ZXA0bkhXYkFsWFpZVE5rRU5jQUJQcHV3X0czSTNIQURvIn19fQ", 4557 "protected": " eyJhbGciOiJSUzI1NiJ9", 4558 "header": { 4559 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4560 "signer":" 4561 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA 4562 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4563 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh 4564 cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p 4565 YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy 4566 BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4567 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4568 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3 4569 c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4570 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA 4571 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4572 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR 4573 MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq 4574 hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G 4575 SZ1MdyIZV8fwdEmD90IvtMHgtzK- 4576 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA 4577 UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4578 }, 4579 "signature":"inB1K6G3EAhF- 4580 FbID83UI25R5Ao8MI4qfrbrmf0UQhjM3O7_g3l6XxN_JkHrGQaZr- 4581 myOkGPVM8BzbUZW5GqxNZwFXwMeaoCjDKc4Apv4WZkD1qKJxkg1k5jaUCfJz1Jmw_XtX 4582 6MHhrLh9ov03S9PtuT1VAQ0FVUB3qFIvjSnNU" 4583 } 4584 } 4586 A.2.2.2. Sample UpdateTAResponse 4587 { 4588 "UpdateTATBSResponse": { 4589 "ver": "1.0", 4590 "status": "pass", 4591 "rid": "req-2", 4592 "tid": "tran-01", 4593 "content": { 4594 "did": "zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM" 4595 } 4596 } 4597 } 4599 { 4600 "UpdateTAResponse":{ 4601 "payload":" 4602 eyJVcGRhdGVUQVRCU1Jlc3BvbnNlIjp7InZlciI6IjEuMCIsInN0YXR1cyI6InBhc3Mi 4603 LCJyaWQiOiJyZXEtMiIsInRpZCI6InRyYW4tMDEiLCJjb250ZW50Ijp7InByb3RlY3Rl 4604 ZCI6ImV5SmxibU1pT2lKQk1USTRRMEpETFVoVE1qVTJJbjAiLCJyZWNpcGllbnRzIjpb 4605 eyJoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0sImVuY3J5cHRlZF9rZXkiOiJFaGUxLUJB 4606 UUdJLTNEMFNHdXFGY01MZDJtd0gxQm1uRndYQWx1M1FxUFVXZ1RRVm55SUowNFc2MnBK 4607 YWVSREFkeTU0R0FSVjBrVzQ0RGw0MkdUUlhqbE1EZ3BYdXdFLWloc1JVV0tNNldCZ2N3 4608 VXVGQTRUR3gwU0I1NTZCdl92dnBNaFdfMXh2c2FHdFBaQmwxTnZjbXNibzBhY3FobXlu 4609 bzBDTmF5SVAtX1UifV0sIml2IjoiQXhZOERDdERhR2xzYkdsamIzUm9aUSIsImNpcGhl 4610 cnRleHQiOiJwc2o2dGtyaGJXM0lmVElMeE9GMU5HdFUtcTFmeVBidV9KWk9jbklycWIw 4611 eTNPOHN6OTItaWpWR1ZyRW5WbG1sY1FYeWFNZTNyX1JGdEkwV3B4UmRodyIsInRhZyI6 4612 Ik0zb2dNNk11MVJYMUMybEZvaG5rTkN5b25qNjd2TDNqd2RrZXhFdUlpaTgifX19", 4613 "protected":"eyJhbGciOiJSUzI1NiJ9", 4614 "header": { 4615 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4616 "signer":" 4617 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA 4618 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4619 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh 4620 cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p 4621 YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy 4622 BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4623 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4624 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3 4625 c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4626 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA 4627 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4628 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR 4629 MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq 4630 hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G 4631 SZ1MdyIZV8fwdEmD90IvtMHgtzK- 4632 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA 4633 UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4634 }, 4635 "signature":" 4636 Twajmt_BBLIMcNrDsjqr8lI7O7lEQxXZNhlUOtFkOMMqf37wOPKtp_99LoS82CVmdpCo 4637 PLaws8zzh-SNIQ42- 4638 9GYO8_9BaEGCiCwyl8YgWP9fWNfNv2gR2fl2DK4uknkYu1EMBW4YfP81n_pGpb4Gm- 4639 nMk14grVZygwAPej3ZZk" 4640 } 4641 } 4642 A.2.3. Sample DeleteTA 4644 A.2.3.1. Sample DeleteTARequest 4646 { 4647 "DeleteTATBSRequest": { 4648 "ver": "1.0", 4649 "rid": "req-2", 4650 "tid": "tran-01", 4651 "tee": "SecuriTEE", 4652 "nextdsi": "false", 4653 "dsihash": "gwjul_9MZks3pqUSN1-eL1aViwGXNAxk0AIKW79dn4U", 4654 "content": { 4655 "tamid": "TAM1.acme.com", 4656 "sdname": "sd.bank.com", 4657 "taid": "sd.bank.com.ta" 4658 } 4659 } 4660 } 4662 { 4663 "DeleteTARequest": { 4664 "payload": 4665 " 4666 eyJEZWxldGVUQVRCU1JlcXVlc3QiOnsidmVyIjoiMS4wIiwicmlkIjoicmVxLTIiLCJ0 4667 aWQiOiJ0cmFuLTAxIiwidGVlIjoiU2VjdXJpVEVFIiwibmV4dGRzaSI6ImZhbHNlIiwi 4668 ZHNpaGFzaCI6Imd3anVsXzlNWmtzM3BxVVNOMS1lTDFhVml3R1hOQXhrMEFJS1c3OWRu 4669 NFUiLCJjb250ZW50Ijp7InByb3RlY3RlZCI6eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0s 4670 InJlY2lwaWVudHMiOlt7ImhlYWRlciI6eyJhbGciOiJSU0ExXzUifSwiZW5jcnlwdGVk 4671 X2tleSI6ImtyaGs0d2dpY0RlX3d0VXQyTW4tSUJsdUtvX0JkeXpNY2p1cVlBenBPYnRS 4672 TG9MZzQ0QkFLN2tRVWE1YTg0TEVJRGEzaHNtWDIxdldNZFJLczN4MTJsOUh5VFdfLUNS 4673 WmZtcUx2bEh1LV9MSVdvc1ZyRTZVMlJqUnRndllVOWliUkVLczkzRDRHWm4xVHFuZG9n 4674 d0tXRF9jdG1nWG1sbzZZVXpCWDZhR1dZMCJ9XSwiaXYiOiJBeFk4REN0RGFHbHNiR2xq 4675 YjNSb1pRIiwiY2lwaGVydGV4dCI6IkhhNzBVdFlUS1ZCa1dEUm4yLTBIX1BGa19yQnpQ 4676 dGJHdzhSNktlMXotdklNeFBSY0Nxa1puZmwyTjRjUTZPSTZCSHZJUUFoM2Jic0l0dHlR 4677 bXhDTE5Nbm8wejBrYm9TdkIyVXlxWExpeGVZIiwidGFnIjoidEtUbFRLdlR2LTRtVVlG 4678 Y1dYWnZMMVlhQnRGNloxVlNxOTMzVmI2UEpmcyJ9fX0", 4679 "protected" : "eyJhbGciOiJSUzI1NiJ9", 4680 "header": { 4681 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4682 "signer":" 4683 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA 4684 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4685 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh 4686 cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p 4687 YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy 4688 BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4689 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4690 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3 4691 c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4692 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA 4693 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4694 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR 4695 MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq 4696 hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G 4697 SZ1MdyIZV8fwdEmD90IvtMHgtzK- 4698 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA 4699 UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4700 }, 4701 "signature" : 4702 " 4703 BZS0_Ab6pqvGNXe5lqT4Sc3jakyWQeiK9KlVSnimwWnjCCyMtyB9bwvlbILZba3IJiFe 4704 _3F9bIQpSytGS0f2TQrPTKC7pSjwDw-3kH7HkHcPPJd- 4705 PpMMfQvRx7AIV8vBqO9MijIC62iN0V2se5z2v8VFjGSoRGgq225w7FvrnWE" 4706 } 4707 } 4708 A.2.3.2. Sample DeleteTAResponse 4710 { 4711 "DeleteTATBSResponse": { 4712 "ver": "1.0", 4713 "status": "pass", 4714 "rid": "req-2", 4715 "tid": "tran-01", 4716 "content": { 4717 "did": "zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM" 4718 } 4719 } 4720 } 4722 { 4723 "DeleteTAResponse":{ 4724 "payload":" 4725 ew0KCSJEZWxldGVUQVRCU1Jlc3BvbnNlIjogew0KCQkidmVyIjogIjEuMCIsDQoJCSJz 4726 dGF0dXMiOiAicGFzcyIsDQoJCSJyaWQiOiAicmVxLTIiLA0KCQkidGlkIjogInRyYW4t 4727 MDEiLA0KCQkiY29udGVudCI6IHsNCgkJCSJwcm90ZWN0ZWQiOnsiZW5jIjoiQTEyOENC 4728 Qy1IUzI1NiJ9LA0KCQkJInJlY2lwaWVudHMiOlsNCgkJCQl7DQoJCQkJCSJoZWFkZXIi 4729 OnsiYWxnIjoiUlNBMV81In0sDQoJCQkJCSJlbmNyeXB0ZWRfa2V5IjoiTXdtU1ZHaWU2 4730 eHpfQmxTaFlmTFRKRHhKT3oyNWhvYy1HZ2NEM2o5OWFyM2E4X2lYY182ZE44bFRTb1dD 4731 X19wZEFhaEMyWk5SakdIcTBCZ2JDYTRKalk0eXRkMVBVWDB6M1psbXl1YnRXM291eEpY 4732 el9PMzg1WGM4S3hySndjbElyZGx2WUY2OVZmeERLQkVzUHJCdzlVenVIa1VmSU4xWlFU 4733 bWZ0QmVaSlJnIg0KCQkJCX0NCgkJCV0sDQoJCQkiaXYiOiJBeFk4REN0RGFHbHNiR2xq 4734 YjNSb1pRIiwNCgkJCSJjaXBoZXJ0ZXh0IjoiamhQTlV5ZkFTel9rVV9GbEM2LUtCME01 4735 WDBHNE5MbHc0LWt0bERyajZTWlUteUp6eUFUbC1oY0ZBWWMwLXJMVEF4cF93N1d1WER0 4736 Y3N3SzJSSzRjcWciLA0KCQkJInRhZyI6IlBBeGo5N25oT29qVTNIREhxSll4MGZMNWpt 4737 b0xkTlJkTHRTAMIzUTdrYXciDQoJCX0NCgl9DQp9", 4738 "protected": "eyJhbGciOiJSUzI1NiJ9", 4739 "header": { 4740 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4741 "signer":" 4742 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJ 4743 BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp 4744 Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcN 4745 MTUwNzAyMDkwMTE4WhcNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzET 4746 MBEGA1UECAwKQ2FsaWZvcm5pYTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8G 4747 A1UECgwYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIGfMA0GCSqGSIb3DQEB 4748 AQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4749 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4750 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA 4751 6b_ZI3c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4752 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJ 4753 BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp 4754 Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX 4755 9nxZBNQWDjAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8E 4756 DDAKBggrBgEFBQcDAzANBgkqhkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4iv 4757 em4cIckfxzTBBiPHCjrrjB2X8Ktn8GSZ1MdyIZV8fwdEmD90IvtMHgtzK- 4758 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fV 4759 rJvnYAUBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4760 }, 4761 "signature":" 4762 DfoBOetNelKsnAe_m4Z9K5UbihgWNYZsp5jVybiI05sOagDzv6R4do9npaAlAvpNK8HJ 4763 CxD6D22J8GDUExlIhSR1aDuDCQm6QzmjdkFdxAz5TRYl6zpPCZqgSToN_g1TZxqxEv6V 4764 Ob5fies4g6MHvCH-Il_-KbHq5YpwGxEEFdg" 4765 } 4766 } 4767 A.3. Example OTrP Broker Option 4769 The most popular TEE devices today are Android powered devices. In 4770 an Android device, an OTrP Broker can be a bound service with a 4771 service registration ID that a Client Application can use. This 4772 option allows a Client Application not to depend on any OTrP Broker 4773 SDK or provider. 4775 An OTrP Broker is responsible to detect and work with more than one 4776 TEE if a device has more than one. In this version, there is only 4777 one active TEE such that an OTrP Broker only needs to handle the 4778 active TEE. 4780 Appendix B. Contributors 4782 - Brian Witten 4783 Symantec 4784 brian_witten@symantec.com 4786 - Tyler Kim 4787 Solacia 4788 tylerkim@iotrust.kr 4790 Authors' Addresses 4792 Mingliang Pei 4793 Symantec 4794 350 Ellis St 4795 Mountain View, CA 94043 4796 USA 4798 Email: mingliang_pei@symantec.com 4800 Andrew Atyeo 4801 Intercede 4802 St. Mary's Road, Lutterworth 4803 Leicestershire, LE17 4PS 4804 Great Britain 4806 Email: andrew.atyeo@intercede.com 4807 Nick Cook 4808 ARM Ltd. 4809 110 Fulbourn Rd 4810 Cambridge, CB1 9NJ 4811 Great Britain 4813 Email: nicholas.cook@arm.com 4815 Minho Yoo 4816 IoTrust 4817 Suite 501, Gasanbusiness Center,165, Gasan digital1-ro 4818 Seoul 08503 4819 Korea 4821 Email: minho.yoo@iotrust.kr 4823 Hannes Tschofenig 4824 ARM Ltd. 4825 110 Fulbourn Rd 4826 Cambridge, CB1 9NJ 4827 Great Britain 4829 Email: hannes.tschofenig@arm.com