idnits 2.17.1 draft-ietf-teep-opentrustprotocol-01.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 == Line 822 has weird spacing: '...cluding the r...' -- The document date (July 2, 2018) is 2119 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CA' is mentioned on line 499, but not defined == Missing Reference: 'Soc' is mentioned on line 501, but not defined == Missing Reference: 'OEM' is mentioned on line 513, but not defined Summary: 0 errors (**), 0 flaws (~~), 5 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: January 3, 2019 Intercede 6 N. Cook 7 ARM Ltd. 8 M. Yoo 9 Solacia 10 H. Tschofenig 11 ARM Ltd. 12 July 2, 2018 14 The Open Trust Protocol (OTrP) 15 draft-ietf-teep-opentrustprotocol-01.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 January 3, 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 . . . . . . . . . . . . . . . . . . . . 6 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 Agent . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 6.1. Role of OTrP Agent . . . . . . . . . . . . . . . . . . . 15 77 6.2. OTrP Agent and Global Platform TEE Client API . . . . . . 16 78 6.3. OTrP Agent Implementation Consideration . . . . . . . . . 16 79 6.3.1. OTrP Agent Distribution . . . . . . . . . . . . . . . 16 80 6.3.2. Number of OTrP Agent . . . . . . . . . . . . . . . . 16 81 6.4. OTrP Agent 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 Secure Boot Module . . . . . . . . . . . . . . . . 75 148 12.1.1. Attestation signer . . . . . . . . . . . . . . . . . 75 149 12.1.2. SBM 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 . . . . . . . . . . . . . . . . . . . . . 78 156 13.1. Error Code List . . . . . . . . . . . . . . . . . . . . 78 157 13.1.1. TEE Signed Error Code List . . . . . . . . . . . . . 78 158 13.1.2. OTrP Agent 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 Agent 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 Agent 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 A TA binary and personalization data can be from two sources: 235 1. A TAM supplies the signed and encrypted TA binary 237 2. A Client Application supplies the TA binary 239 This specification considers the first case where TA binary and 240 personalization data are encrypted by recipient's public key that TAM 241 has to be involved. The second case will be addressed separately. 243 2. Requirements Language 245 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 246 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 247 document are to be interpreted as described in [RFC2119]. 249 3. Terminology 251 3.1. Definitions 253 The definitions provided below are defined as used in this document. 254 All the terms defined in the TEEP Architecture document [TEEPArch] 255 will be used, which are not repeated in this document. 257 OTrP Agent: It is the Agent as defined in the TEEP Architecture 258 document [TEEPArch]. 260 3.2. Abbreviations 262 CA Certificate Authority 264 OTrP Open Trust Protocol 266 REE Rich Execution Environment 268 SD Security Domain 270 SP Service Provider 272 SBM Secure Boot Module 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 284 4.1. System Components 286 The same system components as defined in the TEEP Architecture 287 document [TEEPArch] are used in OTrP, including TAM, CA, TEE, REE, 288 and OTrP Agent (a.k.a Agent). 290 Secure boot (for the purposes of OTrP) is optional in enabling 291 authenticity checking of TEEs by the TAM. A TAM provider can choose 292 it policy whether it trusts a TEE if the underlying firmware 293 attestation information isn't included. 295 OTrP uses trust anchors to establish trust between TEEs and TAMs and 296 verifies that they communicate in a trusted way when performing 297 lifecycle management transactions. 299 4.2. Trust Anchors in TEE 301 This assumes the Trust Anchor specification defined in the TEEP 302 Architecture document [TEEPArch]. 304 Each TEE comes with a trust store that contains a whitelist of root 305 CA certificates that are used to validate a TAM's certificate. A TEE 306 will accept a TAM to create new Security Domains and install new TAs 307 on behalf of a SP only if the TAM's certificate is chained to one of 308 the root CA certificates in the TEE's trust store. 310 4.3. Trust Anchors in TAM 312 The Trust Anchor set in a TAM consists of a list of Certificate 313 Authority certificates that signs various device TEE certificates. A 314 TAM decides what TEE and optionally TFW it will trust when TFW 315 signature data is present in an attestation. 317 4.4. Keys and Certificate Types 319 OTrP leverages the following list of trust anchors and identities in 320 generating signed and encrypted command messages that are exchanged 321 between a device's TEE and a TAM. With these security artifacts, 322 OTrP Messages are able to deliver end-to-end security without relying 323 on any transport security. 325 +-------------+----------+--------+-------------------+-------------+ 326 | Key Entity | Location | Issuer | Trust Implication | Cardinality | 327 | Name | | | | | 328 +-------------+----------+--------+-------------------+-------------+ 329 | 1. TFW key | Device | FW CA | A white list of | 1 per | 330 | pair and | secure | | FW root CA | device | 331 | certificate | storage | | trusted by TAMs | | 332 | | | | | | 333 | 2. TEE key | Device | TEE CA | A white list of | 1 per | 334 | pair and | TEE | under | TEE root CA | device | 335 | certificate | | a root | trusted by TAMs | | 336 | | | CA | | | 337 | | | | | | 338 | 3. TAM key | TAM | TAM CA | A white list of | 1 or | 339 | pair and | provider | under | TAM root CA | multiple | 340 | certificate | | a root | embedded in TEE | can be used | 341 | | | CA | | by a TAM | 342 | | | | | | 343 | 4. SP key | SP | SP | TAM manages SP. | 1 or | 344 | pair and | | signer | TA trust is | multiple | 345 | certificate | | CA | delegated to TAM. | can be used | 346 | | | | TEE trusts TAM to | by a TAM | 347 | | | | ensure that a TA | | 348 | | | | is trustworthy. | | 349 +-------------+----------+--------+-------------------+-------------+ 351 Table 1: Key and Certificate Types 353 1. TFW key pair and certificate: A key pair and certificate for 354 evidence of secure boot and trustworthy firmware in a device. 356 Location: Device secure storage 358 Supported Key Type: RSA and ECC 360 Issuer: OEM CA 362 Trust Implication: A white list of FW root CA trusted by TAMs 364 Cardinality: One per device 366 2. TEE key pair and certificate: It is used for device attestation 367 to a remote TAM and SP. 369 This key pair is burned into the device at device manufacturer. 370 The key pair and its certificate are valid for the expected 371 lifetime of the device. 373 Location: Device TEE 375 Supported Key Type: RSA and ECC 377 Issuer: A CA that chains to a TEE root CA 379 Trust Implication: A white list of TEE root CA trusted by TAMs 381 Cardinality: One per device 383 3. TAM key pair and certificate: A TAM provider acquires a 384 certificate from a CA that a TEE trusts. 386 Location: TAM provider 388 Supported Key Type: RSA and ECC. 390 Supported Key Size: RSA 2048-bit, ECC P-256 and P-384. Other 391 sizes should be anticipated in future. 393 Issuer: TAM CA that chains to a root CA 395 Trust Implication: A white list of TAM root CA embedded in TEE 397 Cardinality: One or multiple can be used by a TAM 399 4. SP key pair and certificate: an SP uses its own key pair and 400 certificate to sign a TA. 402 Location: SP 404 Supported Key Type: RSA and ECC 406 Supported Key Size: RSA 2048-bit, ECC P-256 and P-384. Other 407 sizes should be anticipated in future. 409 Issuer: an SP signer CA that chains to a root CA 411 Trust Implication: TAM manages SP. TA trusts an SP by 412 validating trust against a TAM that the SP uses. A TEE trusts 413 TAM to ensure that a TA from the TAM is trustworthy. 415 Cardinality: One or multiple can be used by an SP 417 5. Protocol Scope and Entity Relations 419 This document specifies messages and key properties that can 420 establish mutual trust between a TEE and a TAM. The protocol 421 provides specifications for the following three entities: 423 1. Key and certificate types required for device firmware, TEEs, 424 TAs, SPs, and TAMs 426 2. Data message formats that should be exchanged between a TEE in a 427 device and a TAM 429 3. An OTrP Agent application in the REE that can relay messages 430 between a Client Application and TEE 432 Figure 1: Protocol Scope and Entity Relationship 434 PKI CA -- CA CA -- 435 | | | 436 | | | 437 | | | 438 Device | | --- OTrP Agent / Client App --- | 439 SW | | | | | 440 | | | | | 441 | | | | | 442 OTrP | -- TEE TAM------- 443 | 444 | 445 FW 447 Figure 2: OTrP System Diagram 448 -------OTrP Message Protocol--- 449 | | 450 | | 451 -------------------- --------------- ---------- 452 | REE | TEE | | TAM | | SP | 453 | --- | --- | | --- | | -- | 454 | | | | | | | 455 | Client | SD (TAs)| | SD / TA | | TA | 456 | Apps | | | Mgmt | | | 457 | | | | | | | | 458 | | | | | | | | 459 | OTrP | Trusted | | Trusted | | | 460 | Agent | TAM/SP | | FW/TEE | | | 461 | | CAs | | CAs | | | 462 | | | | | | | 463 | |TEE Key/ | | TAM Key/ | |SP Key/ | 464 | | Cert | | Cert | | Cert | 465 | | FW Key/ | | | | | 466 | | Cert | | | | | 467 -------------------- --------------- ---------- 468 | | | 469 | | | 470 ------------- ---------- --------- 471 | TEE CA | | TAM CA | | SP CA | 472 ------------- ---------- --------- 474 In the previous diagram, different Certificate Authorities can be 475 used respectively for different types of certificates. OTrP Messages 476 are always signed, where the signer keys is the message creator's 477 private key such as a FW's private key, a TEE's private key, or a 478 TAM's private key. 480 The main OTrP component consists of a set of standard JSON messages 481 created by a TAM to deliver device SD and TA management commands to a 482 device, and device attestation and response messages created by a TEE 483 that responds to a TAM's OTrP message. 485 The communication method of OTrP Messages between a TAM and TEE in a 486 device may vary between TAM and TEE providers. A mandatory transport 487 protocol is specified for a compliant TAM and a device TEE. 489 An OTrP Agent is used to bridge communication between a TAM and a 490 TEE. The OTrP Agent doesn't need to know the actual content of OTrP 491 Messages except for the TEE routing information. 493 5.1. A Sample Device Setup Flow 495 Step 1: Prepare Images for Devices 497 1. [TEE vendor] Deliver TEE Image (CODE Binary) to device OEM 499 2. [CA] Deliver root CA Whitelist 501 3. [Soc] Deliver TFW Image 503 Step 2: Inject Key Pairs and Images to Devices 505 1. [OEM] Generate Secure Boot Key Pair (May be shared among multiple 506 devices) 508 2. [OEM] Flash signed TFW Image and signed TEE Image onto devices 509 (signed by Secure Boot Key) 511 Step 3: Setup attestation key pairs in devices 513 1. [OEM] Flash Secure Boot Public Key and eFuse Key (eFuse key is 514 unique per device) 516 2. [TFW/TEE] Generate a unique attestation key pair and get a 517 certificate for the device. 519 Step 4: Setup trust anchors in devices 521 1. [TFW/TEE] Store the key and certificate encrypted with the eFuse 522 key 524 2. [TEE vendor or OEM] Store trusted CA certificate list into 525 devices 527 5.2. Derived Keys in The Protocol 529 The protocol generates one key pair in run time to assist message 530 communication and anonymous verification between a TAM and a TEE. 532 TEE SP Anonymous Key (AIK): one derived key pair per SP in a device 534 The purpose of the key pair is to sign data by a TEE without using 535 its TEE device key for anonymous attestation to a Client Application. 536 This key pair is generated in the first SD creation for an SP. It is 537 deleted when all SDs are removed for a SP in a device. The public 538 key of the key pair is given to the caller Client Application and TAM 539 for future TEE returned data validation. The public key of this AIK 540 is also used by a TAM to encrypt TA binary data and personalization 541 data when it sends a TA to a device for installation. 543 5.3. Security Domain Hierarchy and Ownership 545 The primary job of a TAM is to help an SP to manage its trusted 546 applications. A TA is typically installed in an SD. An SD is 547 commonly created for an SP. 549 When an SP delegates its SD and TA management to a TAM, an SD is 550 created on behalf of a TAM in a TEE and the owner of the SD is 551 assigned to the TAM. An SD may be associated with an SP but the TAM 552 has full privilege to manage the SD for the SP. 554 Each SD for an SP is associated with only one TAM. When an SP 555 changes TAM, a new SP SD must be created to associate with the new 556 TAM. The TEE will maintain a registry of TAM ID and SP SD ID 557 mapping. 559 From an SD ownership perspective, the SD tree is flat and there is 560 only one level. An SD is associated with its owner. It is up to TEE 561 implementation how it maintains SD binding information for a TAM and 562 different SPs under the same TAM. 564 It is an important decision in this protocol specification that a TEE 565 doesn't need to know whether a TAM is authorized to manage the SD for 566 an SP. This authorization is implicitly triggered by an SP Client 567 Application, which instructs what TAM it wants to use. An SD is 568 always associated with a TAM in addition to its SP ID. A rogue TAM 569 isn't able to do anything on an unauthorized SP's SD managed by 570 another TAM. 572 Since a TAM may support multiple SPs, sharing the same SD name for 573 different SPs creates a dependency in deleting an SD. An SD can be 574 deleted only after all TAs associated with this SD is deleted. An SP 575 cannot delete a Security Domain on its own with a TAM if a TAM 576 decides to introduce such sharing. There are cases where multiple 577 virtual SPs belong to the same organization, and a TAM chooses to use 578 the same SD name for those SPs. This is totally up to the TAM 579 implementation and out of scope of this specification. 581 5.4. SD Owner Identification and TAM Certificate Requirements 583 There is a need of cryptographically binding proof about the owner of 584 an SD in a device. When an SD is created on behalf of a TAM, a 585 future request from the TAM must present itself as a way that the TEE 586 can verify it is the true owner. The certificate itself cannot 587 reliably used as the owner because TAM may change its certificate. 589 To this end, each TAM will be associated with a trusted identifier 590 defined as an attribute in the TAM certificate. This field is kept 591 the same when the TAM renew its certificates. A TAM CA is 592 responsible to vet the requested TAM attribute value. 594 This identifier value must not collide among different TAM providers, 595 and one TAM shouldn't be able to claim the identifier used by another 596 TAM provider. 598 The certificate extension name to carry the identifier can initially 599 use SubjectAltName:registeredID. A dedicated new extension name may 600 be registered later. 602 One common choice of the identifier value is the TAM's service URL. 603 A CA can verify the domain ownership of the URL with the TAM in the 604 certificate enrollment process. 606 A TEE can assign this certificate attribute value as the TAM owner ID 607 for the SDs that are created for the TAM. 609 An alternative way to represent an SD ownership by a TAM is to have a 610 unique secret key upon SD creation such that only the creator TAM is 611 able to produce a Proof-of-Possession (POP) data with the secret. 613 5.5. Service Provider Container 615 A sample Security Domain hierarchy for the TEE is shown below. 617 ---------- 618 | TEE | 619 ---------- 620 | 621 | ---------- 622 |----------| SP1 SD1 | 623 | ---------- 624 | ---------- 625 |----------| SP1 SD2 | 626 | ---------- 627 | ---------- 628 |----------| SP2 SD1 | 629 ---------- 631 OTrP segregates SDs and TAs such that a TAM can only manage or 632 retrieve data for SDs and TAs that it previously created for the SPs 633 it represents. 635 6. OTrP Agent 637 A TEE and TAs that run inside the TEE don't generally have capability 638 to communicate to the outside of the hosting device, for example, the 639 TEE specified by Global Platform groups [GPTEE]. This calls for a 640 software module in the REE world to handle the network communication. 641 Each Client Application in REE may carry this communication 642 functionality but it must also interact with the TEE for the message 643 exchange. The TEE interaction will vary according to different TEEs. 644 In order for a Client Application to transparently support different 645 TEEs, it is imperative to have a common interface for a Client 646 Application to invoke for exchanging messages with TEEs. 648 A shared OTrP Agent comes to meed this need. An OTrP Agent is a Rich 649 Application or SDK that facilitates communication between a TAM and 650 TEE. It also provides interfaces for TAM SDK or Client Applications 651 to query and trigger TA installation that the application needs to 652 use. 654 This interface for Client Applications may be commonly an Android 655 service call for an Android powered device. A Client Application 656 interacts with a TAM, and turns around to pass messages received from 657 TAM to OTrP Agent. 659 In all cases, a Client Application needs to be able to identify an 660 OTrP Agent that it can use. 662 6.1. Role of OTrP Agent 664 An OTrP Agent abstracts the message exchanges with the TEE in a 665 device. The input data is originated from a TAM that a Client 666 Application connects. A Client Application may also directly call 667 OTrP Agent for some TA query functions. 669 OTrP Agent may internally process a request from TAM. At least, it 670 needs to know where to route a message, e.g. TEE instance. It 671 doesn't need to process or verify message content. 673 OTrP Agent returns TEE / TFW generated response messages to the 674 caller. OTrP Agent isn't expected to handle any network connection 675 with an application or TAM. 677 OTrP Agent only needs to return an OTrP Agent error message if the 678 TEE is not reachable for some reason. Other errors are represented 679 as response messages returned from the TEE which will then be passed 680 to the TAM. 682 6.2. OTrP Agent and Global Platform TEE Client API 684 A Client Application may use Global Platform (GP) TEE API for TA 685 communication. OTrP may use the GP TEE Client API but it is internal 686 to OTrP implementation that converts given messages from TAM. More 687 details can be found at [GPTEECLAPI]. 689 6.3. OTrP Agent Implementation Consideration 691 A Provider should consider methods of distribution, scope and 692 concurrency on device and runtime options when implementing an OTrP 693 Agent. Several non-exhaustive options are discussed below. 694 Providers are encouraged to take advantage of the latest 695 communication and platform capabilities to offer the best user 696 experience. 698 6.3.1. OTrP Agent Distribution 700 OTrP Agent installation is commonly carried out at OEM time. A user 701 can dynamically download and install an OTrP Agent on-demand. 703 It is important to ensure a legitimate OTrP Agent is installed and 704 used. If an OTrP Agent is compromised it may send rogue messages to 705 TAM and TEE and introduce additional risks. 707 6.3.2. Number of OTrP Agent 709 We anticipate only one shared OTrP Agent instance in a device. The 710 device's TEE vendor will most probably supply one OTrP Agent. 711 Potentially we expect some open source. 713 With one shared OTrP Agent, the OTrP Agent provider is responsible to 714 allow multiple TAMs and TEE providers to achieve interoperability. 715 With a standard OTrP Agent interface, TAM can implement its own SDK 716 for its SP Client Applications to work with this OTrP Agent. 718 Multiple independent OTrP Agent providers can be used as long as they 719 have standard interface to a Client Application or TAM SDK. Only one 720 OTrP Agent is expected in a device. 722 TAM providers are generally expected to provide SDK for SP 723 applications to interact with an OTrP Agent for the TAM and TEE 724 interaction. 726 6.4. OTrP Agent Interfaces for Client Applications 728 A Client Application shall be responsible for relaying messages 729 between the OTrP agent and the TAM. 731 If a failure occurs during calling OTrP Agent, an error message 732 described in "Common Errors" section (see Section 7.6) will be 733 returned. 735 6.4.1. ProcessOTrPMessage call 737 Description 739 A Client Application will use this method of the OTrP Agent in a 740 device to pass OTrP messages from a TAM. The method is 741 responsible for interacting with the TEE and for forwarding the 742 input message to the TEE. It also returns TEE generated response 743 message back to the Client Application. 745 Inputs: 747 TAMInMsg - OTrP message generated in a TAM that is passed to this 748 method from a Client Application. 750 Outputs: 752 A TEE-generated OTrP response message (which may be a successful 753 response or be a response message containing an error raised 754 within the TEE) for the client application to forward to the TAM. 755 In the event of the OTrP agent not being able to communicate with 756 the TEE, a OTrPAgentException shall be thrown. 758 6.4.2. GetTAInformation call 760 Description 762 A Client Application may quickly query local TEE about a 763 previously installed TA without requiring TAM each time if it has 764 had the TA's identifier and previously saved TEE SP AIK public key 765 for TA information integrity verification. 767 Inputs: 769 { 770 "TAQuery": { 771 "spid": "", 772 "taid": "" 773 } 774 } 776 Outputs: 778 The OTrP Agent is expected to return TA signer and TAM signer 779 certificate along with other metadata information about the TA 780 associated with the given identifier. It follows the underlying 781 TEE trust model for authoring the local TA query from a Client 782 Application. 784 The output is a JSON message that is generated by the TEE. It 785 contains the following information: 787 * tamid 789 * SP ID 791 * TA signer certificate 793 * TAM certificate 795 The message is signed with TEE SP AIK private key. 797 The Client Application is expected to consume the response as 798 follows. 800 The Client Application gets signed TA metadata, in particular, the 801 TA signer certificate. It is able to verify that the result is 802 from device by checking signer against TEE SP AIK public key it 803 gets in some earlier interaction with TAM. 805 If this is a new Client Application in the device that hasn't had 806 TEE SP AIK public key for the response verification, the 807 application can contact the TAM first to do GetDeviceState, and 808 TAM will return TEE SP AIK public key to the app for this 809 operation to proceed. 811 Output Message: 813 { 814 "TAInformationTBS": { 815 "taid": "", 816 "tamid": "", 818 "spid": "", 819 "signercert": "", 821 "signercacerts": [ // the full list of CA certificate chain 822 // including the root CA 823 ], 824 "cacert": "" 826 ], 827 "tamcert": "", 829 "tamcacerts": [ // the full list of CA certificate chain 830 // including the root CA 831 ], 832 "cacert":"" 834 ] 835 } 836 } 838 { 839 "TAInformation": { 840 "payload": "", 842 "protected": "", 843 "header": { 844 "signer": {""} 846 }, 847 "signature": "" 849 } 850 } 852 where the definitions of BASE64 and BASE64URL refer to [RFC4648]. 854 A sample JWK public key representation refers to an example in 855 [RFC7517]. 857 6.5. Sample End-to-End Client Application Flow 859 6.5.1. Case 1: A New Client Application Uses a TA 861 1. During the Client Application installation time, the Client 862 Application calls TAM to initialize the device preparation step. 864 A. The Client Application knows it wants to use a Trusted 865 Application TA1 but the application doesn't know whether TA1 866 has been installed or not. It can use GP TEE Client API 867 [GPTEECLAPI] to check the existence of TA1 first. If it 868 detects that TA1 doesn't exist, it will contact TAM to 869 initiate the installation of TA1. Note that TA1 could have 870 been previously installed by other Client Applications from 871 the same service provider in the device. 873 B. The Client Application sends the TAM the TA list that it 874 depends on. The TAM will query a device for the Security 875 Domains and TAs that have been installed, and instructs the 876 device to install any dependent TAs that have not been 877 installed. 879 C. In general, the TAM has the latest TA list and their status 880 in a device because all operations are instructed by TAM. 881 TAM has such visibility because all Security Domain deletion 882 and TA deletion are managed by the TAM; the TAM could have 883 stored the state when a TA is installed, updated and 884 deleted. There is also the possibility that an update 885 command is carried out inside TEE but a response is never 886 received in TAM. There is also possibility that some manual 887 local reset is done in a device that the TAM isn't aware of 888 the changes. 890 2. The TAM generates message: GetDeviceStateRequest 892 3. The Client Application passes the JSON message 893 GetDeviceStateRequest to OTrP Agent call ProcessOTrPMessage. 894 The communication between a Client Application and an OTrP Agent 895 is up to the implementation of the OTrP Agent. 897 4. The OTrP Agent routes the message to the active TEE. Multiple 898 TEE case: it is up to OTrP Agent to figure this out. This 899 specification limits the support to only one active TEE, which 900 is the typical case today. 902 5. The target active TEE processes the received OTrP message, and 903 returns a JSON message GetDeviceStateResponse. 905 6. The OTrP Agent passes the GetDeviceStateResponse to the Client 906 Application. 908 7. The Client Application sends GetDeviceStateResponse to the TAM. 910 8. The TAM processes the GetDeviceStateResponse. 912 A. Extract TEEspaik for the SP, signs TEEspaik with TAM signer 913 key 915 B. Examine SD list and TA list 917 9. The TAM continues to carry out other actions based on the need. 918 The next call could be instructing the device to install a 919 dependent TA. 921 A. Assume a dependent TA isn't in the device yet, the TAM may 922 do the following: (1) create an SD in which to install the 923 TA by sending a CreateSDRequest message. The message is 924 sent back to the Client Application, and then the OTrP Agent 925 and TEE to process; (2) install a TA with an 926 InstallTARequest message. 928 B. If a Client Application depends on multiple TAs, the Client 929 Application should expect multiple round trips of the TA 930 installation message exchanges. 932 10. At the last TAM and TEE operation, the TAM returns the signed 933 TEE SP AIK public key to the application. 935 11. The Client Application stores the TEEspaik for future loaded TA 936 trust check. 938 12. If the TAM finds that this is a fresh device that does not have 939 any SD for the SP yet, then the TAM may next create an SD for 940 the SP. 942 13. During Client Application installation, the application checks 943 whether required Trusted Applications are already installed, 944 which may have been provided by the TEE. If needed, it will 945 contact its TAM service to determine whether the device is ready 946 or install TA list that this application needs. 948 6.5.2. Case 2: A Previously Installed Client Application Calls a TA 950 1. The Client Application checks the device readiness: (a) whether 951 it has a TEE; (b) whether it has TA that it depends. It may 952 happen that TAM has removed the TA this application depends on. 954 2. The Client Application calls the OTrP Agent to query the TA. 956 3. The OTrP Agent queries the TEE to get TA information. If the 957 given TA doesn't exist, an error is returned. 959 4. The Client Application parses the TAInformation message. 961 5. If the TA doesn't exist, the Client Application calls its TAM to 962 install the TA. If the TA exists, the Client Application 963 proceeds to call the TA. 965 7. OTrP Messages 967 The main OTrP component is the set of standard JSON messages created 968 by a TAM to deliver device SD and TA management commands to a device, 969 and device attestation and response messages created by TEE to 970 respond to TAM OTrP Messages. 972 An OTrP Message is designed to provide end-to-end security. It is 973 always signed by its creator. In addition, an OTrP Message is 974 typically encrypted such that only the targeted device TEE or TAM is 975 able to decrypt and view the actual content. 977 7.1. Message Format 979 OTrP Messages use the JSON format for JSON's simple readability and 980 moderate data size in comparison with alternative TLV and XML 981 formats. More compact CBOR format may be used as an alternative 982 choice. 984 JSON Message security has developed JSON Web Signing and JSON Web 985 Encryption standard in the IETF Workgroup JOSE, see JWS [RFC7515] and 986 JWE [RFC7516]. The OTrP Messages in this protocol will leverage the 987 basic JWS and JWE to handle JSON signing and encryption. 989 7.2. Message Naming Convention 991 For each TAM command "xyz"", OTrP use the following naming convention 992 to represent its raw message content and complete request and 993 response messages: 995 +-----------------------+----------------+---------------------+ 996 | Purpose | Message Name | Example | 997 +-----------------------+----------------+---------------------+ 998 | Request to be signed | xyzTBSRequest | CreateSDTBSRequest | 999 | | | | 1000 | Request message | xyzRequest | CreateSDRequest | 1001 | | | | 1002 | Response to be signed | xyzTBSResponse | CreateSDTBSResponse | 1003 | | | | 1004 | Response message | xyzResponse | CreateSDResponse | 1005 +-----------------------+----------------+---------------------+ 1007 7.3. Request and Response Message Template 1009 An OTrP Request message uses the following format: 1011 { 1012 "TBSRequest": { 1013 1014 } 1015 } 1017 A corresponding OTrP Response message will be as follows. 1019 { 1020 "TBSResponse": { 1021 1022 } 1023 } 1025 7.4. Signed Request and Response Message Structure 1027 A signed request message will generally include only one signature, 1028 and uses the flattened JWS JSON Serialization Syntax, see 1029 Section 7.2.2 in [RFC7515]. 1031 A general JWS object looks like the following. 1033 { 1034 "payload": "", 1035 "protected": "", 1036 "header": { 1037 , 1038 }, 1039 "signature": "" 1040 } 1041 OTrP signed messages only require the signing algorithm as the 1042 mandate header in the property "protected". The "non-integrity- 1043 protected header contents" is optional. 1045 OTrP signed message will be given an explicit Request or Response 1046 property name. In other words, a signed Request or Response uses the 1047 following template. 1049 A general JWS object looks like the following. 1051 { 1052 "[Request | Response]": { 1053 TBS[Request | Response] 1054 } 1055 } 1057 With the standard JWS message format, a signed OTrP Message looks 1058 like the following. 1060 { 1061 "[Request | Response]": { 1062 "payload": "TBS[Request | Response]>", 1063 "protected": "", 1064 "header": , 1065 "signature": "" 1066 } 1067 } 1069 The top element " [Signed][Request | Response]" cannot be fully 1070 trusted to match the content because it doesn't participate in the 1071 signature generation. However, a recipient can always match it with 1072 the value associated with the property "payload". It purely serves 1073 to provide a quick reference for reading and method invocation. 1075 Furthermore, most properties in an unsigned OTrP messages are 1076 encrypted to provide end-to-end confidentiality. The only OTrP 1077 message that isn't encrypted is the initial device query message that 1078 asks for the device state information. 1080 Thus a typical OTrP Message consists of an encrypted and then signed 1081 JSON message. Some transaction data such as transaction ID and TEE 1082 information may need to be exposed to the OTrP Agent for routing 1083 purpose. Such information is excluded from JSON encryption. The 1084 device's signer certificate itself is encrypted. The overall final 1085 message is a standard signed JSON message. 1087 As required by JSW/JWE, those JWE and JWS related elements will be 1088 BASE64URL encoded. Other binary data elements specific to the OTrP 1089 specification are BASE64-encoded. This specification indicates 1090 elements that should be BASE64 and those elements that are to be 1091 BASE64URL encoded. 1093 7.4.1. Identifying Signing and Encryption Keys for JWS/JWE Messaging 1095 JWS and JWE messaging allow various options for identifying the 1096 signing and encryption keys, for example, it allows optional elements 1097 including "x5c", "x5t" and "kid" in the header to cover various 1098 possibilities. 1100 To protect privacy, it is important that the device's certificate is 1101 released only to a trusted TAM, and that it is encrypted. The TAM 1102 will need to know the device certificate, but untrusted parties must 1103 not be able to get the device certificate. All OTrP messaging 1104 conversations between a TAM and device begin with 1105 GetDeviceStateRequest / GetDeviceStateResponse. These messages have 1106 elements built into them to exchange signing certificates, described 1107 in the section Section 9. Any subsequent messages in the 1108 conversation that follow on from this implicitly use the same 1109 certificates for signing/encryption, and as a result the certificates 1110 or references may be omitted in those subsequent messages. 1112 In other words, the signing key identifier in the use of JWS and JWE 1113 here may be absent in the subsequent messages after the initial 1114 GetDeviceState query. 1116 This has an implication on the TEE and TAM implementation: they have 1117 to cache the signer certificates for the subsequent message signature 1118 validation in the session. It may be easier for a TAM service to 1119 cache transaction session information but not so for a TEE in a 1120 device. A TAM can get a device's capability by checking the response 1121 message from a TEE to decide whether it should include its TAM signer 1122 certificate and OCSP data in each subsequent request message. The 1123 device's caching capability is reported in GetDeviceStateResponse 1124 signerreq parameter. 1126 7.5. JSON Signing and Encryption Algorithms 1128 The OTrP JSON signing algorithm shall use SHA256 or a stronger hash 1129 method with respective key type. JSON Web Algorithm RS256 or ES256 1130 [RFC7518] SHALL be used for RSA with SHA256 and ECDSA with SHA256. 1131 If RSA with SHA256 is used, the JSON web algorithm representation is 1132 as follows. 1134 {"alg":"RS256"} 1136 The (BASE64URL encoded) "protected" header property in a signed 1137 message looks like the following: 1139 "protected":"eyJhbGciOiJSUzI1NiJ9" 1141 If ECSDA with P-256 curve and SHA256 are used for signing, the JSON 1142 signing algorithm representation is as follows. 1144 {"alg":"ES256"} 1146 The value for the "protected" field will be the following. 1148 eyJhbGciOiJFUzI1NiJ9 1150 Thus, a common OTrP signed message with ES256 looks like the 1151 following. 1153 { 1154 "payload": "", 1155 "protected": "eyJhbGciOiJFUzI1NiJ9", 1156 "signature": "" 1157 } 1159 The OTrP JSON message encryption algorithm SHOULD use one of the 1160 supported algorithms defined in the later chapter of this document. 1161 JSON encryption uses a symmetric key as its "Content Encryption Key 1162 (CEK)". This CEK is encrypted or wrapped by a recipient's key. The 1163 OTrP recipient typically has an asymmetric key pair. Therefore, the 1164 CEK will be encrypted by the recipient's public key. 1166 A compliant implementation shall support the following symmetric 1167 encryption algorithm and anticipate future new algorithms. 1169 {"enc":"A128CBC-HS256"} 1171 This algorithm represents encryption with AES 128 in CBC mode with 1172 HMAC SHA 256 for integrity. The value of the property "protected" in 1173 a JWE message will be 1175 eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0 1177 An encrypted JSON message looks like the following. 1179 { 1180 "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0", 1181 "recipients": [ 1182 { 1183 "header": { 1184 "alg": "" 1185 }, 1186 "encrypted_key": "" 1187 } 1188 ], 1189 "iv": "", 1190 "ciphertext": "", 1192 "tag": "" 1193 } 1195 OTrP doesn't use JWE AAD (Additional Authenticated Data) because each 1196 message is always signed after the message is encrypted. 1198 7.5.1. Supported JSON Signing Algorithms 1200 The following JSON signature algorithm is mandatory support in the 1201 TEE and TAM: 1203 o RS256 1205 ES256 is optional to support. 1207 7.5.2. Support JSON Encryption Algorithms 1209 The following JSON authenticated encryption algorithm is mandatory 1210 support in TEE and TAM. 1212 o A128CBC-HS256 1214 A256CBC-HS512 is optional to support. 1216 7.5.3. Supported JSON Key Management Algorithms 1218 The following JSON key management algorithm is mandatory support in 1219 TEE and TAM. 1221 o RSA1_5 1223 ECDH-ES+A128KW and ECDH-ES+A256KW are optional to support. 1225 7.6. Common Errors 1227 An OTrP Response message typically needs to report the operation 1228 status and error causes if an operation fails. The following JSON 1229 message elements should be used across all OTrP Messages. 1231 "status": "pass | fail" 1233 "reason": { 1234 "error-code": "", 1235 "error-message": "" 1236 } 1238 "ver": "" 1240 7.7. OTrP Message List 1242 The following table lists the OTrP commands and therefore 1243 corresponding Request and Response messages defined in this 1244 specification. Additional messages may be added in the future when 1245 new task messages are needed. 1247 GetDeviceState - 1248 A TAM queries a device's current state with a message 1249 GetDeviceStateRequest. A device TEE will report its version, its 1250 FW version, and list of all SDs and TAs in the device that is 1251 managed by the requesting TAM. TAM may determine whether the 1252 device is trustworthy and decide to carry out additional commands 1253 according to the response from this query. 1255 CreateSD - 1256 A TAM instructs a device TEE to create an SD for an SP. The 1257 recipient TEE will check whether the requesting TAM is 1258 trustworthy. 1260 UpdateSD - 1261 A TAM instructs a device TEE to update an existing SD. A typical 1262 update need comes from SP certificate change, TAM certificate 1263 change and so on. The recipient TEE will verify whether the TAM 1264 is trustworthy and owns the SD. 1266 DeleteSD - 1267 A TAM instructs a device TEE to delete an existing SD. A TEE 1268 conditionally deletes TAs loaded in the SD according to a request 1269 parameter. An SD cannot be deleted until all TAs in this SD are 1270 deleted. If this is the last SD for an SP, TEE MAY also delete 1271 TEE SP AIK key for this SP. 1273 InstallTA - 1274 A TAM instructs a device to install a TA into an SD for a SP. 1275 The TEE in a device will check whether the TAM and TA are 1276 trustworthy. 1278 UpdateTA - 1279 A TAM instructs a device to update a TA into an SD for an SP. 1280 The change may commonly be bug fix for a previously installed TA. 1282 DeleteTA - 1283 A TAM instructs a device to delete a TA. The TEE in a device 1284 will check whether the TAM and TA are trustworthy. 1286 7.8. OTrP Request Message Routing Rules 1288 For each command that a TAM wants to send to a device, the TAM 1289 generates a request message. This is typically triggered by a Client 1290 Application that uses the TAM. The Client Application initiates 1291 contact with the TAM and receives TAM OTrP Request messages according 1292 to the TAM's implementation. The Client Application forwards the 1293 OTrP message to an OTrP Agent in the device, which in turn sends the 1294 message to the active TEE in the device. 1296 The current version of this specification assumes that each device 1297 has only one active TEE, and the OTrP Agent is responsible to connect 1298 to the active TEE. This is the case today with devices in the 1299 market. 1301 When the TEE responds to a request, the OTrP Agent gets the OTrP 1302 response messages back to the Client Application that sent the 1303 request. In case the target TEE fails to respond to the request, the 1304 OTrP Agent will be responsible to generate an error message to reply 1305 the Client Application. The Client Application forwards any data it 1306 received to its TAM. 1308 7.8.1. SP Anonymous Attestation Key (SP AIK) 1310 When the first new Security Domain is created in a TEE for an SP, a 1311 new key pair is generated and associated with this SP. This key pair 1312 is used for future device attestation to the service provider instead 1313 of using the device's TEE key pair. 1315 8. Transport Protocol Support 1317 The OTrP message exchange between a TEE device and TAM generally 1318 takes place between a Client Application in REE and TAM. A device 1319 that is capable to run a TEE and PKI based cryptographic attestation 1320 isn't generally resource constraint to carry out standard HTTPS 1321 connections. A compliant device and TAM SHOULD support HTTPs. 1323 9. Detailed Messages Specification 1325 For each message in the following sections all JSON elements are 1326 mandatory if not explicitly indicated as optional. 1328 9.1. GetDeviceState 1330 This is the first command that a TAM will send to a device. This 1331 command is triggered when an SP's Client Application contacts its TAM 1332 to check whether the underlying device is ready for TA operations. 1334 This command queries a device's current TEE state. A device TEE will 1335 report its version, its FW version, and list of all SDs and TAs in 1336 the device that is managed by the requesting TAM. TAM may determine 1337 whether the device is trustworthy and decide to carry out additional 1338 commands according to the response from this query. 1340 The request message of this command is signed by the TAM. The 1341 response message from the TEE is encrypted. A random message 1342 encryption key (MK) is generated by TEE, and this encrypted key is 1343 encrypted by the TAM's public key such that only the TAM that sent 1344 the request is able to decrypt and view the response message. 1346 9.1.1. GetDeviceStateRequest message 1348 { 1349 "GetDeviceStateTBSRequest": { 1350 "ver": "1.0", 1351 "rid": "", 1352 "tid": "", 1353 "ocspdat": ["], 1354 "supportedsigalgs": [] 1355 } 1356 } 1358 The request message consists of the following data elements: 1360 ver - version of the message format 1362 rid - a unique request ID generated by the TAM 1364 tid - a unique transaction ID to trace request and response. This 1365 can be from a prior transaction's tid field, and can be used in 1366 subsequent message exchanges in this TAM session. The 1367 combination of rid and tid MUST be made unique. 1369 ocspdat - A list of OCSP stapling data respectively for the TAM 1370 certificate and each of the CA certificates up to the root 1371 certificate. The TAM provides OCSP data such that a recipient 1372 TEE can validate the TAM certificate chain revocation status 1373 without making its own external OCSP service call. A TEE MAY 1374 cache the CA OCSP data such that the array may contain only the 1375 OCSP stapling data for the TAM certificate in subsequent 1376 exchanges. This is a mandatory field. 1378 supportedsigalgs - an optional property to list the signing 1379 algorithms that the TAM is able to support. A recipient TEE MUST 1380 choose an algorithm in this list to sign its response message if 1381 this property is present in a request. If it is absent, the TEE 1382 may use any compliant signing algorithm that is listed as 1383 mandatory support in this specification. 1385 The final request message is JSON signed message of the above raw 1386 JSON data with TAM's certificate. 1388 { 1389 "GetDeviceStateRequest": { 1390 "payload": "", 1392 "protected": "", 1393 "header": { 1394 "x5c": "" 1396 }, 1397 "signature":"" 1398 } 1399 } 1401 The signing algorithm SHOULD use SHA256 with respective key type. 1402 The mandatory algorithm support is the RSA signing algorithm. The 1403 signer header "x5c" is used to include the TAM signer certificate up 1404 to the root CA certificate. 1406 9.1.2. Request processing requirements at a TEE 1408 Upon receiving a request message GetDeviceStateRequest at a TEE, the 1409 TEE MUST validate a request: 1411 1. Validate JSON message signing. If it doesn't pass, an error 1412 message is returned. 1414 2. Validate that the request TAM certificate is chained to a trusted 1415 CA that the TEE embeds as its trust anchor. 1417 * Cache the CA OCSP stapling data and certificate revocation 1418 check status for other subsequent requests. 1420 * A TEE can use its own clock time for the OCSP stapling data 1421 validation. 1423 3. Optionally collect Firmware signed data 1425 * This is a capability in ARM architecture that allows a TEE to 1426 query Firmware to get FW signed data. It isn't required for 1427 all TEE implementations. When TFW signed data is absent, it 1428 is up to a TAM's policy how it will trust a TEE. 1430 4. Collect SD information for the SD owned by this TAM 1432 9.1.3. Firmware Signed Data 1434 Firmware isn't expected to process or produce JSON data. It is 1435 expected to just sign some raw bytes of data. 1437 The data to be signed by TFW key needs be some unique random data 1438 each time. The (UTF-8 encoded) "tid" value from the 1439 GetDeviceStateTBSRequest shall be signed by the firmware. TAM isn't 1440 expected to parse TFW data except the signature validation and signer 1441 trust path validation. 1443 It is possible that a TEE can get some valid TFW signed data from 1444 another device. The TEE is responsible to validate TFW integrity to 1445 ensure that the underlying device firmware is trustworthy. In some 1446 cases, a TEE isn't able to get a TFW signed data, in which case the 1447 TEE trust validation is up to a TAM to decide. A TAM may opt to 1448 trust a TEE basing on the TEE signer and additional information about 1449 a TEE out-of-band. 1451 When TFW signed data is available, a TAM validates the TEE and trusts 1452 that a trusted TEE has carried out appropriate trust check about a 1453 TFW. 1455 TfwData: { 1456 "tbs": "", 1457 "cert": "", 1458 "sigalg": "Signing method", 1459 "sig": "" 1460 } 1462 It is expected that a FW uses standard signature methods for maximal 1463 interoperability with TAM providers. The mandatory support list of 1464 signing algorithm is RSA with SHA256. 1466 The JSON object above is constructed by a TEE with data returned from 1467 the FW. It isn't a standard JSON signed object. The signer 1468 information and data to be signed must be specially processed by a 1469 TAM according to the definition given here. The data to be signed is 1470 the raw data. 1472 9.1.3.1. Supported Firmware Signature Methods 1474 TAM providers shall support the following signature methods. A 1475 firmware provider can choose one of the methods in signature 1476 generation. 1478 o RSA with SHA256 1480 o ECDSA with SHA 256 1482 The value of "sigalg" in the TfwData JSON message SHOULD use one of 1483 the following: 1485 o RS256 1487 o ES256 1489 9.1.4. Post Conditions 1491 Upon successful request validation, the TEE information is collected. 1492 There is no change in the TEE in the device. 1494 The response message shall be encrypted where the encryption key 1495 shall be a symmetric key that is wrapped by TAM's public key. The 1496 JSON Content Encryption Key (CEK) is used for this purpose. 1498 9.1.5. GetDeviceStateResponse Message 1500 The message has the following structure. 1502 { 1503 "GetDeviceTEEStateTBSResponse": { 1504 "ver": "1.0", 1505 "status": "pass | fail", 1506 "rid": "", 1507 "tid": "", 1508 "signerreq": true | false // about whether TAM needs to send 1509 signer data again in subsequent messages, 1510 "edsi": "" 1511 } 1512 } 1514 where 1516 signerreq - true if the TAM should send its signer certificate and 1517 OCSP data again in the subsequent messages. The value may be 1518 "false" if the TEE caches the TAM's signer certificate and OCSP 1519 status. 1521 rid - the request ID from the request message 1523 tid - the tid from the request message 1525 edsi - the main data element whose value is JSON encrypted message 1526 over the following Device State Information (DSI). 1528 The Device State Information (DSI) message consists of the following. 1530 { 1531 "dsi": { 1532 "tfwdata": { 1533 "tbs": "" 1534 "cert": "", 1535 "sigalg": "Signing method", 1536 "sig": "" 1537 }, 1538 "tee": { 1539 "name": "", 1540 "ver": "", 1541 "cert": "", 1542 "cacert": "", 1544 "sdlist": { 1545 "cnt": "", 1546 "sd": [ 1547 { 1548 "name": "", 1549 "spid": "", 1550 "talist": [ 1551 { 1552 "taid": "", 1553 "taname": "" // optional 1555 } 1556 ] 1557 } 1558 ] 1559 }, 1560 "teeaiklist": [ 1561 { 1562 "spaik": "", 1563 "spaiktype": "", 1564 "spid": "" 1565 } 1566 ] 1567 } 1568 } 1569 } 1571 The encrypted JSON message looks like the following. 1573 { 1574 "protected": "", 1576 "recipients": [ 1577 { 1578 "header": { 1579 "alg": "RSA1_5" 1580 }, 1581 "encrypted_key": "" 1582 } 1583 ], 1584 "iv": "", 1585 "ciphertext": "", 1587 "tag": "" 1588 } 1590 Assume we encrypt plaintext with AES 128 in CBC mode with HMAC SHA 1591 256 for integrity, the encryption algorithm header is: 1593 {"enc":"A128CBC-HS256"} 1595 The value of the property "protected" in the above JWE message will 1596 be 1598 eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0 1600 In other words, the above message looks like the following: 1602 { 1603 "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0", 1604 "recipients": [ 1605 { 1606 "header": { 1607 "alg": "RSA1_5" 1608 }, 1609 "encrypted_key": "" 1610 } 1611 ], 1612 "iv": "", 1613 "ciphertext": "", 1615 "tag": "" 1616 } 1618 The full response message looks like the following: 1620 { 1621 "GetDeviceTEEStateTBSResponse": { 1622 "ver": "1.0", 1623 "status": "pass | fail", 1624 "rid": "", 1625 "tid": "", 1626 "signerreq": "true | false", 1627 "edsi": { 1628 "protected": "", 1630 "recipients": [ 1631 { 1632 "header": { 1633 "alg": "RSA1_5" 1634 }, 1635 "encrypted_key": "" 1636 } 1637 ], 1638 "iv": "", 1639 "ciphertext": "", 1641 "tag": "" 1642 } 1643 } 1644 } 1646 The CEK will be encrypted by the TAM public key in the device. The 1647 TEE signed message has the following structure. 1649 { 1650 "GetDeviceTEEStateResponse": { 1651 "payload": "", 1653 "protected": "", 1654 "signature": "" 1655 } 1656 } 1658 The signing algorithm shall use SHA256 with respective key type, see 1659 Section 7.5.1. 1661 The final GetDeviceStateResponse response message consists of an 1662 array of TEE responses. 1664 { 1665 "GetDeviceStateResponse": [ // JSON array 1666 {"GetDeviceTEEStateResponse": ...}, 1667 ... 1668 {"GetDeviceTEEStateResponse": ...} 1669 ] 1670 } 1672 9.1.6. Error Conditions 1674 An error may occur if a request isn't valid or the TEE runs into some 1675 error. The list of possible error conditions is the following. 1677 ERR_REQUEST_INVALID The TEE meets the following conditions with a 1678 request message: (1) The request from a TAM has an invalid message 1679 structure; mandatory information is absent in the message; or an 1680 undefined member or structure is included. (2) TEE fails to verify 1681 the signature of the message or fails to decrypt its contents. 1683 ERR_UNSUPPORTED_MSG_VERSION The TEE receives a version of message 1684 that the TEE can't deal with. 1686 ERR_UNSUPPORTED_CRYPTO_ALG The TEE receives a request message 1687 encoded with a cryptographic algorithm that the TEE doesn't 1688 support. 1690 ERR_TFW_NOT_TRUSTED The TEE considers the underlying device firmware 1691 be not trustworthy. 1693 ERR_TAM_NOT_TRUSTED The TEE needs to make sure whether the TAM is 1694 trustworthy by checking the validity of the TAM certificate and 1695 OCSP stapling data and so on. If the TEE finds the TAM is not 1696 reliable, it returns this error code. 1698 ERR_TEE_FAIL If the TEE fails to process a request because of its 1699 internal error but is able to sign an error response message, it 1700 will return this error code. 1702 ERR_AGENT_TEE_FAIL The TEE failed to respond to a TAM request. The 1703 OTrP Agent will construct an error message in responding to the 1704 TAM's request. The error message will not be signed. 1706 The response message will look like the following if the TEE signing 1707 can work to sign the error response message. 1709 { 1710 "GetDeviceTEEStateTBSResponse": { 1711 "ver": "1.0", 1712 "status": "fail", 1713 "rid": "", 1714 "tid": "", 1715 "reason": {"error-code":""} 1716 "supportedsigalgs": [] 1718 } 1719 } 1721 where 1723 supportedsigalgs - an optional property to list the JWS signing 1724 algorithms that the active TEE supports. When a TAM sends a 1725 signed message that the TEE isn't able to validate, it can 1726 include signature algorithms that it is able to consume in this 1727 status report. A TAM can generate a new request message to retry 1728 the management task with a TEE-supported signing algorithm. 1730 If the TEE isn't able to sign an error message due to an internal 1731 device error, a general error message should be returned by the OTrP 1732 Agent. 1734 9.1.7. TAM Processing Requirements 1736 Upon receiving a GetDeviceStateResponse message at a TAM, the TAM 1737 MUST validate the following. 1739 o Parse to get list of GetDeviceTEEStateResponse JSON objects 1741 o Parse the JSON "payload" property and decrypt the JSON element 1742 "edsi". The decrypted message contains the TEE signer 1743 certificate. 1745 o Validate the GetDeviceTEEStateResponse JSON signature. The signer 1746 certificate is extracted from the decrypted message in the last 1747 step. 1749 o Extract TEE information and check it against its TEE acceptance 1750 policy. 1752 o Extract the TFW signed element, and check the signer and data 1753 integration against its TFW policy. 1755 o Check the SD list and TA list and prepare for a subsequent command 1756 such as "CreateSD" if it needs to have a new SD for an SP. 1758 9.2. Security Domain Management 1760 9.2.1. CreateSD 1762 This command is typically preceded with a GetDeviceState command that 1763 has acquired the device information of the target device by the TAM. 1764 The TAM sends such a command to instruct a TEE to create a new 1765 Security Domain for an SP. 1767 A TAM sends an OTrP CreateSDRequest Request message to a device TEE 1768 to create a Security Domain for an SP. Such a request is signed by 1769 the TAM where the TAM signer may or may not be the same as the SP's 1770 TA signer certificate. The resulting SD is associated with two 1771 identifiers for future management: 1773 o TAM as the owner. The owner identifier is a registered unique TAM 1774 ID that is stored in the TAM certificate. 1776 o SP identified by its TA signer certificate as the authorization. 1777 A TAM can add more than one SP certificate to an SD. 1779 A Trusted Application that is signed by a matching SP signer 1780 certificate for an SD is eligible to be installed into that SD. The 1781 TA installation into an SD by a subsequent InstallTARequest message 1782 may be instructed from a TAM. 1784 9.2.1.1. CreateSDRequest Message 1785 The request message for CreateSD has the following JSON format. 1787 { 1788 "CreateSDTBSRequest": { 1789 "ver": "1.0", 1790 "rid": "", 1791 "tid": "", // this may be from prior message 1792 "tee": "", 1793 "nextdsi": true | false, 1794 "dsihash": "", 1795 "content": ENCRYPTED { // this piece of JSON data will be 1796 // encrypted 1797 "spid": "", 1798 "sdname": "", 1799 "spcert": "", 1800 "tamid": "", 1802 "did": "" 1803 } 1804 } 1805 } 1807 In the message, 1809 rid - A unique value to identify this request 1811 tid - A unique value to identify this transaction. It can have the 1812 same value for the tid in the preceding GetDeviceStateRequest. 1814 tee - TEE ID returned from the previous GetDeviceStateResponse. 1816 nextdsi - Indicates whether the up-to-date Device State Information 1817 (DSI) is expected in the response from the TEE to this request. 1819 dsihash - The BASE64-encoded SHA256 hash value of the DSI data 1820 returned in the prior TAM operation with this target TEE. This 1821 value is always included such that a receiving TEE can check 1822 whether the device state has changed since its last query. It 1823 helps enforce SD update order in the right sequence without 1824 accidentally overwriting an update that was done simultaneously. 1826 content - The "content" is a JSON encrypted message that includes 1827 actual input for the SD creation. The encryption key is TAMmk that 1828 is encrypted by the target TEE's public key. The entire message is 1829 signed by the TAM private key TAMpriv. A separate TAMmk isn't used 1830 in the latest specification because JSON encryption will use a 1831 content encryption key for exactly the same purpose. 1833 spid - A unique id assigned by the TAM for its SP. It should be 1834 unique within a TAM namespace. 1836 sdname - a name unique to the SP. TAM should ensure it is unique 1837 for each SP. 1839 spcert - The SP's TA signer certificate is included in the request. 1840 This certificate will be stored by the device TEE which uses it to 1841 check against TA installation. Only if a TA is signed by a 1842 matching spcert associated with an SD will the TA be installed into 1843 the SD. 1845 tamid - SD owner claim by TAM - an SD owned by a TAM will be 1846 associated with a trusted identifier defined as an attribute in the 1847 signer TAM certificate. TEE will be responsible to assign this ID 1848 to the SD. The TAM certificate attribute for this attribute tamid 1849 MUST be vetted by the TAM signer issuing CA. With this trusted 1850 identifier, the SD query at TEE can be fast upon TAM signer 1851 verification. 1853 did - The SHA256 hash of the binary-encoded device TEE certificate. 1854 The encryption key CEK will be encrypted the recipient TEE's public 1855 key. This hash value in the "did" property allows the recipient 1856 TEE to check whether it is the expected target to receive such a 1857 request. If this isn't given, an OTrP message for device 2 could 1858 be sent to device 1. It is optional for the TEE to check because 1859 the successful decryption of the request message with this device's 1860 TEE private key already proves it is the target. This explicit 1861 hash value makes the protocol not dependent on message encryption 1862 method in future. 1864 A CreateSDTBSRequest message is signed to generate a final 1865 CreateSDRequest message as follows. 1867 { 1868 "CreateSDRequest": { 1869 "payload": "", 1870 "protected": "", 1871 "header": "", 1872 "signature": "" 1873 } 1874 } 1876 The TAM signer certificate is included in the "header" property. 1878 9.2.1.2. Request Processing Requirements at a TEE 1880 Upon receiving a CreateSDRequest request message at a TEE, the TEE 1881 MUST do the following: 1883 1. Validate the JSON request message as follows 1885 * Validate JSON message signing. 1887 * Validate that the request TAM certificate is chained to a 1888 trusted CA that the TEE embeds as its trust anchor. 1890 * Compare dsihash with its current state to make sure nothing 1891 has changed since this request was sent. 1893 * Decrypt to get the plaintext of the content: (a) spid, (b) sd 1894 name, (c) did. 1896 * Check that an SPID is supplied. 1898 * spcert check: check it is a valid certificate (signature and 1899 format verification only). 1901 * Check "did" is the SHA256 hash of its TEEcert BER raw binary 1902 data. 1904 * Check whether the requested SD already exists for the SP. 1906 * Check that the tamid in the request matches the TAM 1907 certificate's TAM ID attribute. 1909 2. If the request was valid, create action 1911 * Create an SD for the SP with the given name. 1913 * Assign the tamid from the TAMCert to this SD. 1915 * Assign the SPID and SPCert to this SD. 1917 * Check whether a TEE SP AIK key pair already exists for the 1918 given SP ID. 1920 * Create TEE SP AIK key pair if it doesn't exist for the given 1921 SP ID. 1923 * Generate new DSI data if the request asks for updated DSI. 1925 3. Construct a CreateSDResponse message 1926 * Create raw content 1928 + Operation status 1930 + "did" or full signer certificate information, 1932 + TEE SP AIK public key if DSI isn't going to be included 1934 + Updated DSI data if requested 1936 * The response message is encrypted with the same JWE CEK of the 1937 request without recreating a new content encryption key. 1939 * The encrypted message is signed with TEEpriv. The signer 1940 information ("did" or TEEcert) is encrypted. 1942 4. Deliver the response message. (a) The OTrP Agent returns this to 1943 the Client Application; (b) The Client App passes this back to 1944 the TAM. 1946 5. TAM processing. (a) The TAM processes the response message; (b) 1947 the TAM can look up signer certificate from the device ID "did". 1949 If a request is illegitimate or signature doesn't pass, a "status" 1950 property in the response will indicate the error code and cause. 1952 9.2.1.3. CreateSDResponse Message 1954 The response message for a CreateSDRequest contains the following 1955 content. 1957 { 1958 "CreateSDTBSResponse": { 1959 "ver": "1.0", 1960 "status": "", 1961 "rid": "", 1962 "tid": "", 1963 "content": ENCRYPTED { 1964 "reason": "", // optional 1965 "did": "", 1966 "sdname": "", 1967 "teespaik": "", 1968 "dsi": "" 1970 } 1971 } 1972 } 1973 In the response message, the following fields MUST be supplied. 1975 did - The SHA256 hash of the device TEE certificate. This shows 1976 the device ID explicitly to the receiving TAM. 1978 teespaik - The newly generated SP AIK public key for the given SP. 1979 This is an optional value if the device has had another domain for 1980 the SP that has triggered TEE SP AIK key pair for this specific SP. 1982 There is a possible extreme error case where the TEE isn't reachable 1983 or the TEE final response generation itself fails. In this case, the 1984 TAM might still receive a response from the OTrP Agent if the OTrP 1985 Agent is able to detect such error from TEE. In this case, a general 1986 error response message should be returned by the OTrP Agent, assuming 1987 OTrP Agent even doesn't know any content and information about the 1988 request message. 1990 In other words, the TAM should expect to receive a TEE successfully 1991 signed JSON message, a general "status" message, or none when a 1992 client experiences a network error. 1994 { 1995 "CreateSDResponse": { 1996 "payload": "", 1997 "protected": { 1998 "" 1999 }, 2000 "signature": "" 2002 } 2003 } 2005 A response message type "status" will be returned when the TEE fails 2006 to respond. The OTrP Agent is responsible to create this message. 2008 { 2009 "status": { 2010 "result": "fail", 2011 "error-code": "ERR_AGENT_TEE_FAIL", 2012 "error-message": "TEE fails to respond" 2013 } 2014 } 2016 9.2.1.4. Error Conditions 2018 An error might occur if a request isn't valid or the TEE runs into 2019 some error. The list of possible errors are as follows. Refer to 2020 the Error Code List (Section 13.1) for detailed causes and actions. 2022 ERR_AGENT_TEE_BUSY 2024 ERR_AGENT_TEE_FAIL 2026 ERR_AGENT_TEE_UNKNOWN 2028 ERR_REQUEST_INVALID 2030 ERR_UNSUPPORTED_MSG_VERSION 2032 ERR_UNSUPPORTED_CRYPTO_ALG 2034 ERR_DEV_STATE_MISMATCH 2036 ERR_SD_ALREADY_EXIST 2038 ERR_SD_NOT_FOUND 2040 ERR_SPCERT_INVALID 2042 ERR_TEE_FAIL 2044 ERR_TAM_NOT_AUTHORIZED 2046 ERR_TAM_NOT_TRUSTED 2048 9.2.2. UpdateSD 2050 This TAM initiated command can update an SP's SD that it manages for 2051 any of the following needs: (a) Update an SP signer certificate; (b) 2052 Add an SP signer certificate when an SP uses multiple to sign TA 2053 binaries; (c) Update an SP ID. 2055 The TAM presents the proof of the SD ownership to the TEE, and 2056 includes related information in its signed message. The entire 2057 request is also encrypted for end-to-end confidentiality. 2059 9.2.2.1. UpdateSDRequest Message 2060 The UpdateSD request message has the following JSON format. 2062 { 2063 "UpdateSDTBSRequest": { 2064 "ver": "1.0", 2065 "rid": "", 2066 "tid": "", // this may be from prior message 2067 "tee": "", 2068 "nextdsi": true | false, 2069 "dsihash": "", 2070 "content": ENCRYPTED { // this piece of JSON will be encrypted 2071 "tamid": "", 2072 "spid": "", 2073 "sdname": "", 2074 "changes": { 2075 "newsdname": "", 2076 // Optional 2077 "newspid": "", 2078 // Optional 2079 "spcert": [""], 2080 // Optional 2081 "deloldspcert": [""], 2083 // Optional 2084 "renewteespaik": true | false 2085 } 2086 } 2087 } 2088 } 2090 In the message, 2092 rid - A unique value to identify this request 2094 tid - A unique value to identify this transaction. It can have the 2095 same value as the tid in the preceding GetDeviceStateRequest. 2097 tee - TEE ID returned from the previous GetDeviceStateResponse 2099 nextdsi - Indicates whether the up-to-date Device State Information 2100 (DSI) is expected to be returned in the response from the TEE to 2101 this request. 2103 dsihash - The BASE64-encoded SHA256 hash value of the DSI data 2104 returned in the prior TAM operation with this target TEE. This 2105 value is always included such that a receiving TEE can check 2106 whether the device state has changed since its last query. It 2107 helps enforce SD update order in the right sequence without 2108 accidentally overwriting an update that was done simultaneously. 2110 content - The "content" is a JSON encrypted message that includes 2111 actual input for the SD update. The standard JSON content 2112 encryption key (CEK) is used, and the CEK is encrypted by the 2113 target TEE's public key. 2115 tamid - SD owner claim by TAM - an SD owned by a TAM will be 2116 associated with a trusted identifier defined as an attribute in the 2117 signer TAM certificate. 2119 spid - the identifier of the SP whose SD will be updated. This 2120 value is still needed because the SD name is considered unique only 2121 within an SP. 2123 sdname - the name of the target SD to be updated. 2125 changes - its content consists of changes are to be updated in the 2126 given SD. 2128 newsdname - the new name of the target SD to be assigned if this 2129 value is present. 2131 newspid - the new SP ID of the target SD to be assigned if this 2132 value is present. 2134 spcert - a new TA signer certificate of this SP to be added to the 2135 SD if this is present. 2137 deloldspcert - an SP certificate assigned into the SD is to be 2138 deleted if this is present. The value is the SHA256 fingerprint of 2139 the old SP certificate. 2141 renewteespaik - the value should be true or false. If it is present 2142 and the value is true, the TEE MUST regenerate TEE SP AIK for this 2143 SD's owner SP. The newly generated TEE SP AIK for the SP must be 2144 returned in the response message of this request. If there is more 2145 than one SD for the SP, a new SPID for one of the domains will 2146 always trigger a new teespaik generation as if a new SP were 2147 introduced to the TEE. 2149 The UpdateSDTBSRequest message is signed to generate the final 2150 UpdateSDRequest message. 2152 { 2153 "UpdateSDRequest": { 2154 "payload": "", 2155 "protected": "", 2156 "header": "", 2157 "signature":"" 2158 } 2159 } 2161 TAM signer certificate is included in the "header" property. 2163 9.2.2.2. Request Processing Requirements at a TEE 2165 Upon receiving a request message UpdateSDRequest at a TEE, the TEE 2166 must validate a request: 2168 1. Validate the JSON request message 2170 * Validate JSON message signing 2172 * Validate that the request TAM certificate is chained to a 2173 trusted CA that the TEE embeds as its trust anchor.The TAM 2174 certificate status check is generally not needed anymore in 2175 this request. The prior request should have validated the TAM 2176 certificate's revocation status. 2178 * Compare dsihash with the TEE cached last response DSI data to 2179 this TAM. 2181 * Decrypt to get the plaintext of the content. 2183 * Check that the target SD name is supplied. 2185 * Check whether the requested SD exists. 2187 * Check that the TAM owns this TAM by verifying tamid in the SD 2188 matches TAM certificate's TAM ID attribute. 2190 * Now the TEE is ready to carry out update listed in the 2191 "content" message. 2193 2. If the request is valid, update action 2195 * If "newsdname" is given, replace the SD name for the SD to the 2196 new value 2198 * If "newspid" is given, replace the SP ID assigned to this SD 2199 with the given new value 2201 * If "spcert" is given, add this new SP certificate to the SD. 2203 * If "deloldspcert" is present in the content, check previously 2204 assigned SP certificates to this SD, and delete the one that 2205 matches the given certificate hash value. 2207 * If "renewteespaik" is given and has a value of 'true', 2208 generate a new TEE SP AIK key pair, and replace the old one 2209 with this. 2211 * Generate new DSI data if the request asks for updated DSI 2213 * Now the TEE is ready to construct the response message 2215 3. Construct UpdateSDResponse message 2217 * Create raw content 2219 + Operation status 2221 + "did" or full signer certificate information, 2223 + TEE SP AIK public key if DSI isn't going to be included 2225 + Updated DSI data if requested 2227 * The response message is encrypted with the same JWE CEK of the 2228 request without recreating a new content encryption key. 2230 * The encrypted message is signed with TEEpriv. The signer 2231 information ("did" or TEEcert) is encrypted. 2233 4. Deliver response message. (a) The OTrP Agent returns this to the 2234 app; (b) The app passes this back to the TAM. 2236 5. TAM processing. (a) The TAM processes the response message; (b) 2237 The TAM can look up the signer certificate from the device ID 2238 "did". 2240 If a request is illegitimate or the signature doesn't pass, a 2241 "status" property in the response will indicate the error code and 2242 cause. 2244 9.2.2.3. UpdateSDResponse Message 2246 The response message for a UpdateSDRequest contains the following 2247 content. 2249 { 2250 "UpdateSDTBSResponse": { 2251 "ver": "1.0", 2252 "status": "", 2253 "rid": "", 2254 "tid": "", 2255 "content": ENCRYPTED { 2256 "reason": "", // optional 2257 "did": "", 2258 "cert": "", // optional 2259 "teespaik": "", 2260 "teespaiktype": "", 2261 "dsi": "" 2263 } 2264 } 2265 } 2267 In the response message, the following fields MUST be supplied. 2269 did - The request should have known the signer certificate of this 2270 device from a prior request. This hash value of the device TEE 2271 certificate serves as a quick identifier only. A full device 2272 certificate isn't necessary. 2274 teespaik - the newly generated SP AIK public key for the given SP 2275 if the TEE SP AIK for the SP is asked to be renewed in the request. 2276 This is an optional value if "dsi" is included in the response, 2277 which will contain all up-to-date TEE SP AIK key pairs. 2279 Similar to the template for the creation of the encrypted and signed 2280 CreateSDResponse, the final UpdateSDResponse looks like the 2281 following. 2283 { 2284 "UpdateSDResponse": { 2285 "payload": "", 2286 "protected": { 2287 "" 2288 }, 2289 "signature": "" 2291 } 2292 } 2294 A response message type "status" will be returned when the TEE fails 2295 to respond. The OTrP Agent is responsible to create this message. 2297 { 2298 "status": { 2299 "result": "fail", 2300 "error-code": "ERR_AGENT_TEE_FAIL", 2301 "error-message": "" 2302 } 2303 } 2305 9.2.2.4. Error Conditions 2307 An error may occur if a request isn't valid or the TEE runs into some 2308 error. The list of possible errors are as follows. Refer to the 2309 Error Code List (Section 13.1) for detailed causes and actions. 2311 ERR_AGENT_TEE_BUSY 2313 ERR_AGENT_TEE_FAIL 2315 ERR_AGENT_TEE_UNKNOWN 2317 ERR_REQUEST_INVALID 2319 ERR_UNSUPPORTED_MSG_VERSION 2321 ERR_UNSUPPORTED_CRYPTO_ALG 2323 ERR_DEV_STATE_MISMATCH 2325 ERR_SD_NOT_FOUND 2327 ERR_SDNAME_ALREADY_USED 2329 ERR_SPCERT_INVALID 2330 ERR_TEE_FAIL 2332 ERR_TAM_NOT_AUTHORIZED 2334 ERR_TAM_NOT_TRUSTED 2336 9.2.3. DeleteSD 2338 A TAM sends a DeleteSDRequest message to a TEE to delete a specified 2339 SD that it owns. An SD can be deleted only if there is no TA 2340 associated with this SD in the device. The request message can 2341 contain a flag to instruct the TEE to delete all related TAs in an SD 2342 and then delete the SD. 2344 The target TEE will operate with the following logic. 2346 1. Look up the given SD specified in the request message 2348 2. Check that the TAM owns the SD 2350 3. Check that the device state hasn't changed since the last 2351 operation 2353 4. Check whether there are TAs in this SD 2355 5. If TA exists in an SD, check whether the request instructs 2356 whether the TA should be deleted. If the request instructs the 2357 TEE to delete TAs, delete all TAs in this SD. If the request 2358 doesn't instruct the TEE to delete TAs, return an error 2359 "ERR_SD_NOT_EMPTY". 2361 6. Delete the SD 2363 7. If this is the last SD of this SP, delete the TEE SP AIK key. 2365 9.2.3.1. DeleteSDRequest Message 2366 The request message for DeleteSD has the following JSON format. 2368 { 2369 "DeleteSDTBSRequest": { 2370 "ver": "1.0", 2371 "rid": "", 2372 "tid": "", // this may be from prior message 2373 "tee": "", 2374 "nextdsi": true | false, 2375 "dsihash": "", 2376 "content": ENCRYPTED { // this piece of JSON will be encrypted 2377 "tamid": "", 2378 "sdname": "", 2379 "deleteta": true | false 2380 } 2381 } 2382 } 2384 In the message, 2386 rid - A unique value to identify this request 2388 tid - A unique value to identify this transaction. It can have the 2389 same value for the tid in the preceding GetDeviceStateRequest. 2391 tee - TEE ID returned from the previous response 2392 GetDeviceStateResponse 2394 nextdsi - Indicates whether the up-to-date Device State Information 2395 (DSI) is to be returned in the response to this request. 2397 dsihash - The BASE64-encoded SHA256 hash value of the DSI data 2398 returned in the prior TAM operation with this target TEE. This 2399 value is always included such that a receiving TEE can check 2400 whether the device state has changed since its last query. It 2401 helps enforce SD update order in the right sequence without 2402 accidentally overwriting an update that was done simultaneously. 2404 content - The "content" is a JSON encrypted message that includes 2405 actual input for the SD update. The standard JSON content 2406 encryption key (CEK) is used, and the CEK is encrypted by the 2407 target TEE's public key. 2409 tamid - SD owner claim by TAM - an SD owned by a TAM will be 2410 associated with a trusted identifier defined as an attribute in the 2411 signer TAM certificate. 2413 sdname - the name of the target SD to be updated. 2415 deleteta - the value should be boolean 'true' or 'false'. If it is 2416 present and the value is 'true', the TEE should delete all TAs 2417 associated with the SD in the device. 2419 According to the OTrP message template, the full request 2420 DeleteSDRequest is a signed message over the DeleteSDTBSRequest as 2421 follows. 2423 { 2424 "DeleteSDRequest": { 2425 "payload": "", 2426 "protected": "", 2427 "header": "", 2428 "signature": "" 2429 } 2430 } 2432 TAM signer certificate is included in the "header" property. 2434 9.2.3.2. Request Processing Requirements at a TEE 2436 Upon receiving a request message DeleteSDRequest at a TEE, the TEE 2437 must validate a request: 2439 1. Validate the JSON request message 2441 * Validate JSON message signing 2443 * Validate that the request TAM certificate is chained to a 2444 trusted CA that the TEE embeds as its trust anchor. The TAM 2445 certificate status check is generally not needed anymore in 2446 this request. The prior request should have validated the TAM 2447 certificate's revocation status. 2449 * Compare dsihash with the TEE cached last response DSI data to 2450 this TAM 2452 * Decrypt to get the plaintext of the content 2454 * Check that the target SD name is supplied 2456 * Check whether the requested SD exists 2458 * Check that the TAM owns this TAM by verifying that the tamid 2459 in the SD matches the TAM certificate's TAM ID attribute 2461 * Now the TEE is ready to carry out the update listed in the 2462 "content" message 2464 2. If the request is valid, deletion action 2466 * Check TA existence in this SD 2468 * If "deleteta" is "true", delete all TAs in this SD. If the 2469 value of "deleteta" is false and some TA exists, return an 2470 error "ERR_SD_NOT_EMPTY" 2472 * Delete the SD 2474 * Delete the TEE SP AIK key pair if this SD is the last one for 2475 the SP 2477 * Now the TEE is ready to construct the response message 2479 3. Construct a DeleteSDResponse message 2481 * Create response content 2483 + Operation status 2485 + "did" or full signer certificate information, 2487 + Updated DSI data if requested 2489 * The response message is encrypted with the same JWE CEK of the 2490 request without recreating a new content encryption key. 2492 * The encrypted message is signed with TEEpriv. The signer 2493 information ("did" or TEEcert) is encrypted. 2495 4. Deliver response message. (a) The OTrP Agent returns this to the 2496 app; (b) The app passes this back to the TAM 2498 5. TAM processing. (a) The TAM processes the response message; (b) 2499 The TAM can look up signer certificate from the device ID "did". 2501 If a request is illegitimate or the signature doesn't pass, a 2502 "status" property in the response will indicate the error code and 2503 cause. 2505 9.2.3.3. DeleteSDResponse Message 2507 The response message for a DeleteSDRequest contains the following 2508 content. 2510 { 2511 "DeleteSDTBSResponse": { 2512 "ver": "1.0", 2513 "status": "", 2514 "rid": "", 2515 "tid": "", 2516 "content": ENCRYPTED { 2517 "reason": "", // optional 2518 "did": "", 2519 "dsi": "" 2521 } 2522 } 2523 } 2525 In the response message, the following fields MUST be supplied. 2527 did - The request should have known the signer certificate of this 2528 device from a prior request. This hash value of the device TEE 2529 certificate serves as a quick identifier only. A full device 2530 certificate isn't necessary. 2532 The final DeleteSDResponse looks like the following. 2534 { 2535 "DeleteSDResponse": { 2536 "payload": "", 2537 "protected": { 2538 "" 2539 }, 2540 "signature": "" 2542 } 2543 } 2545 A response message type "status" will be returned when the TEE fails 2546 to respond. The OTrP Agent is responsible to create this message. 2548 { 2549 "status": { 2550 "result": "fail", 2551 "error-code": "ERR_AGENT_TEE_FAIL", 2552 "error-message": "TEE fails to respond" 2553 } 2554 } 2556 9.2.3.4. Error Conditions 2558 An error may occur if a request isn't valid or the TEE runs into some 2559 error. The list of possible errors is as follows. Refer to the 2560 Error Code List (Section 13.1) for detailed causes and actions. 2562 ERR_AGENT_TEE_BUSY 2564 ERR_AGENT_TEE_FAIL 2566 ERR_AGENT_TEE_UNKNOWN 2568 ERR_REQUEST_INVALID 2570 ERR_UNSUPPORTED_MSG_VERSION 2572 ERR_UNSUPPORTED_CRYPTO_ALG 2574 ERR_DEV_STATE_MISMATCH 2576 ERR_SD_NOT_EMPTY 2578 ERR_SD_NOT_FOUND 2580 ERR_TEE_FAIL 2582 ERR_TAM_NOT_AUTHORIZED 2584 ERR_TAM_NOT_TRUSTED 2586 9.3. Trusted Application Management 2588 This protocol doesn't introduce a TA container concept. All TA 2589 authorization and management will be up to the TEE implementation. 2591 The following three TA management commands are supported. 2593 o InstallTA - provision a TA by TAM 2595 o UpdateTA - update a TA by TAM 2597 o DeleteTA - remove TA registration information with an SD, remove 2598 the TA binary and all TA-related data in a TEE 2600 9.3.1. InstallTA 2602 TA binary data and related personalization data if there is any can 2603 be from two sources: 2605 1. A TAM supplies the signed and encrypted TA binary 2607 2. A Client Application supplies the TA binary 2609 This specification primarily considers the first case where a TAM 2610 supplies a TA binary. This is to ensure that a TEE can properly 2611 validate whether a TA is trustworthy. Further, TA personalization 2612 data will be encrypted by the TEE device's SP public key for end-to- 2613 end protection. A Client Application bundled TA case will be 2614 addressed separately later. 2616 A TAM sends the following information in a InstallTARequest message 2617 to a target TEE: 2619 o The target SD information: SP ID and SD name 2621 o Encrypted TA binary data. TA data is encrypted with the TEE SP 2622 AIK. 2624 o TA metadata. It is optional to include the SP signer certificate 2625 for the SD to add if the SP has changed signer since the SD was 2626 created. 2628 The TEE processes the command given by the TAM to install a TA into 2629 an SP's SD. It does the following: 2631 o Validation 2633 * The TEE validates the TAM message authenticity 2635 * Decrypt to get request content 2637 * Look up the SD with the SD name 2639 * Checks that the TAM owns the SD 2641 * Checks that the DSI hash matches which shows that the device 2642 state hasn't changed 2644 o If the request is valid, continue to do the TA validation 2646 * Decrypt to get the TA binary data and any personalization data 2647 with the "TEE SP AIK private key" 2649 * Check that SP ID is the one that is registered with the SP SD 2651 * Check that the TA signer is either a newly given SP certificate 2652 or the one that is already trusted by the SD from the previous 2653 TA installation. The TA signing method is specific to a TEE. 2654 This specification doesn't define how a TA should be signed; a 2655 TAM should support TEE specific TA signing when it supports 2656 that TEE. 2658 * If a TA signer is given in the request, add this signer into 2659 the SD. 2661 o If the above validation passed, continue to do TA installation 2663 * The TEE re-encrypts the TA binary and its personalization data 2664 with its own method. 2666 * The TEE enrolls and stores the TA in a secure storage. 2668 o Construct a response message. This involves signing encrypted 2669 status information for the requesting TAM. 2671 9.3.1.1. InstallTARequest Message 2672 The request message for InstallTA has the following JSON format. 2674 { 2675 "InstallTATBSRequest": { 2676 "ver": "1.0", 2677 "rid": "", 2678 "tid": "", 2679 "tee": "", 2680 "nextdsi": true | false, 2681 "dsihash": "", 2682 "content": ENCRYPTED { 2683 "tamid": "", 2684 "spid": "", 2685 "sdname": "", 2686 "spcert": "", // optional 2687 "taid": "" 2688 }, 2689 "encrypted_ta": { 2690 "key": "", 2692 "iv": "", 2693 "alg": "", 2695 "cipherpdata": "" 2697 } 2698 } 2699 } 2701 In the message, 2703 rid - A unique value to identify this request 2705 tid - A unique value to identify this transaction. It can have the 2706 same value for the tid in the preceding GetDeviceStateRequest. 2708 tee - TEE ID returned from the previous GetDeviceStateResponse 2710 nextdsi - Indicates whether the up-to-date Device State Information 2711 (DSI) is to be returned in the response to this request. 2713 dsihash - The BASE64-encoded SHA256 hash value of the DSI data 2714 returned in the prior TAM operation with this target TEE. This 2715 value is always included such that a receiving TEE can check 2716 whether the device state has changed since its last query. It 2717 helps enforce SD update order in the right sequence without 2718 accidentally overwriting an update that was done simultaneously. 2720 content - The "content" is a JSON encrypted message that includes 2721 actual input for the SD update. The standard JSON content 2722 encryption key (CEK) is used, and the CEK is encrypted by the 2723 target TEE's public key. 2725 tamid - SD owner claim by TAM - An SD owned by a TAM will be 2726 associated with a trusted identifier defined as an attribute in the 2727 signer TAM certificate. 2729 spid - SP identifier of the TA owner SP 2731 sdname - the name of the target SD where the TA is to be installed 2733 spcert - an optional field to specify the SP certificate that signed 2734 the TA. This is sent if the SP has a new certificate that hasn't 2735 been previously registered with the target SD where the TA should 2736 be installed. 2738 taid - the identifier of the TA application to be installed 2740 encrypted_ta - the message portion contains encrypted TA binary data 2741 and personalization data. The TA data encryption key is placed in 2742 "key", which is encrypted by the recipient's public key, using JWE 2743 enveloped structure. The TA data encryption uses symmetric key 2744 based encryption such as AESCBC. 2746 According to the OTrP message template, the full request 2747 InstallTARequest is a signed message over the InstallTATBSRequest as 2748 follows. 2750 { 2751 "InstallTARequest": { 2752 "payload": "", 2753 "protected": "", 2754 "header": "", 2755 "signature": "" 2756 } 2757 } 2759 9.3.1.2. InstallTAResponse Message 2761 The response message for a InstallTARequest contains the following 2762 content. 2764 { 2765 "InstallTATBSResponse": { 2766 "ver": "1.0", 2767 "status": "", 2768 "rid": "", 2769 "tid": "", 2770 "content": ENCRYPTED { 2771 "reason":"", // optional 2772 "did": "", 2773 "dsi": "" 2775 } 2776 } 2777 } 2779 In the response message, the following fields MUST be supplied. 2781 did - the SHA256 hash of the device TEE certificate. This shows 2782 the device ID explicitly to the receiving TAM. 2784 The final message InstallTAResponse looks like the following. 2786 { 2787 "InstallTAResponse": { 2788 "payload":"", 2789 "protected": { 2790 "" 2791 }, 2792 "signature": "" 2794 } 2795 } 2797 A response message type "status" will be returned when the TEE fails 2798 to respond. The OTrP Agent is responsible to create this message. 2800 { 2801 "status": { 2802 "result": "fail", 2803 "error-code": "ERR_AGENT_TEE_FAIL", 2804 "error-message": "TEE fails to respond" 2805 } 2806 } 2808 9.3.1.3. Error Conditions 2810 An error may occur if a request isn't valid or the TEE runs into some 2811 error. The list of possible errors are as follows. Refer to the 2812 Error Code List (Section 13.1) for detailed causes and actions. 2814 ERR_AGENT_TEE_BUSY 2816 ERR_AGENT_TEE_FAIL 2818 ERR_AGENT_TEE_UNKNOWN 2820 ERR_REQUEST_INVALID 2822 ERR_UNSUPPORTED_MSG_VERSION 2824 ERR_UNSUPPORTED_CRYPTO_ALG 2826 ERR_DEV_STATE_MISMATCH 2828 ERR_SD_NOT_FOUND 2830 ERR_TA_INVALID 2832 ERR_TA_ALREADY_INSTALLED 2834 ERR_TEE_FAIL 2836 ERR_TEE_RESOURCE_FULL 2838 ERR_TAM_NOT_AUTHORIZED 2840 ERR_TAM_NOT_TRUSTED 2842 9.3.2. UpdateTA 2844 This TAM-initiated command can update a TA and its data in an SP's SD 2845 that it manages for the following purposes. 2847 1. Update TA binary 2849 2. Update TA's personalization data 2851 The TAM presents the proof of the SD ownership to a TEE, and includes 2852 related information in its signed message. The entire request is 2853 also encrypted for end-to-end confidentiality. 2855 The TEE processes the command from the TAM to update the TA of an SP 2856 SD. It does the following: 2858 o Validation 2860 * The TEE validates the TAM message authenticity 2862 * Decrypt to get request content 2864 * Look up the SD with the SD name 2866 * Checks that the TAM owns the SD 2868 * Checks DSI hash matches that the device state hasn't changed 2870 o TA validation 2872 * Both TA binary and personalization data are optional, but at 2873 least one of them shall be present in the message 2875 * Decrypt to get the TA binary and any personalization data with 2876 the "TEE SP AIK private key" 2878 * Check that SP ID is the one that is registered with the SP SD 2880 * Check that the TA signer is either a newly given SP certificate 2881 or the one in SD. 2883 * If a TA signer is given in the request, add this signer into 2884 the SD. 2886 o If the above validation passes, continue to do TA update 2888 * The TEE re-encrypts the TA binary and its personalization data 2889 with its own method 2891 * The TEE replaces the existing TA binary and its personalization 2892 data with the new binary and data. 2894 o Construct a response message. This involves signing a encrypted 2895 status information for the requesting TAM. 2897 9.3.2.1. UpdateTARequest Message 2898 The request message for UpdateTA has the following JSON format. 2900 { 2901 "UpdateTATBSRequest": { 2902 "ver": "1.0", 2903 "rid": "", 2904 "tid": "", 2905 "tee": "", 2906 "nextdsi": true | false, 2907 "dsihash": "", 2908 "content": ENCRYPTED { 2909 "tamid": "", 2910 "spid": "", 2911 "sdname": "", 2912 "spcert": "", // optional 2913 "taid": "" 2914 }, 2915 "encrypted_ta": { 2916 "key": "", 2918 "iv": "", 2919 "alg": "", 2922 "ciphernewpdata": "" 2924 // optional 2925 } 2926 } 2927 } 2929 In the message, 2931 rid - A unique value to identify this request 2933 tid - A unique value to identify this transaction. It can have the 2934 same value for the tid in the preceding GetDeviceStateRequest. 2936 tee - TEE ID returned from the previous GetDeviceStateResponse 2938 nextdsi - Indicates whether the up-to-date Device State Information 2939 (DSI) is to be returned in the response to this request. 2941 dsihash - The BASE64-encoded SHA256 hash value of the DSI data 2942 returned in the prior TAM operation with this target TEE. This 2943 value is always included such that a receiving TEE can check 2944 whether the device state has changed since its last query. It 2945 helps enforce SD update order in the right sequence without 2946 accidentally overwriting an update that was done simultaneously. 2948 content - The "content" is a JSON encrypted message that includes 2949 actual input for the SD update. The standard JSON content 2950 encryption key (CEK) is used, and the CEK is encrypted by the 2951 target TEE's public key. 2953 tamid - SD owner claim by TAM - an SD owned by a TAM will be 2954 associated with a trusted identifier defined as an attribute in the 2955 signer TAM certificate. 2957 spid - SP identifier of the TA owner SP 2959 spcert - an optional field to specify the SP certificate that signed 2960 the TA. This is sent if the SP has a new certificate that hasn't 2961 been previously registered with the target SD where the TA is to be 2962 installed. 2964 sdname - the name of the target SD where the TA should be updated 2966 taid - an identifier for the TA application to be updated 2968 encrypted_ta - the message portion contains newly encrypted TA 2969 binary data and personalization data. 2971 According to the OTrP message template, the full request 2972 UpdateTARequest is a signed message over the UpdateTATBSRequest as 2973 follows. 2975 { 2976 "UpdateTARequest": { 2977 "payload": "", 2978 "protected": "", 2979 "header": "", 2980 "signature": "" 2981 } 2982 } 2984 9.3.2.2. UpdateTAResponse Message 2986 The response message for a UpdateTARequest contains the following 2987 content. 2989 { 2990 "UpdateTATBSResponse": { 2991 "ver": "1.0", 2992 "status": "", 2993 "rid": "", 2994 "tid": "", 2995 "content": ENCRYPTED { 2996 "reason": "", // optional 2997 "did": "", 2998 "dsi": "" 3000 } 3001 } 3002 } 3004 In the response message, the following fields MUST be supplied. 3006 did - the SHA256 hash of the device TEE certificate. This shows 3007 the device ID explicitly to the receiving TAM. 3009 The final message UpdateTAResponse looks like the following. 3011 { 3012 "UpdateTAResponse": { 3013 "payload":"", 3014 "protected": { 3015 "" 3016 }, 3017 "signature": "" 3019 } 3020 } 3022 A response message type "status" will be returned when the TEE fails 3023 to respond. The OTrP Agent is responsible to create this message. 3025 { 3026 "status": { 3027 "result": "fail", 3028 "error-code": "ERR_AGENT_TEE_FAIL", 3029 "error-message": "TEE fails to respond" 3030 } 3031 } 3033 9.3.2.3. Error Conditions 3035 An error may occur if a request isn't valid or the TEE runs into some 3036 error. The list of possible errors are as follows. Refer to the 3037 Error Code List (Section 13.1) for detailed causes and actions. 3039 ERR_AGENT_TEE_BUSY 3041 ERR_AGENT_TEE_FAIL 3043 ERR_AGENT_TEE_UNKNOWN 3045 ERR_REQUEST_INVALID 3047 ERR_UNSUPPORTED_MSG_VERSION 3049 ERR_UNSUPPORTED_CRYPTO_ALG 3051 ERR_DEV_STATE_MISMATCH 3053 ERR_SD_NOT_FOUND 3055 ERR_TA_INVALID 3057 ERR_TA_NOT_FOUND 3059 ERR_TEE_FAIL 3061 ERR_TAM_NOT_AUTHORIZED 3063 ERR_TAM_NOT_TRUSTED 3065 9.3.3. DeleteTA 3067 This operation defines OTrP messages that allow a TAM to instruct a 3068 TEE to delete a TA for an SP in a given SD. A TEE will delete a TA 3069 from an SD and also TA data in the TEE. A Client Application cannot 3070 directly access TEE or OTrP Agent to delete a TA. 3072 9.3.3.1. DeleteTARequest Message 3073 The request message for DeleteTA has the following JSON format. 3075 { 3076 "DeleteTATBSRequest": { 3077 "ver": "1.0", 3078 "rid": "", 3079 "tid": "", 3080 "tee": "", 3081 "nextdsi": true | false, 3082 "dsihash": "", 3083 "content": ENCRYPTED { 3084 "tamid": "", 3085 "sdname": "", 3086 "taid": "" 3088 } 3089 } 3090 } 3092 In the message, 3094 rid - A unique value to identify this request 3096 tid - A unique value to identify this transaction. It can have the 3097 same value for the tid in the preceding GetDeviceStateRequest. 3099 tee - The TEE ID returned from the previous GetDeviceStateResponse 3101 nextdsi - Indicates whether the up-to-date Device State Information 3102 (DSI) is to be returned in the response to this request. 3104 dsihash - The BASE64-encoded SHA256 hash value of the DSI data 3105 returned in the prior TAM operation with this target TEE. This 3106 value is always included such that a receiving TEE can check 3107 whether the device state has changed since its last query. It 3108 helps enforce SD update order in the right sequence without 3109 accidentally overwriting an update that was done simultaneously. 3111 content - The "content" is a JSON encrypted message that includes 3112 actual input for the SD update. The standard JSON content 3113 encryption key (CEK) is used, and the CEK is encrypted by the 3114 target TEE's public key. 3116 tamid - SD owner claim by TAM - an SD owned by a TAM will be 3117 associated with a trusted identifier defined as an attribute in the 3118 signer TAM certificate. 3120 sdname - the name of the target SD where the TA is installed 3121 taid - an identifier for the TA application to be deleted 3123 According to the OTrP message template, the full request 3124 DeleteTARequest is a signed message over the DeleteTATBSRequest as 3125 follows. 3127 { 3128 "DeleteTARequest": { 3129 "payload": "", 3130 "protected": "", 3131 "header": "", 3132 "signature": "" 3134 } 3135 } 3137 9.3.3.2. Request Processing Requirements at a TEE 3139 A TEE processes a command from a TAM to delete a TA of an SP SD. It 3140 does the following: 3142 1. Validate the JSON request message 3144 * The TEE validates TAM message authenticity 3146 * Decrypt to get request content 3148 * Look up the SD and the TA with the given SD name and TA ID 3150 * Checks that the TAM owns the SD, and TA is installed in the SD 3152 * Checks that the DSI hash matches and the the device state 3153 hasn't changed 3155 2. Deletion action 3157 * If all the above validation points pass, the TEE deletes the 3158 TA from the SD 3160 * The TEE SHOULD also delete all personalization data for the TA 3162 3. Construct DeleteTAResponse message. 3164 If a request is illegitimate or the signature doesn't pass, a 3165 "status" property in the response will indicate the error code and 3166 cause. 3168 9.3.3.3. DeleteTAResponse Message 3170 The response message for a DeleteTARequest contains the following 3171 content. 3173 { 3174 "DeleteTATBSResponse": { 3175 "ver": "1.0", 3176 "status": "", 3177 "rid": "", 3178 "tid": "", 3179 "content": ENCRYPTED { 3180 "reason": "", // optional 3181 "did": "", 3182 "dsi": "" 3184 } 3185 } 3186 } 3188 In the response message, the following fields MUST be supplied. 3190 did - the SHA256 hash of the device TEE certificate. This shows 3191 the device ID explicitly to the receiving TAM. 3193 The final message DeleteTAResponse looks like the following. 3195 { 3196 "DeleteTAResponse": { 3197 "payload": "", 3198 "protected": { 3199 "" 3200 }, 3201 "signature": "" 3203 } 3204 } 3206 A response message type "status" will be returned when the TEE fails 3207 to respond. The OTrP Agent is responsible to create this message. 3209 { 3210 "status": { 3211 "result": "fail", 3212 "error-code": "ERR_AGENT_TEE_FAIL", 3213 "error-message": "TEE fails to respond" 3214 } 3215 } 3217 9.3.3.4. Error Conditions 3219 An error may occur if a request isn't valid or the TEE runs into some 3220 error. The list of possible errors are as follows. Refer to the 3221 Error Code List (Section 13.1) for detailed causes and actions. 3223 ERR_AGENT_TEE_BUSY 3225 ERR_AGENT_TEE_FAIL 3227 ERR_AGENT_TEE_UNKNOWN 3229 ERR_REQUEST_INVALID 3231 ERR_UNSUPPORTED_MSG_VERSION 3233 ERR_UNSUPPORTED_CRYPTO_ALG 3235 ERR_DEV_STATE_MISMATCH 3237 ERR_SD_NOT_FOUND 3239 ERR_TA_NOT_FOUND 3241 ERR_TEE_FAIL 3243 ERR_TAM_NOT_AUTHORIZED 3245 ERR_TAM_NOT_TRUSTED 3247 10. Response Messages a TAM May Expect 3249 A TAM expects some feedback from a remote device when a request 3250 message is delivered to a device. The following three types of 3251 responses SHOULD be supplied. 3253 Type 1: Expect a valid TEE-generated response message 3255 A valid TEE signed response may contain errors detected by a TEE, 3256 e.g. a TAM is trusted but some TAM-supplied data is missing, for 3257 example, SP ID doesn't exist. TEE MUST be able to sign and 3258 encrypt. 3260 If a TEE isn't able to sign a response, the TEE returns an error 3261 to the OTrP Agent without giving any other internal information. 3262 The OTrP Agent will be generating the response. 3264 Type 2: The OTrP Agent generated error message when TEE fails. 3265 OTrP Agent errors will be defined in this document. 3267 A Type 2 message has the following format. 3269 { 3270 "OTrPAgentError": { 3271 "ver": "1.0", 3272 "rid": "", 3273 "tid": "", 3274 "errcode": "ERR_AGENT_TEE_UNKNOWN | ERR_AGENT_TEE_BUSY" 3275 } 3276 } 3278 Type 3: OTrP Agent itself isn't reachable or fails. A Client 3279 Application is responsible to handle error and respond the TAM in 3280 its own way. This is out of scope for this specification. 3282 11. Basic Protocol Profile 3284 This section describes a baseline for interoperability among the 3285 protocol entities, mainly, the TAM and TEE. 3287 A TEE MUST support RSA algorithms. It is optional to support ECC 3288 algorithms. A TAM SHOULD use a RSA certificate for TAM message 3289 signing. It may use an ECC certificate if it detects that the TEE 3290 supports ECC according to the field "supportedsigalgs" in a TEE 3291 response. 3293 A TAM MUST support both RSA 2048-bit algorithm and ECC P-256 3294 algorithms. With this, a TEE and TFW certificate can be either RSA 3295 or ECC type. 3297 JSON signing algorithms 3299 o RSA PKCS#1 with SHA256 signing : "RS256" 3301 o ECDSA with SHA256 signing : "ES256" 3303 JSON asymmetric encryption algorithms (describes key-exchange or key- 3304 agreement algorithm for sharing symmetric key with TEE): 3306 o RSA PKCS#1 : "RSA1_5" 3308 o ECDH using TEE ECC P-256 key and ephemeral ECC key generated by 3309 TAM : "ECDH-ES+A128W" 3311 JSON symmetric encryption algorithms (describes symmetric algorithm 3312 for encrypting body of data, using symmetric key transferred to TEE 3313 using asymmetric encryption): 3315 o Authenticated encryption AES 128 CBC with SHA256 : 3316 {"enc":"A128CBC-HS256"} 3318 12. Attestation Implementation Consideration 3320 It is important to know that the state of a device is appropriate 3321 before trusting that a device is what it says it is. The attestation 3322 scheme for OTrP must also be able to cope with different TEEs, 3323 including those that are OTrP compliant and those that use another 3324 mechanism. In the initial version, only one active TEE is assumed. 3326 It is out of scope how the TAM and the device implement the trust 3327 hierarchy verification. However, it is helpful to understand what 3328 each system provider should do in order to properly implement an OTrP 3329 trust hierarchy. 3331 In this section, we provide some implementation reference 3332 consideration. 3334 12.1. OTrP Secure Boot Module 3336 12.1.1. Attestation signer 3338 It is proposed that attestation for OTrP is based on the SBM secure 3339 boot layer, and that further attestation is not performed within the 3340 TEE itself during Security Domain operations. The rationale is that 3341 the device boot process will be defined to start with a secure boot 3342 approach that, using eFuse, only releases attestation signing 3343 capabilities into the SBM once a secure boot has been established. 3344 In this way the release of the attestation signer can be considered 3345 the first "platform configuration metric", using Trust Computing 3346 Group (TCG) terminology. 3348 12.1.2. SBM Initial Requirements 3350 R1 The SBM must be possible to load securely into the secure boot 3351 flow 3353 R2 The SBM must allow a public / private key pair to be generated 3354 during device manufacture 3356 R3 The public key and certificate must be possible to store securely 3358 R4 The private key must be possible to store encrypted at rest 3360 R5 The private key must only be visible to the SBM when it is 3361 decrypted 3363 R6 The SBM must be able to read a list of root and intermediate 3364 certificates that it can use to check certificate chains with. 3365 The list must be stored such that it cannot be tampered with 3367 R7 Need to allow a TEE to access its unique TEE specific private key 3369 12.2. TEE Loading 3371 During boot, the SBM is required to start all of the root TEEs. 3372 Before loading them, the SBM must first determine whether the code 3373 sign signature of the TEE is valid. If TEE integrity is confirmed, 3374 the TEE may be started. The SBM must then be able to receive the 3375 identity certificate from the TEE (if that TEE is OTrP compliant). 3376 The identity certificate and keys will need to be baked into the TEE 3377 image, and therefore also covered by the code signer hash during the 3378 manufacturing process. The private key for the identity certificate 3379 must be securely protected. The private key for a TEE identity must 3380 never be released no matter how the public key and certificate are 3381 released to the SBM. 3383 Once the SBM has successfully booted a TEE and retrieved the identity 3384 certificate, the SBM will commit this to the platform configuration 3385 register (PCR) set, for later use during attestation. At minimum, 3386 the following data must be committed to the PCR for each TEE: 3388 1. Public key and certificate for the TEE 3390 2. TEE identifier that can be used later by a TAM to identify this 3391 TEE 3393 12.3. Attestation Hierarchy 3395 The attestation hierarchy and seed required for TAM protocol 3396 operation must be built into the device at manufacture. Additional 3397 TEEs can be added post-manufacture using the scheme proposed, but it 3398 is outside of the current scope of this document to detail that. 3400 It should be noted that the attestation scheme described is based on 3401 signatures. The only encryption that takes place is with eFuse to 3402 release the SBM signing key and later during the protocol lifecycle 3403 management interchange with the TAM. 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, encrypted by eFuse. This key pair will be used for 3411 signing operations performed by the SBM. 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. Secure boot releases the TFW private key by decrypting it with 3426 eFuse 3428 2. The SBM 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 SBM leaves 3431 the TEE public key field blank. 3433 3. The SBM signs the signing buffer with the TFW private key. 3435 4. Each active TEE performs the same operation as the SBM, 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 Agent 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 Agent 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 Agent 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 Agent has a function to allow an 3636 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 Agent Trust Model 3652 An OTrP Agent could be malware in the vulnerable Rich OS. 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 Agent. 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 Agent cannot modify or 3660 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 Agent 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 Agent could replay or send TAM messages out of sequence: 3711 e.g., a TAM sends update1 and update2. The OTrP Agent 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 OEM. 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. 3805 16.2. Informative References 3807 [GPTEE] Global Platform, "Global Platform, GlobalPlatform Device 3808 Technology: TEE System Architecture, v1.0", 2013. 3810 [GPTEECLAPI] 3811 Global Platform, "Global Platform, GlobalPlatform Device 3812 Technology: TEE Client API Specification, v1.0", 2013. 3814 Appendix A. Sample Messages 3816 A.1. Sample Security Domain Management Messages 3818 A.1.1. Sample GetDeviceState 3820 A.1.1.1. Sample GetDeviceStateRequest 3822 The TAM builds a "GetDeviceStateTBSRequest" message. 3824 { 3825 "GetDeviceStateTBSRequest": { 3826 "ver": "1.0", 3827 "rid": "8C6F9DBB-FC39-435c-BC89-4D3614DA2F0B", 3828 "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE", 3829 "ocspdat": "c2FtcGxlIG9jc3BkYXQgQjY0IGVuY29kZWQgQVNOMQ==", 3830 "icaocspdat": "c2FtcGxlIGljYW9jc3BkYXQgQjY0IGVuY29kZWQgQVNOMQ==", 3831 "supportedsigalgs": "RS256" 3832 } 3833 } 3835 The TAM signs "GetDeviceStateTBSRequest", creating 3836 "GetDeviceStateRequest" 3838 { 3839 "GetDeviceStateRequest": { 3840 "payload":" 3841 ewoJIkdldERldmljZVN0YXRlVEJTUmVxdWVzdCI6IHsKCQkidmVyIjogIjEuMCIsCgkJ 3842 InJpZCI6IHs4QzZGOURCQi1GQzM5LTQzNWMtQkM4OS00RDM2MTREQTJGMEJ9LAoJCSJ0 3843 aWQiOiAiezRGNDU0QTdGLTAwMkQtNDE1Ny04ODRFLUIwREQxQTA2QThBRX0iLAoJCSJv 3844 Y3NwZGF0IjogImMyRnRjR3hsSUc5amMzQmtZWFFnUWpZMElHVnVZMjlrWldRZ1FWTk9N 3845 UT09IiwKCQkiaWNhb2NzcGRhdCI6ICJjMkZ0Y0d4bElHbGpZVzlqYzNCa1lYUWdRalkw 3846 SUdWdVkyOWtaV1FnUVZOT01RPT0iLAoJCSJzdXBwb3J0ZWRzaWdhbGdzIjogIlJTMjU2 3847 IgoJfQp9", 3848 "protected": "eyJhbGciOiJSUzI1NiJ9", 3849 "header": { 3850 "x5c": ["ZXhhbXBsZSBBU04xIHNpZ25lciBjZXJ0aWZpY2F0ZQ==", 3851 "ZXhhbXBsZSBBU04xIENBIGNlcnRpZmljYXRl"] 3852 }, 3853 "signature":"c2FtcGxlIHNpZ25hdHVyZQ" 3854 } 3855 } 3857 A.1.1.2. Sample GetDeviceStateResponse 3859 The TAM sends "GetDeviceStateRequest" to the OTrP Agent 3861 The OTrP Agent obtains "dsi" from each TEE. (In this example there 3862 is a single TEE.) 3864 The TEE obtains signed "fwdata" from firmware. 3866 The TEE builds "dsi" - summarizing device state of the TEE. 3868 { 3869 "dsi": { 3870 "tfwdata": { 3871 "tbs": "ezRGNDU0QTdGLTAwMkQtNDE1Ny04ODRFLUIwREQxQTA2QThBRX0=", 3872 "cert": "ZXhhbXBsZSBGVyBjZXJ0aWZpY2F0ZQ==", 3873 "sigalg": "RS256", 3874 "sig": "c2FtcGxlIEZXIHNpZ25hdHVyZQ==" 3875 }, 3876 "tee": { 3877 "name": "Primary TEE", 3878 "ver": "1.0", 3879 "cert": "c2FtcGxlIFRFRSBjZXJ0aWZpY2F0ZQ==", 3880 "cacert": [ 3881 "c2FtcGxlIENBIGNlcnRpZmljYXRlIDE=", 3882 "c2FtcGxlIENBIGNlcnRpZmljYXRlIDI=" 3883 ], 3884 "sdlist": { 3885 "cnt": "1", 3886 "sd": [ 3887 { 3888 "name": "default.acmebank.com", 3889 "spid": "acmebank.com", 3890 "talist": [ 3891 { 3892 "taid": "acmebank.secure.banking", 3893 "taname": "Acme secure banking app" 3894 }, 3895 { 3896 "taid": "acmebank.loyalty.rewards", 3897 "taname": "Acme loyalty rewards app" 3898 } 3899 ] 3900 } 3901 ] 3902 }, 3903 "teeaiklist": [ 3904 { 3905 "spaik": "c2FtcGxlIEFTTjEgZW5jb2RlZCBQS0NTMSBwdWJsaWNrZXk=", 3906 "spaiktype": "RSA", 3907 "spid": "acmebank.com" 3908 } 3909 ] 3910 } 3911 } 3912 } 3914 The TEE encrypts "dsi", and embeds it into a 3915 "GetDeviceTEEStateTBSResponse" message. 3917 { 3918 "GetDeviceTEEStateTBSResponse": { 3919 "ver": "1.0", 3920 "status": "pass", 3921 "rid": "{8C6F9DBB-FC39-435c-BC89-4D3614DA2F0B}", 3922 "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}", 3923 "signerreq":"false", 3924 "edsi": { 3925 "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0K", 3926 "recipients": [ 3927 { 3928 "header": { 3929 "alg": "RSA1_5" 3930 }, 3931 "encrypted_key": 3932 " 3933 QUVTMTI4IChDRUspIGtleSwgZW5jcnlwdGVkIHdpdGggVFNNIFJTQSBwdWJsaWMg 3934 a2V5LCB1c2luZyBSU0ExXzUgcGFkZGluZw" 3935 } 3936 ], 3937 "iv": "ySGmfZ69YlcEilNr5_SGbA", 3938 "ciphertext": 3939 " 3940 c2FtcGxlIGRzaSBkYXRhIGVuY3J5cHRlZCB3aXRoIEFFUzEyOCBrZXkgZnJvbSByZW 3941 NpcGllbnRzLmVuY3J5cHRlZF9rZXk", 3942 "tag": "c2FtcGxlIGF1dGhlbnRpY2F0aW9uIHRhZw" 3943 } 3944 } 3945 } 3947 The TEE signs "GetDeviceTEEStateTBSResponse" and returns it to the 3948 OTrP Agent. The OTrP Agent encodes "GetDeviceTEEStateResponse" into 3949 an array to form "GetDeviceStateResponse". 3951 { 3952 "GetDeviceStateResponse": [ 3953 { 3954 "GetDeviceTEEStateResponse": { 3955 "payload": 3956 " 3957 ewogICJHZXREZXZpY2VURUVTdGF0ZVRCU1Jlc3BvbnNlIjogewogICAgInZlciI6 3958 ICIxLjAiLAogICAgInN0YXR1cyI6ICJwYXNzIiwKICAgICJyaWQiOiAiezhDNkY5 3959 REJCLUZDMzktNDM1Yy1CQzg5LTREMzYxNERBMkYwQn0iLAogICAgInRpZCI6ICJ7 3960 NEY0NTRBN0YtMDAyRC00MTU3LTg4NEUtQjBERDFBMDZBOEFFfSIsCgkic2lnbmVy 3961 cmVxIjoiZmFsc2UiLAogICAgImVkc2kiOiB7CiAgICAgICJwcm90ZWN0ZWQiOiAi 3962 ZXlKbGJtTWlPaUpCTVRJNFEwSkRMVWhUTWpVMkluMEsiLAogICAgICAicmVjaXBp 3963 ZW50cyI6IFsKICAgICAgICB7CiAgICAgICAgICAiaGVhZGVyIjogewogICAgICAg 3964 ICAgImFsZyI6ICJSU0ExXzUiCiAgICAgICAgfSwKICAgICAgICAiZW5jcnlwdGVk 3965 X2tleSI6CiAgICAgICAgIgogICAgICAgIFFVVlRNVEk0SUNoRFJVc3BJR3RsZVN3 3966 Z1pXNWpjbmx3ZEdWa0lIZHBkR2dnVkZOTklGSlRRU0J3ZFdKc2FXTWcKICAgICAg 3967 ICBhMlY1TENCMWMybHVaeUJTVTBFeFh6VWdjR0ZrWkdsdVp3IgogICAgICAgIH0K 3968 ICAgICAgXSwKICAgICAgIml2IjogInlTR21mWjY5WWxjRWlsTnI1X1NHYkEiLAog 3969 ICAgICAiY2lwaGVydGV4dCI6CiAgICAgICIKICAgICAgYzJGdGNHeGxJR1J6YVNC 3970 a1lYUmhJR1Z1WTNKNWNIUmxaQ0IzYVhSb0lFRkZVekV5T0NCclpYa2dabkp2YlNC 3971 eVpXCiAgICAgIE5wY0dsbGJuUnpMbVZ1WTNKNWNIUmxaRjlyWlhrIiwKICAgICAg 3972 InRhZyI6ICJjMkZ0Y0d4bElHRjFkR2hsYm5ScFkyRjBhVzl1SUhSaFp3IgogICAg 3973 fQogIH0KfQ", 3974 "protected": "eyJhbGciOiJSUzI1NiJ9", 3975 "signature": "c2FtcGxlIHNpZ25hdHVyZQ" 3976 } 3977 } 3978 ] 3979 } 3981 The TEE returns "GetDeviceStateResponse" back to the OTrP Agent, 3982 which returns message back to the TAM. 3984 A.1.2. Sample CreateSD 3986 A.1.2.1. Sample CreateSDRequest 3987 { 3988 "CreateSDTBSRequest": { 3989 "ver":"1.0", 3990 "rid":"req-01", 3991 "tid":"tran-01", 3992 "tee":"SecuriTEE", 3993 "nextdsi":"false", 3994 "dsihash":"Iu-c0-fGrpMmzbbtiWI1U8u7wMJE7IK8wkJpsVuf2js", 3995 "content":{ 3996 "spid":"bank.com", 3997 "sdname":"sd.bank.com", 3998 "spcert":"MIIDFjCCAn- 3999 gAwIBAgIJAIk0Tat0tquDMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNVBAYTAkTAMQ4wD 4000 AYDVQQIDAVTZW91bDESMBAGA1UEBwwJR3Vyby1kb25nMRAwDgYDVQQKDAdTb2xhY2l 4001 hMRAwDgYDVQQLDAdTb2xhY2lhMRUwEwYDVQQDDAxTb2xhLWNpYS5jb20wHhcNMTUwN 4002 zAyMDg1MTU3WhcNMjAwNjMwMDg1MTU3WjBsMQswCQYDVQQGEwJLUjEOMAwGA1UECAw 4003 FU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU29sYWNpYTEQMA4GA 4004 1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tMIGfMA0GCSqGSIb3DQE 4005 BAQUAA4GNADCBiQKBgQDYWLrFf2OFMEciwSYsyhaLY4kslaWcXA0hCWJRaFzt5mU- 4006 lpSJ4jeu92inBbsXcI8PfRbaItsgW1TD1Wg4gQH4MX_YtaBoOepE-- 4007 3JoZZyPyCWS3AaLYWrDmqFXdbzaO1i8GxB7zz0gWw55bZ9jyzcl5gQzWSqMRpx_dca 4008 d2SP2wIDAQABo4G_MIG8MIGGBgNVHSMEfzB9oXCkbjBsMQswCQYDVQQGEwJLUjEOMA 4009 wGA1UECAwFU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU29sYWNp 4010 YTEQMA4GA1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tggkAiTRNq3 4011 S2q4MwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0lAQH_BAwwCgYIKwYB 4012 BQUHAwMwDQYJKoZIhvcNAQEFBQADgYEAEFMhRwEQ- 4013 LDa9O7P1N0mcLORpo6fW3QuJfuXbRQRQGoXddXMKazI4VjbGaXhey7Bzvk6TZYDa- 4014 GRiZby1J47UPaDQR3UiDzVvXwCOU6S5yUhNJsW_BeMViYj4lssX28iPpNwLUCVm1QV 4015 THILI6afLCRWXXclc1L5KGY290OwIdQ", 4016 "tamid":"TAM_x.acme.com", 4017 "did":"zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM" 4018 } 4019 } 4020 } 4022 Below is a sample message after the content is encrypted and encoded 4024 { 4025 "CreateSDRequest": { 4026 "payload":" 4027 eyJDcmVhdGVTRFRCU1JlcXVlc3QiOnsidmVyIjoiMS4wIiwicmlkIjoicmVxLTAxIiwidG 4028 lkIjoidHJhbi0wMSIsInRlZSI6IlNlY3VyaVRFRSIsIm5leHRkc2kiOiJmYWxzZSIsImRz 4029 aWhhc2giOiIyMmVmOWNkM2U3YzZhZTkzMjZjZGI2ZWQ4OTYyMzU1M2NiYmJjMGMyNDRlYz 4030 gyYmNjMjQyNjliMTViOWZkYTNiIiwiY29udGVudCI6eyJwcm90ZWN0ZWQiOiJlLUtBbkdW 4031 dVktS0FuVHJpZ0p4Qk1USTRRMEpETFVoVE1qVTI0b0NkZlEiLCJyZWNpcGllbnRzIjpbey 4032 JoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0sImVuY3J5cHRlZF9rZXkiOiJTUzE2NTl4Q2FJ 4033 c1dUeUlsVTZPLUVsZzU4UUhvT1pCekxVRGptVG9vanBaWE54TVpBakRMcWtaSTdEUzhOVG 4034 FIWHcxczFvZjgydVhsM0d6NlVWMkRoZDJ3R2l6Y2VEdGtXc1RwZDg4QVYwaWpEYTNXa3lk 4035 dEpSVmlPOGdkSlEtV29NSUVJRUxzVGthblZCb25wQkF4ZHE0ckVMbl9TZlliaFg4Zm9ub2 4036 gxUVUifV0sIml2IjoiQXhZOERDdERhR2xzYkdsamIzUm9aUSIsImNpcGhlcnRleHQiOiI1 4037 bmVWZXdndm55UXprR3hZeWw5QlFrZTJVNjVaOHp4NDdlb3NzM3FETy0xY2FfNEpFY3NLcj 4038 ZhNjF5QzBUb0doYnJOQWJXbVRSemMwSXB5bTF0ZjdGemp4UlhBaTZBYnVSM2gzSUpRS1Bj 4039 UUVvRUlkZ2tWX0NaZTM2eTBkVDBpRFBMclg0QzFkb0dmMEdvaWViRC1yVUg1VUtEY3BsTW 4040 9lTjZvUnFyd0dnNUhxLTJXM3B4MUlzY0h4SktRZm11dkYxMTJ4ajBmZFNZX0N2WFE1NTJr 4041 TVRDUW1ZbzRPaGF2R0ZvaG9TZVVnaGZSVG1LYWp3OThkTzdhREdrUEpRUlBtYVVHWllEMW 4042 JXd01nMXFRV3RPd19EZlIyZDNzTzVUN0pQMDJDUFprVXBiQ3dZYVcybW9HN1c2Zlc2U3V5 4043 Q2lpd2pQWmZSQmIzSktTVTFTd1kxYXZvdW02OWctaDB6by12TGZvbHRrWFV2LVdPTXZTY0 4044 JzR25NRzZYZnMzbXlTWnJ1WTNRR09wVVRzdjFCQ0JqSTJpdjkwb2U2aXFCcVpxQVBxbzdi 4045 ajYwVlJGQzZPTlNLZExGQTIyU3pqRHo1dmtnTXNEaHkwSzlDeVhYN1Z6MkNLTXJvQjNiUE 4046 xFZF9abTZuVWlkTFN5cVJ5cXJxTmVnN1lmQng3aV93X0dzRW9rX1VYZXd6RGtneHp6RjZj 4047 XzZ6S0s3UFktVnVmYUo0Z2dHZmlpOHEwMm9RZ1VEZTB2Vm1FWDc0c2VQX2RxakVpZVVOYm 4048 xBZE9sS2dBWlFGdEs4dy1xVUMzSzVGTjRoUG9yeDc2b3lPVUpOQTVFZVV2Qy1jR2tMcTNQ 4049 UG1GRmQyaUtOTElCTEJzVWl6c1h3RERvZVA5SmktWGt5ZEQtREN1SHdpcno0OEdNNWVLSj 4050 Q5WVdqRUtFQko2T01NNUNmZHZ4cDNmVG1uUTdfTXcwZ3FZVDRiOUJJSnBfWjA3TTctNUpE 4051 emg0czhyU3dsQzFXU3V2RmhRWlJCcXJtX2RaUlRIb0VaZldXc1VCSWVNWWdxNG1zb0JqTj 4052 NXSzhnRWYwZGI5a3Z6UG9LYmpJRy10UUE2R2l1X3pHaFVfLXFBV1lLemVKMDZ6djRIWlBO 4053 dHktQXRyTGF0WGhtUTdOQlVrX0hvbjdOUWxhU1g1ZHVNVmN4bGs1ZHVrWFZNMDgxa09wYV 4054 kzbDliQVFfYVhTM0FNaFFTTVVsT3dnTDZJazFPYVpaTGFMLUE3ejlITnlESmFEWTVhakZK 4055 TWFDV1lfOG94YlNoQUktNXA2MmNuT0xzV0dNWWNKTlBGVTZpcWlMR19oc3JfNlNKMURhbD 4056 VtQ0YycnBJLUItMlhuckxZR01ZS0NEZ2V2dGFnbi1DVUV6RURwR3ozQ2VLcWdQU0Vqd3BK 4057 N0M3NXduYTlCSmtTUkpOdDNla3hoWElrcnNEazRHVVpMSDdQYzFYZHdRTXhxdWpzNmxJSV 4058 EycjM1NWEtVkotWHdPcFpfY3RPdW96LTA4WHdYQ3RkTEliSFFVTG40RjlMRTRtanU0dUxS 4059 bjNSc043WWZ1S3dCVmVEZDJ6R3NBY0s5SVlDa3hOaDk3dDluYW1iMDZqSXVoWXF5QkhWRU 4060 9nTkhici1rMDY1bW9OVk5lVVUyMm5OdVNKS0ZxVnIxT0dKNGVfNXkzYkNwTmxTeEFPV1Bn 4061 RnJzU0Flc2JJOWw4eVJtVTAwenJYdGc4OWt5SjlCcXN2eXA1RE8wX2FtS1JyMXB1MVJVWF 4062 lFZzB2ampKS1FSdDVZbXRUNFJzaWpqdGRDWDg3UUxJaUdSY0hDdlJzUzZSdDJESmNYR1ht 4063 UGQyc0ZmNUZyNnJnMkFzX3BmUHN3cnF1WlAxbVFLc3RPMFVkTXpqMTlyb2N1NHVxVXlHUD 4064 lWWU54cHVnWVdNSjRYb1dRelJtWGNTUEJ4VEtnenFPS2s3UnRzWWVMNXl4LVM4NjV0cHVz 4065 dTA0bXpzYUJRZ21od1ZFVXBRdWNrcG1YWkNLNHlJUXktaHNFQUlJSmVxdFB3dVAySXF0X2 4066 I5dlk0bzExeXdzeXhzdmp2RnNKN0VVZU1MaGE2R2dSanBSbnU5RWIzRnlJZ0U5M0VVNEEw 4067 T0lUMWlOSGNRYWc0eWtOc3dPdkxQbjZIZ21zQ05ESlgwekc2RlFDMTZRdjBSQ25SVTdfV2 4068 VvblhSTUZwUzZRZ1JiSk45R1NMckN5bklJSWxUcDBxNHBaS05zM0tqQ2tMUzJrb3Bhd2Y0 4069 WF9BUllmTko3a0s5eW5BR0dCcktnUWJNRWVxUEFmMDBKMlYtVXpuU1JMZmQ4SGs3Y2JEdk 4070 5RQlhHQW9BR0ViaGRwVUc0RXFwMlVyQko3dEtyUUVSRlh4RTVsOFNHY2czQ1RmN2Zoazdx 4071 VEFBVjVsWEFnOUtOUDF1c1ZRZk1fUlBleHFNTG9WQVVKV2syQkF6WF9uSEhkVVhaSVBIOG 4072 hLeDctdEFRV0dTWUd0R2FmanZJZzI2c082TzloQWZVd3BpSV90MzF6SkZORDU0OTZURHBz 4073 QmNnd2dMLU1UcVhCRUJ2NEhvQld5SG1DVjVFMUwiLCJ0YWciOiJkbXlEeWZJVlNJUi1Ren 4074 ExOEgybFRIeEMxbl9HZEtrdnZNMDJUcHdsYzQwIn19fQ", 4075 "protected":"e-KAnGFsZ-KAnTrigJxSUzI1NuKAnX0", //RSAwithSHA256 4076 "header": { 4077 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4078 "signer":" 4079 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA 4080 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4081 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh 4082 cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p 4083 YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy 4084 BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4085 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4086 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3 4087 c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4088 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA 4089 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4090 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR 4091 MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq 4092 hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G 4093 SZ1MdyIZV8fwdEmD90IvtMHgtzK- 4094 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA 4095 UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4096 }, 4097 "signature":"nuQUsCTEBLeaRzuwd7q1iPIYEJ2eJfurO5sT5Y- 4098 N03zFRcv1jvrqMHtx_pw0Y9YWjmpoWfpfelhwGEko9SgeeBnznmkZbp7kjS6MmX4CKz 4099 9OApe3-VI7yL9Yp0WNdRh3425eYfuapCy3lcXFln5JBAUnU_OzUg3RWxcU_yGnFsw" 4100 } 4101 } 4103 A.1.2.2. Sample CreateSDResponse 4105 { 4106 "CreateSDTBSResponse": { 4107 "ver":"1.0", 4108 "status":"pass", 4109 "rid":"req-01", 4110 "tid":"tran-01", 4111 "content":{ 4112 "did":"zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM", 4113 "sdname":"sd.bank.com", 4114 "teespaik":"AQABjY9KiwH3hkMmSAAN6CLXot525U85WNlWKAQz5TOdfe_CM8h- 4115 X6_EHX1gOXoyRXaBiKMqWb0YZLCABTw1ytdXy2kWa525imRho8Vqn6HDGsJDZPDru9 4116 GnZR8pZX5ge_dWXB_uljMvDttc5iAWEJ8ZgcpLGtBTGLZnQoQbjtn1lIE", 4117 } 4118 } 4119 } 4121 Below is the response message after the content is encrypted and 4122 encoded. 4124 { 4125 "CreateSDResponse": { 4126 "payload":" 4127 eyJDcmVhdGVTRFRCU1Jlc3BvbnNlIjp7InZlciI6IjEuMCIsInN0YXR1cyI6InBhc3Mi 4128 LCJyaWQiOiJyZXEtMDEiLCJ0aWQiOiJ0cmFuLTAxIiwiY29udGVudCI6eyJwcm90ZWN0 4129 ZWQiOiJlLUtBbkdWdVktS0FuVHJpZ0p4Qk1USTRRMEpETFVoVE1qVTI0b0NkZlEiLCJy 4130 ZWNpcGllbnRzIjpbeyJoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0sImVuY3J5cHRlZF9r 4131 ZXkiOiJOX0I4R3pldUlfN2hwd0wwTFpHSTkxVWVBbmxJRkJfcndmZU1yZERrWnFGak1s 4132 VVhjdlI0XzhhOGhyeFI4SXR3aEtFZnVfRWVLRDBQb0dqQ2pCSHcxdG1ULUN6eWhsbW5v 4133 Slk3LXllWnZzRkRpc2VNTkd0eGE0OGZJYUs2VWx5NUZMYXBCZVc5T1I5bmktOU9GQV9j 4134 aFVuWWl3b2Q4ZTJFa0Vpd0JEZ1EzMk0ifV0sIml2IjoiQXhZOERDdERhR2xzYkdsamIz 4135 Um9aUSIsImNpcGhlcnRleHQiOiJsalh6Wk5JTmR1WjFaMXJHVElkTjBiVUp1RDRVV2xT 4136 QVptLWd6YnJINFVDYy1jMEFQenMtMWdWSFk4NTRUR3VMYkdyRmVHcDFqM2Fsb1lacWZp 4137 ZnE4aEt3Ty16RFlBN2tmVFhBZHp6czM4em9xeG4zbHoyM2w1RUlGUWhrOHBRWTRYTHRW 4138 M3ZBQWlNYnlrQ1Q3VS1CWDdWcjBacVNhYWZTQVZ4OFBLQ1RIU3hHN3hHVko0NkxxRzJS 4139 RE54WXQ4RC1SQ3lZUi1zRTM0MUFKZldEc2FLaGRRbzJXcjNVN1hTOWFqaXJtWjdqTlJ4 4140 cVRodHJBRWlIY1ctOEJMdVFHWEZ1YUhLMTZrenJKUGl4d0VXbzJ4cmw4cmkwc3ZRcHpl 4141 Z2M3MEt2Z0I0NUVaNHZiNXR0YlUya25hN185QU1Wcm4wLUJaQ1Bnb280MWlFblhuNVJn 4142 TXY2c2V2Y1JPQ2xHMnpWSjFoRkVLYjk2akEiLCJ0YWciOiIzOTZISTk4Uk1NQnR0eDlo 4143 ZUtsODROaVZLd0lJSzI0UEt2Z1RGYzFrbEJzIn19fQ", 4144 "protected": "e-KAnGFsZ-KAnTrigJxSUzI1NuKAnX0", 4145 "header": { 4146 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4147 "signer":" 4148 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJ 4149 BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp 4150 Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcN 4151 MTUwNzAyMDkwMTE4WhcNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzET 4152 MBEGA1UECAwKQ2FsaWZvcm5pYTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8G 4153 A1UECgwYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIGfMA0GCSqGSIb3DQEB 4154 AQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4155 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4156 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA 4157 6b_ZI3c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4158 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJ 4159 BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp 4160 Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX 4161 9nxZBNQWDjAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8E 4162 DDAKBggrBgEFBQcDAzANBgkqhkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4iv 4163 em4cIckfxzTBBiPHCjrrjB2X8Ktn8GSZ1MdyIZV8fwdEmD90IvtMHgtzK- 4164 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fV 4165 rJvnYAUBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4166 }, 4167 "signature":"jnJtaB0vFFwrE-qKOR3Pu9pf2gNoI1s67GgPCTq0U- 4168 qrz97svKpuh32WgCP2MWCoQPEswsEX-nxhIx_siTe4zIPO1nBYn- 4169 R7b25rQaF87O8uAOOnBN5Yl2Jk3laIbs- 4170 hGE32aRZDhrVoyEdSvIFrT6AQqD20bIAZGqTR-zA-900" 4171 } 4172 } 4174 A.1.3. Sample UpdateSD 4175 A.1.3.1. Sample UpdateSDRequest 4177 { 4178 "UpdateSDTBSRequest": { 4179 "ver": "1.0", 4180 "rid": "1222DA7D-8993-41A4-AC02-8A2807B31A3A", 4181 "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE", 4182 "tee": "Primary TEE ABC", 4183 "nextdsi": "false", 4184 "dsihash": 4185 " 4186 IsOvwpzDk8Onw4bCrsKTJsONwrbDrcKJYjVTw4vCu8OAw4JEw6zCgsK8w4JCacKxW8Kf 4187 w5o7", 4188 "content": { // NEEDS to BE ENCRYPTED 4189 "tamid": "id1.TAMxyz.com", 4190 "spid": "com.acmebank.spid1", 4191 "sdname": "com.acmebank.sdname1", 4192 "changes": { 4193 "newsdname": "com.acmebank.sdname2", 4194 "newspid": "com.acquirer.spid1", 4195 "spcert": 4196 "MIIDFjCCAn- 4197 gAwIBAgIJAIk0Tat0tquDMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNVBAYTAkTAMQ4 4198 wDAYDVQQIDAVTZW91bDESMBAGA1UEBwwJR3Vyby1kb25nMRAwDgYDVQQKDAdTb2x 4199 hY2lhMRAwDgYDVQQLDAdTb2xhY2lhMRUwEwYDVQQDDAxTb2xhLWNpYS5jb20wHhc 4200 NMTUwNzAyMDg1MTU3WhcNMjAwNjMwMDg1MTU3WjBsMQswCQYDVQQGEwJLUjEOMAw 4201 GA1UECAwFU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU29sYWN 4202 pYTEQMA4GA1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tMIGfMA0 4203 GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDYWLrFf2OFMEciwSYsyhaLY4kslaWcXA0 4204 hCWJRaFzt5mU- 4205 lpSJ4jeu92inBbsXcI8PfRbaItsgW1TD1Wg4gQH4MX_YtaBoOepE-- 4206 3JoZZyPyCWS3AaLYWrDmqFXdbzaO1i8GxB7zz0gWw55bZ9jyzcl5gQzWSqMRpx_d 4207 cad2SP2wIDAQABo4G_MIG8MIGGBgNVHSMEfzB9oXCkbjBsMQswCQYDVQQGEwJLUj 4208 EOMAwGA1UECAwFU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU2 4209 9sYWNpYTEQMA4GA1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tgg 4210 kAiTRNq3S2q4MwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0lAQH_BA 4211 wwCgYIKwYBBQUHAwMwDQYJKoZIhvcNAQEFBQADgYEAEFMhRwEQ- 4212 LDa9O7P1N0mcLORpo6fW3QuJfuXbRQRQGoXddXMKazI4VjbGaXhey7Bzvk6TZYDa 4213 - 4214 GRiZby1J47UPaDQR3UiDzVvXwCOU6S5yUhNJsW_BeMViYj4lssX28iPpNwLUCVm1 4215 QVTHILI6afLCRWXXclc1L5KGY290OwIdQ", 4216 "renewteespaik": "0" 4217 } 4218 } 4219 } 4220 } 4221 A.1.3.2. Sample UpdateSDResponse 4223 { 4224 "UpdateSDTBSResponse": { 4225 "ver": "1.0", 4226 "status": "pass", 4227 "rid": "1222DA7D-8993-41A4-AC02-8A2807B31A3A", 4228 "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE", 4229 "content": { 4230 "did": "MTZENTE5Qzc0Qzk0NkUxMzYxNzk0NjY4NTc3OTY4NTI=", 4231 "teespaik": 4232 "AQABjY9KiwH3hkMmSAAN6CLXot525U85WNlWKAQz5TOdfe_CM8h- 4233 X6_EHX1gOXoyRXaBiKMqWb0YZLCABTw1ytdXy2kWa525imRho8Vqn6HDGsJDZPDru9 4234 GnZR8pZX5ge_dWXB_uljMvDttc5iAWEJ8ZgcpLGtBTGLZnQoQbjtn1lIE", 4235 "teespaiktype": "RSA" 4236 } 4237 } 4238 } 4240 A.1.4. Sample DeleteSD 4242 A.1.4.1. Sample DeleteSDRequest 4244 The TAM builds message - including data to be encrypted. 4246 { 4247 "DeleteSDTBSRequest": { 4248 "ver": "1.0", 4249 "rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}", 4250 "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}", 4251 "tee": "Primary TEE", 4252 "nextdsi": "false", 4253 "dsihash": "AAECAwQFBgcICQoLDA0ODwABAgMEBQYHCAkKCwwNDg8=", 4254 "content": ENCRYPTED { 4255 "tamid": "TAM1.com", 4256 "sdname": "default.acmebank.com", 4257 "deleteta": "1" 4258 } 4259 } 4260 } 4262 The TAM encrypts the "content". 4264 { 4265 "DeleteSDTBSRequest": { 4266 "ver": "1.0", 4267 "rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}", 4268 "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}", 4269 "tee": "Primary TEE", 4270 "nextdsi": "false", 4271 "dsihash": "AAECAwQFBgcICQoLDA0ODwABAgMEBQYHCAkKCwwNDg8=", 4272 "content": { 4273 "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0", 4274 "recipients": [ 4275 { 4276 "header": { 4277 "alg": "RSA1_5" 4278 }, 4279 "encrypted_key": 4280 " 4281 QUVTMTI4IChDRUspIGtleSwgZW5jcnlwdGVkIHdpdGggVFNNIFJTQSBwdWJsaWMga2 4282 V5LCB1c2luZyBSU0ExXzUgcGFkZGluZw" 4283 } 4284 ], 4285 "iv": "rWO5DVmQX9ogelMLBIogIA", 4286 "ciphertext": 4287 " 4288 c2FtcGxlIGRzaSBkYXRhIGVuY3J5cHRlZCB3aXRoIEFFUzEyOCBrZXkgZnJvbSByZWNp 4289 cGllbnRzLmVuY3J5cHRlZF9rZXk", 4290 "tag": "c2FtcGxlIGF1dGhlbnRpY2F0aW9uIHRhZw" 4291 } 4292 } 4293 } 4295 The TAM signs the "DeleteSDTBSRequest" to form a "DeleteSDRequest" 4296 { 4297 "DeleteSDRequest": { 4298 "payload":" 4299 ewoJIkRlbGV0ZVNEVEJTUmVxdWVzdCI6IHsKCQkidmVyIjogIjEuMCIsCgkJInJp 4300 ZCI6ICJ7NzEyNTUxRjUtREZCMy00M2YwLTlBNjMtNjYzNDQwQjkxRDQ5fSIsCgkJ 4301 InRpZCI6ICJ7NEY0NTRBN0YtMDAyRC00MTU3LTg4NEUtQjBERDFBMDZBOEFFfSIs 4302 CgkJInRlZSI6ICJQcmltYXJ5IFRFRSIsCgkJIm5leHRkc2kiOiAiZmFsc2UiLAoJ 4303 CSJkc2loYXNoIjogIkFBRUNBd1FGQmdjSUNRb0xEQTBPRHdBQkFnTUVCUVlIQ0Fr 4304 S0N3d05EZzg9IiwKCQkiY29udGVudCI6IHsKCQkJInByb3RlY3RlZCI6ICJleUps 4305 Ym1NaU9pSkJNVEk0UTBKRExVaFRNalUySW4wIiwKCQkJInJlY2lwaWVudHMiOiBb 4306 ewoJCQkJImhlYWRlciI6IHsKCQkJCQkiYWxnIjogIlJTQTFfNSIKCQkJCX0sCgkJ 4307 CQkiZW5jcnlwdGVkX2tleSI6ICJRVVZUTVRJNElDaERSVXNwSUd0bGVTd2daVzVq 4308 Y25sd2RHVmtJSGRwZEdnZ1ZGTk5JRkpUUVNCd2RXSnNhV01nYTJWNUxDQjFjMmx1 4309 WnlCU1UwRXhYelVnY0dGa1pHbHVadyIKCQkJfV0sCgkJCSJpdiI6ICJyV081RFZt 4310 UVg5b2dlbE1MQklvZ0lBIiwKCQkJImNpcGhlcnRleHQiOiAiYzJGdGNHeGxJR1J6 4311 YVNCa1lYUmhJR1Z1WTNKNWNIUmxaQ0IzYVhSb0lFRkZVekV5T0NCclpYa2dabkp2 4312 YlNCeVpXTnBjR2xsYm5SekxtVnVZM0o1Y0hSbFpGOXJaWGsiLAoJCQkidGFnIjog 4313 ImMyRnRjR3hsSUdGMWRHaGxiblJwWTJGMGFXOXVJSFJoWnciCgkJfQoJfQp9", 4314 "protected":"eyJhbGciOiJSUzI1NiJ9", 4315 "header": { 4316 "x5c": ["ZXhhbXBsZSBBU04xIHNpZ25lciBjZXJ0aWZpY2F0ZQ==", 4317 "ZXhhbXBsZSBBU04xIENBIGNlcnRpZmljYXRl"] 4318 }, 4319 "signature":"c2FtcGxlIHNpZ25hdHVyZQ" 4320 } 4321 } 4323 A.1.4.2. Sample DeleteSDResponse 4325 The TEE creates a "DeleteSDTBSResponse" to respond to the 4326 "DeleteSDRequest" message from the TAM, including data to be 4327 encrypted. 4329 { 4330 "DeleteSDTBSResponse": { 4331 "ver": "1.0", 4332 "status": "pass", 4333 "rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}", 4334 "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}", 4335 "content": ENCRYPTED { 4336 "did": "MTZENTE5Qzc0Qzk0NkUxMzYxNzk0NjY4NTc3OTY4NTI=", 4337 } 4338 } 4339 } 4341 The TEE encrypts the "content" for the TAM. 4343 { 4344 "DeleteSDTBSResponse": { 4345 "ver": "1.0", 4346 "status": "pass", 4347 "rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}", 4348 "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}", 4349 "content": { 4350 "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0K", 4351 "recipients": [ 4352 { 4353 "header": { 4354 "alg": "RSA1_5" 4355 }, 4356 "encrypted_key": 4357 " 4358 QUVTMTI4IChDRUspIGtleSwgZW5jcnlwdGVkIHdpdGggVFNNIFJTQSBwdWJsaWMg 4359 a2V5LCB1c2luZyBSU0ExXzUgcGFkZGluZw" 4360 } 4361 ], 4362 "iv": "ySGmfZ69YlcEilNr5_SGbA", 4363 "ciphertext": 4364 " 4365 c2FtcGxlIGRzaSBkYXRhIGVuY3J5cHRlZCB3aXRoIEFFUzEyOCBrZXkgZnJvbSByZW 4366 NpcGllbnRzLmVuY3J5cHRlZF9rZXk", 4367 "tag": "c2FtcGxlIGF1dGhlbnRpY2F0aW9uIHRhZw" 4368 } 4369 } 4370 } 4372 The TEE signs "DeleteSDTBSResponse" to form a "DeleteSDResponse" 4373 { 4374 "DeleteSDResponse": { 4375 "payload":" 4376 ewoJIkRlbGV0ZVNEVEJTUmVzcG9uc2UiOiB7CgkJInZlciI6ICIxLjAiLAoJCSJz 4377 dGF0dXMiOiAicGFzcyIsCgkJInJpZCI6ICJ7NzEyNTUxRjUtREZCMy00M2YwLTlB 4378 NjMtNjYzNDQwQjkxRDQ5fSIsCgkJInRpZCI6ICJ7NEY0NTRBN0YtMDAyRC00MTU3 4379 LTg4NEUtQjBERDFBMDZBOEFFfSIsCgkJImNvbnRlbnQiOiB7CgkJCSJwcm90ZWN0 4380 ZWQiOiAiZXlKbGJtTWlPaUpCTVRJNFEwSkRMVWhUTWpVMkluMEsiLAoJCQkicmVj 4381 aXBpZW50cyI6IFt7CgkJCQkiaGVhZGVyIjogewoJCQkJCSJhbGciOiAiUlNBMV81 4382 IgoJCQkJfSwKCQkJCSJlbmNyeXB0ZWRfa2V5IjogIlFVVlRNVEk0SUNoRFJVc3BJ 4383 R3RsZVN3Z1pXNWpjbmx3ZEdWa0lIZHBkR2dnVkZOTklGSlRRU0J3ZFdKc2FXTWdh 4384 MlY1TENCMWMybHVaeUJTVTBFeFh6VWdjR0ZrWkdsdVp3IgoJCQl9XSwKCQkJIml2 4385 IjogInlTR21mWjY5WWxjRWlsTnI1X1NHYkEiLAoJCQkiY2lwaGVydGV4dCI6ICJj 4386 MkZ0Y0d4bElHUnphU0JrWVhSaElHVnVZM0o1Y0hSbFpDQjNhWFJvSUVGRlV6RXlP 4387 Q0JyWlhrZ1puSnZiU0J5WldOcGNHbGxiblJ6TG1WdVkzSjVjSFJsWkY5clpYayIs 4388 CgkJCSJ0YWciOiAiYzJGdGNHeGxJR0YxZEdobGJuUnBZMkYwYVc5dUlIUmhadyIK 4389 CQl9Cgl9Cn0", 4390 "protected":"eyJhbGciOiJSUzI1NiJ9", 4391 "signature":"c2FtcGxlIHNpZ25hdHVyZQ" 4392 } 4393 } 4395 The TEE returns "DeleteSDResponse" back to the OTrP Agent, which 4396 returns the message back to the TAM. 4398 A.2. Sample TA Management Messages 4400 A.2.1. Sample InstallTA 4402 A.2.1.1. Sample InstallTARequest 4403 { 4404 "InstallTATBSRequest": { 4405 "ver": "1.0", 4406 "rid": "24BEB059-0AED-42A6-A381-817DFB7A1207", 4407 "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE", 4408 "tee": "Primary TEE ABC", 4409 "nextdsi": "true", 4410 "dsihash": 4411 " 4412 IsOvwpzDk8Onw4bCrsKTJsONwrbDrcKJYjVTw4vCu8OAw4JEw6zCgsK8w4JCacKxW8Kf 4413 w5o7", 4414 "content": { 4415 "tamid": "id1.TAMxyz.com", 4416 "spid": "com.acmebank.spid1", 4417 "sdname": "com.acmebank.sdname1", 4418 "taid": "com.acmebank.taid.banking" 4419 }, 4420 "encrypted_ta": { 4421 "key": 4422 "mLBjodcE4j36y64nC/nEs694P3XrLAOokjisXIGfs0H7lOEmT5FtaNDYEMcg9RnE 4423 ftlJGHO7N0lgcNcjoXBmeuY9VI8xzrsZM9gzH6VBKtVONSx0aw5IAFkNcyPZwDdZ 4424 MLwhvrzPJ9Fg+bZtrCoJz18PUz+5aNl/dj8+NM85LCXXcBlZF74btJer1Mw6ffzT 4425 /grPiEQTeJ1nEm9F3tyRsvcTInsnPJ3dEXv7sJXMrhRKAeZsqKzGX4eiZ3rEY+FQ 4426 6nXULC8cAj5XTKpQ/EkZ/iGgS0zcXR7KUJv3wFEmtBtPD/+ze08NILLmxM8olQFj 4427 //Lq0gGtq8vPC8r0oOfmbQ==", 4428 "iv": "4F5472504973426F726E496E32303135", 4429 "alg": "AESCBC", 4430 "ciphertadata": 4431 "......0x/5KGCXWfg1Vrjm7zPVZqtYZ2EovBow+7EmfOJ1tbk......=", 4432 "cipherpdata": "0x/5KGCXWfg1Vrjm7zPVZqtYZ2EovBow+7EmfOJ1tbk=" 4433 } 4434 } 4435 } 4437 A.2.1.2. Sample InstallTAResponse 4439 A sample to-be-signed response of InstallTA looks as follows. 4441 { 4442 "InstallTATBSResponse": { 4443 "ver": "1.0", 4444 "status": "pass", 4445 "rid": "24BEB059-0AED-42A6-A381-817DFB7A1207", 4446 "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE", 4447 "content": { 4448 "did": "MTZENTE5Qzc0Qzk0NkUxMzYxNzk0NjY4NTc3OTY4NTI=", 4449 "dsi": { 4450 "tfwdata": { 4451 "tbs": "ezRGNDU0QTdGLTAwMkQtNDE1Ny04ODRFLUIwREQxQTA2QThBRX0=" 4452 "cert": "ZXhhbXBsZSBGVyBjZXJ0aWZpY2F0ZQ==", 4453 "sigalg": "UlMyNTY=", 4454 "sig": "c2FtcGxlIEZXIHNpZ25hdHVyZQ==" 4455 }, 4456 "tee": { 4457 "name": "Primary TEE", 4458 "ver": "1.0", 4459 "cert": "c2FtcGxlIFRFRSBjZXJ0aWZpY2F0ZQ==", 4460 "cacert": [ 4461 "c2FtcGxlIENBIGNlcnRpZmljYXRlIDE=", 4462 "c2FtcGxlIENBIGNlcnRpZmljYXRlIDI=" 4463 ], 4464 "sdlist": { 4465 "cnt": "1", 4466 "sd": [ 4467 { 4468 "name": "com.acmebank.sdname1", 4469 "spid": "com.acmebank.spid1", 4470 "talist": [ 4471 { 4472 "taid": "com.acmebank.taid.banking", 4473 "taname": "Acme secure banking app" 4474 }, 4475 { 4476 "taid": "acom.acmebank.taid.loyalty.rewards", 4477 "taname": "Acme loyalty rewards app" 4478 } 4479 ] 4480 } 4481 ] 4482 }, 4483 "teeaiklist": [ 4484 { 4485 "spaik": 4486 "c2FtcGxlIEFTTjEgZW5jb2RlZCBQS0NTMSBwdWJsaWNrZXk=", 4487 "spaiktype": "RSA" 4488 "spid": "acmebank.com" 4489 } 4490 ] 4491 } 4492 } 4493 } 4494 } 4495 } 4497 A.2.2. Sample UpdateTA 4499 A.2.2.1. Sample UpdateTARequest 4501 { 4502 "UpdateTATBSRequest": { 4503 "ver": "1.0", 4504 "rid": "req-2", 4505 "tid": "tran-01", 4506 "tee": "SecuriTEE", 4507 "nextdsi": " false", 4508 "dsihash": "gwjul_9MZks3pqUSN1-eL1aViwGXNAxk0AIKW79dn4U", 4509 "content": { 4510 "tamid": "TAM1.acme.com", 4511 "spid": "bank.com", 4512 "sdname": "sd.bank.com", 4513 "taid": "sd.bank.com.ta" 4514 }, 4515 "encrypted_ta": { 4516 "key": 4517 " 4518 XzmAn_RDVk3IozMwNWhiB6fmZlIs1YUvMKlQAv_UDoZ1fvGGsRGo9bT0A440aYMgLt 4519 GilKypoJjCgijdaHgamaJgRSc4Je2otpnEEagsahvDNoarMCC5nGQdkRxW7Vo2NKgL 4520 A892HGeHkJVshYm1cUlFQ-BhiJ4NAykFwlqC_oc", 4521 "iv": "AxY8DCtDaGlsbGljb3RoZQ", 4522 "alg": "AESCBC", 4523 "ciphernewtadata": 4524 "KHqOxGn7ib1F_14PG4_UX9DBjOcWkiAZhVE-U- 4525 67NsKryHGokeWr2spRWfdU2KWaaNncHoYGwEtbCH7XyNbOFh28nzwUmstep4nHWbAl 4526 XZYTNkENcABPpuw_G3I3HADo" 4527 } 4528 } 4529 } 4531 { 4532 "UpdateTARequest": { 4533 "payload" : 4534 " 4535 eyJVcGRhdGVUQVRCU1JlcXVlc3QiOnsidmVyIjoiMS4wIiwicmlkIjoicmVxLTIiLCJ0 4536 aWQiOiJ0cmFuLTAxIiwidGVlIjoiU2VjdXJpVEVFIiwibmV4dGRzaSI6ImZhbHNlIiwi 4537 ZHNpaGFzaCI6Imd3anVsXzlNWmtzM3BxVVNOMS1lTDFhVml3R1hOQXhrMEFJS1c3OWRu 4538 NFUiLCJjb250ZW50Ijp7InByb3RlY3RlZCI6ImV5SmxibU1pT2lKQk1USTRRMEpETFVo 4539 VE1qVTJJbjAiLCJyZWNpcGllbnRzIjpbeyJoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0s 4540 ImVuY3J5cHRlZF9rZXkiOiJYem1Bbl9SRFZrM0lvek13TldoaUI2Zm1abElzMVlVdk1L 4541 bFFBdl9VRG9aMWZ2R0dzUkdvOWJUMEE0NDBhWU1nTHRHaWxLeXBvSmpDZ2lqZGFIZ2Ft 4542 YUpnUlNjNEplMm90cG5FRWFnc2FodkROb2FyTUNDNW5HUWRrUnhXN1ZvMk5LZ0xBODky 4543 SEdlSGtKVnNoWW0xY1VsRlEtQmhpSjROQXlrRndscUNfb2MifV0sIml2IjoiQXhZOERD 4544 dERhR2xzYkdsamIzUm9aUSIsImNpcGhlcnRleHQiOiJIYTcwVXRZVEtWQmtXRFJuMi0w 4545 SF9IdkZtazl5SGtoVV91bk1OLWc1T3BqLWF1NGFUb2lxWklMYzVzYTdENnZZSjF6eW04 4546 QW1JOEJIVXFqc2l5Z0tOcC1HdURJUjFzRXc0a2NhMVQ5ZENuU0RydHhSUFhESVdrZmt3 4547 azZlR1NQWiIsInRhZyI6Im9UN01UTE41eWtBTFBoTDR0aUh6T1pPTGVFeU9xZ0NWaEM5 4548 MXpkcldMU0UifSwiZW5jcnlwdGVkX3RhIjp7ImtleSI6Ilh6bUFuX1JEVmszSW96TXdO 4549 V2hpQjZmbVpsSXMxWVV2TUtsUUF2X1VEb1oxZnZHR3NSR285YlQwQTQ0MGFZTWdMdEdp 4550 bEt5cG9KakNnaWpkYUhnYW1hSmdSU2M0SmUyb3RwbkVFYWdzYWh2RE5vYXJNQ0M1bkdR 4551 ZGtSeFc3Vm8yTktnTEE4OTJIR2VIa0pWc2hZbTFjVWxGUS1CaGlKNE5BeWtGd2xxQ19v 4552 YyIsIml2IjoiQXhZOERDdERhR2xzYkdsamIzUm9aUSIsImFsZyI6IkFFU0NCQyIsImNp 4553 cGhlcm5ld3RhZGF0YSI6IktIcU94R243aWIxRl8xNFBHNF9VWDlEQmpPY1draUFaaFZF 4554 LVUtNjdOc0tyeUhHb2tlV3Iyc3BSV2ZkVTJLV2FhTm5jSG9ZR3dFdGJDSDdYeU5iT0Zo 4555 MjhuendVbXN0ZXA0bkhXYkFsWFpZVE5rRU5jQUJQcHV3X0czSTNIQURvIn19fQ", 4556 "protected": " eyJhbGciOiJSUzI1NiJ9", 4557 "header": { 4558 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4559 "signer":" 4560 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA 4561 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4562 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh 4563 cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p 4564 YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy 4565 BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4566 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4567 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3 4568 c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4569 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA 4570 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4571 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR 4572 MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq 4573 hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G 4574 SZ1MdyIZV8fwdEmD90IvtMHgtzK- 4575 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA 4576 UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4577 }, 4578 "signature":"inB1K6G3EAhF- 4579 FbID83UI25R5Ao8MI4qfrbrmf0UQhjM3O7_g3l6XxN_JkHrGQaZr- 4580 myOkGPVM8BzbUZW5GqxNZwFXwMeaoCjDKc4Apv4WZkD1qKJxkg1k5jaUCfJz1Jmw_XtX 4581 6MHhrLh9ov03S9PtuT1VAQ0FVUB3qFIvjSnNU" 4582 } 4583 } 4585 A.2.2.2. Sample UpdateTAResponse 4586 { 4587 "UpdateTATBSResponse": { 4588 "ver": "1.0", 4589 "status": "pass", 4590 "rid": "req-2", 4591 "tid": "tran-01", 4592 "content": { 4593 "did": "zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM" 4594 } 4595 } 4596 } 4598 { 4599 "UpdateTAResponse":{ 4600 "payload":" 4601 eyJVcGRhdGVUQVRCU1Jlc3BvbnNlIjp7InZlciI6IjEuMCIsInN0YXR1cyI6InBhc3Mi 4602 LCJyaWQiOiJyZXEtMiIsInRpZCI6InRyYW4tMDEiLCJjb250ZW50Ijp7InByb3RlY3Rl 4603 ZCI6ImV5SmxibU1pT2lKQk1USTRRMEpETFVoVE1qVTJJbjAiLCJyZWNpcGllbnRzIjpb 4604 eyJoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0sImVuY3J5cHRlZF9rZXkiOiJFaGUxLUJB 4605 UUdJLTNEMFNHdXFGY01MZDJtd0gxQm1uRndYQWx1M1FxUFVXZ1RRVm55SUowNFc2MnBK 4606 YWVSREFkeTU0R0FSVjBrVzQ0RGw0MkdUUlhqbE1EZ3BYdXdFLWloc1JVV0tNNldCZ2N3 4607 VXVGQTRUR3gwU0I1NTZCdl92dnBNaFdfMXh2c2FHdFBaQmwxTnZjbXNibzBhY3FobXlu 4608 bzBDTmF5SVAtX1UifV0sIml2IjoiQXhZOERDdERhR2xzYkdsamIzUm9aUSIsImNpcGhl 4609 cnRleHQiOiJwc2o2dGtyaGJXM0lmVElMeE9GMU5HdFUtcTFmeVBidV9KWk9jbklycWIw 4610 eTNPOHN6OTItaWpWR1ZyRW5WbG1sY1FYeWFNZTNyX1JGdEkwV3B4UmRodyIsInRhZyI6 4611 Ik0zb2dNNk11MVJYMUMybEZvaG5rTkN5b25qNjd2TDNqd2RrZXhFdUlpaTgifX19", 4612 "protected":"eyJhbGciOiJSUzI1NiJ9", 4613 "header": { 4614 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4615 "signer":" 4616 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA 4617 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4618 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh 4619 cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p 4620 YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy 4621 BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4622 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4623 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3 4624 c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4625 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA 4626 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4627 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR 4628 MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq 4629 hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G 4630 SZ1MdyIZV8fwdEmD90IvtMHgtzK- 4631 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA 4632 UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4633 }, 4634 "signature":" 4635 Twajmt_BBLIMcNrDsjqr8lI7O7lEQxXZNhlUOtFkOMMqf37wOPKtp_99LoS82CVmdpCo 4636 PLaws8zzh-SNIQ42- 4637 9GYO8_9BaEGCiCwyl8YgWP9fWNfNv2gR2fl2DK4uknkYu1EMBW4YfP81n_pGpb4Gm- 4638 nMk14grVZygwAPej3ZZk" 4639 } 4640 } 4641 A.2.3. Sample DeleteTA 4643 A.2.3.1. Sample DeleteTARequest 4645 { 4646 "DeleteTATBSRequest": { 4647 "ver": "1.0", 4648 "rid": "req-2", 4649 "tid": "tran-01", 4650 "tee": "SecuriTEE", 4651 "nextdsi": "false", 4652 "dsihash": "gwjul_9MZks3pqUSN1-eL1aViwGXNAxk0AIKW79dn4U", 4653 "content": { 4654 "tamid": "TAM1.acme.com", 4655 "sdname": "sd.bank.com", 4656 "taid": "sd.bank.com.ta" 4657 } 4658 } 4659 } 4661 { 4662 "DeleteTARequest": { 4663 "payload": 4664 " 4665 eyJEZWxldGVUQVRCU1JlcXVlc3QiOnsidmVyIjoiMS4wIiwicmlkIjoicmVxLTIiLCJ0 4666 aWQiOiJ0cmFuLTAxIiwidGVlIjoiU2VjdXJpVEVFIiwibmV4dGRzaSI6ImZhbHNlIiwi 4667 ZHNpaGFzaCI6Imd3anVsXzlNWmtzM3BxVVNOMS1lTDFhVml3R1hOQXhrMEFJS1c3OWRu 4668 NFUiLCJjb250ZW50Ijp7InByb3RlY3RlZCI6eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0s 4669 InJlY2lwaWVudHMiOlt7ImhlYWRlciI6eyJhbGciOiJSU0ExXzUifSwiZW5jcnlwdGVk 4670 X2tleSI6ImtyaGs0d2dpY0RlX3d0VXQyTW4tSUJsdUtvX0JkeXpNY2p1cVlBenBPYnRS 4671 TG9MZzQ0QkFLN2tRVWE1YTg0TEVJRGEzaHNtWDIxdldNZFJLczN4MTJsOUh5VFdfLUNS 4672 WmZtcUx2bEh1LV9MSVdvc1ZyRTZVMlJqUnRndllVOWliUkVLczkzRDRHWm4xVHFuZG9n 4673 d0tXRF9jdG1nWG1sbzZZVXpCWDZhR1dZMCJ9XSwiaXYiOiJBeFk4REN0RGFHbHNiR2xq 4674 YjNSb1pRIiwiY2lwaGVydGV4dCI6IkhhNzBVdFlUS1ZCa1dEUm4yLTBIX1BGa19yQnpQ 4675 dGJHdzhSNktlMXotdklNeFBSY0Nxa1puZmwyTjRjUTZPSTZCSHZJUUFoM2Jic0l0dHlR 4676 bXhDTE5Nbm8wejBrYm9TdkIyVXlxWExpeGVZIiwidGFnIjoidEtUbFRLdlR2LTRtVVlG 4677 Y1dYWnZMMVlhQnRGNloxVlNxOTMzVmI2UEpmcyJ9fX0", 4678 "protected" : "eyJhbGciOiJSUzI1NiJ9", 4679 "header": { 4680 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4681 "signer":" 4682 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA 4683 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4684 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh 4685 cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p 4686 YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy 4687 BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4688 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4689 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3 4690 c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4691 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA 4692 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4693 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR 4694 MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq 4695 hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G 4696 SZ1MdyIZV8fwdEmD90IvtMHgtzK- 4697 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA 4698 UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4699 }, 4700 "signature" : 4701 " 4702 BZS0_Ab6pqvGNXe5lqT4Sc3jakyWQeiK9KlVSnimwWnjCCyMtyB9bwvlbILZba3IJiFe 4703 _3F9bIQpSytGS0f2TQrPTKC7pSjwDw-3kH7HkHcPPJd- 4704 PpMMfQvRx7AIV8vBqO9MijIC62iN0V2se5z2v8VFjGSoRGgq225w7FvrnWE" 4705 } 4706 } 4707 A.2.3.2. Sample DeleteTAResponse 4709 { 4710 "DeleteTATBSResponse": { 4711 "ver": "1.0", 4712 "status": "pass", 4713 "rid": "req-2", 4714 "tid": "tran-01", 4715 "content": { 4716 "did": "zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM" 4717 } 4718 } 4719 } 4721 { 4722 "DeleteTAResponse":{ 4723 "payload":" 4724 ew0KCSJEZWxldGVUQVRCU1Jlc3BvbnNlIjogew0KCQkidmVyIjogIjEuMCIsDQoJCSJz 4725 dGF0dXMiOiAicGFzcyIsDQoJCSJyaWQiOiAicmVxLTIiLA0KCQkidGlkIjogInRyYW4t 4726 MDEiLA0KCQkiY29udGVudCI6IHsNCgkJCSJwcm90ZWN0ZWQiOnsiZW5jIjoiQTEyOENC 4727 Qy1IUzI1NiJ9LA0KCQkJInJlY2lwaWVudHMiOlsNCgkJCQl7DQoJCQkJCSJoZWFkZXIi 4728 OnsiYWxnIjoiUlNBMV81In0sDQoJCQkJCSJlbmNyeXB0ZWRfa2V5IjoiTXdtU1ZHaWU2 4729 eHpfQmxTaFlmTFRKRHhKT3oyNWhvYy1HZ2NEM2o5OWFyM2E4X2lYY182ZE44bFRTb1dD 4730 X19wZEFhaEMyWk5SakdIcTBCZ2JDYTRKalk0eXRkMVBVWDB6M1psbXl1YnRXM291eEpY 4731 el9PMzg1WGM4S3hySndjbElyZGx2WUY2OVZmeERLQkVzUHJCdzlVenVIa1VmSU4xWlFU 4732 bWZ0QmVaSlJnIg0KCQkJCX0NCgkJCV0sDQoJCQkiaXYiOiJBeFk4REN0RGFHbHNiR2xq 4733 YjNSb1pRIiwNCgkJCSJjaXBoZXJ0ZXh0IjoiamhQTlV5ZkFTel9rVV9GbEM2LUtCME01 4734 WDBHNE5MbHc0LWt0bERyajZTWlUteUp6eUFUbC1oY0ZBWWMwLXJMVEF4cF93N1d1WER0 4735 Y3N3SzJSSzRjcWciLA0KCQkJInRhZyI6IlBBeGo5N25oT29qVTNIREhxSll4MGZMNWpt 4736 b0xkTlJkTHRTAMIzUTdrYXciDQoJCX0NCgl9DQp9", 4737 "protected": "eyJhbGciOiJSUzI1NiJ9", 4738 "header": { 4739 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4740 "signer":" 4741 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJ 4742 BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp 4743 Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcN 4744 MTUwNzAyMDkwMTE4WhcNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzET 4745 MBEGA1UECAwKQ2FsaWZvcm5pYTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8G 4746 A1UECgwYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIGfMA0GCSqGSIb3DQEB 4747 AQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4748 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4749 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA 4750 6b_ZI3c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4751 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJ 4752 BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp 4753 Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX 4754 9nxZBNQWDjAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8E 4755 DDAKBggrBgEFBQcDAzANBgkqhkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4iv 4756 em4cIckfxzTBBiPHCjrrjB2X8Ktn8GSZ1MdyIZV8fwdEmD90IvtMHgtzK- 4757 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fV 4758 rJvnYAUBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4759 }, 4760 "signature":" 4761 DfoBOetNelKsnAe_m4Z9K5UbihgWNYZsp5jVybiI05sOagDzv6R4do9npaAlAvpNK8HJ 4762 CxD6D22J8GDUExlIhSR1aDuDCQm6QzmjdkFdxAz5TRYl6zpPCZqgSToN_g1TZxqxEv6V 4763 Ob5fies4g6MHvCH-Il_-KbHq5YpwGxEEFdg" 4764 } 4765 } 4766 A.3. Example OTrP Agent Option 4768 The most popular TEE devices today are Android powered devices. In 4769 an Android device, an OTrP Agent can be a bound service with a 4770 service registration ID that a Client Application can use. This 4771 option allows a Client Application not to depend on any OTrP Agent 4772 SDK or provider. 4774 An OTrP Agent is responsible to detect and work with more than one 4775 TEE if a device has more than one. In this version, there is only 4776 one active TEE such that an OTrP Agent only needs to handle the 4777 active TEE. 4779 Appendix B. Contributors 4781 - Brian Witten 4782 Symantec 4783 brian_witten@symantec.com 4785 - Tyler Kim 4786 Solacia 4787 tylerkim@iotrust.kr 4789 Authors' Addresses 4791 Mingliang Pei 4792 Symantec 4793 350 Ellis St 4794 Mountain View, CA 94043 4795 USA 4797 Email: mingliang_pei@symantec.com 4799 Andrew Atyeo 4800 Intercede 4801 St. Mary's Road, Lutterworth 4802 Leicestershire, LE17 4PS 4803 Great Britain 4805 Email: andrew.atyeo@intercede.com 4806 Nick Cook 4807 ARM Ltd. 4808 110 Fulbourn Rd 4809 Cambridge, CB1 9NJ 4810 Great Britain 4812 Email: nicholas.cook@arm.com 4814 Minho Yoo 4815 Solacia 4816 5F, Daerung Post Tower 2, 306 Digital-ro 4817 Seoul 152-790 4818 Korea 4820 Email: paromix@gmail.com 4822 Hannes Tschofenig 4823 ARM Ltd. 4824 110 Fulbourn Rd 4825 Cambridge, CB1 9NJ 4826 Great Britain 4828 Email: Hannes.Tschofenig@arm.com