idnits 2.17.1 draft-pei-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 886 has weird spacing: '...cluding the r...' -- The document date (July 8, 2016) is 2820 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Pei 3 Internet-Draft Symantec 4 Intended status: Informational N. Cook 5 Expires: January 9, 2017 Intercede 6 M. Yoo 7 Solacia 8 A. Atyeo 9 Intercede 10 H. Tschofenig 11 ARM Ltd. 12 July 8, 2016 14 The Open Trust Protocol (OTrP) 15 draft-pei-opentrustprotocol-01.txt 17 Abstract 19 This document specifies the Open Trust Protocol (OTrP), a protocol to 20 install, update, and delete applications and to manage security 21 configuration in a Trusted Execution Environment (TEE). 23 TEEs are used in environments where security services should be 24 isolated from a regular operating system (often called rich OS). 25 This form of compartmentlization grants a smaller codebase access to 26 security sensitive services and restricts communication from the rich 27 OS to those security services via mediated access. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 9, 2017. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7 68 4. OTrP Entities and Trust Model . . . . . . . . . . . . . . . . 8 69 4.1. System Components . . . . . . . . . . . . . . . . . . . . 8 70 4.2. Trusted Anchors in TEE . . . . . . . . . . . . . . . . . 9 71 4.3. Trusted Anchors in TSM . . . . . . . . . . . . . . . . . 9 72 4.4. Keys and Cerificate Types . . . . . . . . . . . . . . . . 9 73 5. Protocol Scope and Entity Relations . . . . . . . . . . . . . 12 74 5.1. A Sample Device Setup Flow . . . . . . . . . . . . . . . 14 75 5.2. Derived Keys in the Protocol . . . . . . . . . . . . . . 14 76 5.3. Security Domain Hierarchy and Ownership . . . . . . . . . 14 77 5.4. SD Owner Identification and TSM Certificate 78 Requirements . . . . . . . . . . . . . . . . . . . . . . 15 79 5.5. Service Provider Container . . . . . . . . . . . . . . . 16 80 6. OTrP Agent . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 6.1. Role of OTrP Agent . . . . . . . . . . . . . . . . . . . 16 82 6.2. OTrP Agent and Global Platform TEE Client API . . . . . . 17 83 6.3. OTrP Agent Implementation Consideration . . . . . . . . . 17 84 6.3.1. OTrP Agent Distribution . . . . . . . . . . . . . . . 17 85 6.3.2. Number of OTrP Agent . . . . . . . . . . . . . . . . 17 86 6.3.3. OTrP Android Service Option . . . . . . . . . . . . . 18 87 6.4. OTrP Agent API for Client Applications . . . . . . . . . 18 88 6.4.1. API processMessage . . . . . . . . . . . . . . . . . 18 89 6.4.2. API getTAInformation . . . . . . . . . . . . . . . . 19 90 6.5. Sample End-to-End Client Application Flow . . . . . . . . 21 91 6.5.1. Case 1: A new Client App uses a TA . . . . . . . . . 21 92 6.5.2. Case 2: A previously installed Client Application 93 calls a TA . . . . . . . . . . . . . . . . . . . . . 23 95 7. OTrP Messages . . . . . . . . . . . . . . . . . . . . . . . . 24 96 7.1. Message Format . . . . . . . . . . . . . . . . . . . . . 24 97 7.2. Message Naming Convention . . . . . . . . . . . . . . . . 24 98 7.3. Request and Response Message Template . . . . . . . . . . 25 99 7.4. Signed Request and Response Message Structure . . . . . . 25 100 7.4.1. Identifying signing and Encryption keys for JWS/JWE 101 messaging . . . . . . . . . . . . . . . . . . . . . . 27 102 7.5. JSON Signing and Encryption Algorithms . . . . . . . . . 27 103 7.5.1. Supported JSON Signing Algorithms . . . . . . . . . . 29 104 7.5.2. Support JSON Encryption Algorithms . . . . . . . . . 29 105 7.5.3. Supported JSON Key Management Algorithms . . . . . . 29 106 7.6. Common Errors . . . . . . . . . . . . . . . . . . . . . . 30 107 7.7. OTrP Message List . . . . . . . . . . . . . . . . . . . . 30 108 7.8. OTrP Request Message Routing Rules . . . . . . . . . . . 31 109 7.8.1. SP Anonymous Attestation Key (SP AIK) . . . . . . . . 31 110 8. Detailed Messages Specification . . . . . . . . . . . . . . . 31 111 8.1. GetDeviceState . . . . . . . . . . . . . . . . . . . . . 32 112 8.1.1. GetDeviceStateRequest message . . . . . . . . . . . . 32 113 8.1.2. Request processing requirements at a TEE . . . . . . 33 114 8.1.3. Firmware signed data . . . . . . . . . . . . . . . . 34 115 8.1.3.1. Supported Firmware Signature Methods . . . . . . 34 116 8.1.4. Post Conditions . . . . . . . . . . . . . . . . . . . 35 117 8.1.5. GetDeviceStateResponse message . . . . . . . . . . . 35 118 8.1.6. Error Conditions . . . . . . . . . . . . . . . . . . 39 119 8.1.7. TSM Processing Requirements . . . . . . . . . . . . . 40 120 8.2. Security Domain Management . . . . . . . . . . . . . . . 41 121 8.2.1. CreateSD . . . . . . . . . . . . . . . . . . . . . . 41 122 8.2.1.1. CreateSDRequest Message . . . . . . . . . . . . . 41 123 8.2.1.2. Request processing requirements at a TEE . . . . 44 124 8.2.1.3. CreateSDResponse Message . . . . . . . . . . . . 45 125 8.2.1.4. Error Conditions . . . . . . . . . . . . . . . . 46 126 8.2.2. UpdateSD . . . . . . . . . . . . . . . . . . . . . . 47 127 8.2.2.1. UpdateSDRequest Message . . . . . . . . . . . . . 47 128 8.2.2.2. Request processing requirements at a TEE . . . . 50 129 8.2.2.3. UpdateSDResponse Message . . . . . . . . . . . . 52 130 8.2.2.4. Error Conditions . . . . . . . . . . . . . . . . 53 131 8.2.3. DeleteSD . . . . . . . . . . . . . . . . . . . . . . 54 132 8.2.3.1. DeleteSDRequest Message . . . . . . . . . . . . . 54 133 8.2.3.2. Request processing requirements at a TEE . . . . 56 134 8.2.3.3. DeleteSDResponse Message . . . . . . . . . . . . 57 135 8.2.3.4. Error Conditions . . . . . . . . . . . . . . . . 59 136 8.3. Trusted Application Management . . . . . . . . . . . . . 59 137 8.3.1. InstallTA . . . . . . . . . . . . . . . . . . . . . . 59 138 8.3.1.1. InstallTARequest Message . . . . . . . . . . . . 61 139 8.3.1.2. InstallTAResponse Message . . . . . . . . . . . . 62 140 8.3.1.3. Error Conditions . . . . . . . . . . . . . . . . 64 141 8.3.2. UpdateTA . . . . . . . . . . . . . . . . . . . . . . 64 142 8.3.2.1. UpdateTARequest Message . . . . . . . . . . . . . 65 143 8.3.2.2. UpdateTAResponse Message . . . . . . . . . . . . 67 144 8.3.2.3. Error Conditions . . . . . . . . . . . . . . . . 69 145 8.3.3. DeleteTA . . . . . . . . . . . . . . . . . . . . . . 69 146 8.3.3.1. DeleteTARequest Message . . . . . . . . . . . . . 69 147 8.3.3.2. Request processing requirements at a TEE . . . . 71 148 8.3.3.3. DeleteTAResponse Message . . . . . . . . . . . . 72 149 8.3.3.4. Error Conditions . . . . . . . . . . . . . . . . 73 150 9. Response Messages a TSM May Expect . . . . . . . . . . . . . 73 151 10. Attestation Implementation Consideration . . . . . . . . . . 74 152 10.1. OTrP Secure Boot Module . . . . . . . . . . . . . . . . 74 153 10.1.1. Attestation signer . . . . . . . . . . . . . . . . . 74 154 10.1.2. SBM initial requirements . . . . . . . . . . . . . . 75 155 10.2. TEE Loading . . . . . . . . . . . . . . . . . . . . . . 75 156 10.3. Attestation Hierarchy . . . . . . . . . . . . . . . . . 76 157 10.3.1. Attestation hierarchy establishment: manufacture . . 76 158 10.3.2. Attestation hierarchy establishment: device boot . . 76 159 10.3.3. Attestation hierarchy establishment: TSM . . . . . . 76 160 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 77 161 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 77 162 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77 163 13.1. Error Code List . . . . . . . . . . . . . . . . . . . . 77 164 14. Security Consideration . . . . . . . . . . . . . . . . . . . 79 165 14.1. Cryptographic Strength . . . . . . . . . . . . . . . . . 79 166 14.2. Message Security . . . . . . . . . . . . . . . . . . . . 79 167 14.3. TEE Attestation . . . . . . . . . . . . . . . . . . . . 80 168 14.4. TA Protection . . . . . . . . . . . . . . . . . . . . . 80 169 14.5. TA Personalization Data . . . . . . . . . . . . . . . . 80 170 14.6. TA trust check at TEE . . . . . . . . . . . . . . . . . 81 171 14.7. One TA Multiple SP Case . . . . . . . . . . . . . . . . 81 172 14.8. OTrP Agent Trust Model . . . . . . . . . . . . . . . . . 81 173 14.9. OCSP Stapling Data for TSM signed messages . . . . . . . 82 174 14.10. Data protection at TSM and TEE . . . . . . . . . . . . . 82 175 14.11. Privacy consideration . . . . . . . . . . . . . . . . . 82 176 14.12. Threat mitigation . . . . . . . . . . . . . . . . . . . 82 177 14.13. Compromised CA . . . . . . . . . . . . . . . . . . . . . 83 178 14.14. Compromised TSM . . . . . . . . . . . . . . . . . . . . 83 179 14.15. Certificate renewal . . . . . . . . . . . . . . . . . . 84 180 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 84 181 15.1. Normative References . . . . . . . . . . . . . . . . . . 84 182 15.2. Informative References . . . . . . . . . . . . . . . . . 84 183 Appendix A. Sample Messages . . . . . . . . . . . . . . . . . . 84 184 A.1. Sample Security Domain Management Messages . . . . . . . 84 185 A.1.1. Sample GetDeviceState . . . . . . . . . . . . . . . . 85 186 A.1.1.1. Sample GetDeviceStateRequest . . . . . . . . . . 85 187 A.1.1.2. Sample GetDeviceStateResponse . . . . . . . . . . 85 188 A.1.2. Sample CreateSD . . . . . . . . . . . . . . . . . . . 88 189 A.1.2.1. Sample CreateSDRequest . . . . . . . . . . . . . 88 190 A.1.2.2. Sample CreateSDResponse . . . . . . . . . . . . . 91 192 A.1.3. Sample UpdateSD . . . . . . . . . . . . . . . . . . . 92 193 A.1.3.1. Sample UpdateSDRequest . . . . . . . . . . . . . 93 194 A.1.3.2. Sample UpdateSDResponse . . . . . . . . . . . . . 94 195 A.1.4. Sample DeleteSD . . . . . . . . . . . . . . . . . . . 94 196 A.1.4.1. Sample DeleteSDRequest . . . . . . . . . . . . . 94 197 A.1.4.2. Sample DeleteSDResponse . . . . . . . . . . . . . 96 198 A.2. Sample TA Management Messages . . . . . . . . . . . . . . 98 199 A.2.1. Sample InstallTA . . . . . . . . . . . . . . . . . . 98 200 A.2.1.1. Sample InstallTARequest . . . . . . . . . . . . . 98 201 A.2.1.2. Sample InstallTAResponse . . . . . . . . . . . . 99 202 A.2.2. Sample UpdateTA . . . . . . . . . . . . . . . . . . . 101 203 A.2.2.1. Sample UpdateTARequest . . . . . . . . . . . . . 101 204 A.2.2.2. Sample UpdateTAResponse . . . . . . . . . . . . . 102 205 A.2.3. Sample DeleteTA . . . . . . . . . . . . . . . . . . . 105 206 A.2.3.1. Sample DeleteTARequest . . . . . . . . . . . . . 105 207 A.2.3.2. Sample DeleteTAResponse . . . . . . . . . . . . . 107 208 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 109 210 1. Introduction 212 The Trusted Execution Environment (TEE) concept has been designed and 213 used to increase security by separating regular operating systems, 214 also referred as Rich Execution Environment (REE), from security- 215 sensitive applications. In an TEE ecosystem, a Trust Service Manager 216 (TSM) is used to authorize manage keys and the Trusted Applications 217 (TA) that run in a device. Different device vendors may use 218 different TEE implementations. Different application providers may 219 use different TSM providers. There arises a need of an open 220 interoperable protocol that allows trustworthy TSM to manage security 221 domains and contents running in different Trusted Execution 222 Environment (TEE) of various devices. 224 The Open Trust Protocol (OTrP) defines a protocol between a TSM and a 225 TEE 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). 229 This specification assumes that a device that utilizes this 230 specification is equipped with a TEE and is pre-provisioned with a 231 device-unique public/private key pair, which is securely stored. 232 This key pair is referred as the 'root of trust'. A Service Provider 233 (SP) uses such a device to run Trusted Applications (TA). 235 A security domain is defined as the TEE representation of a service 236 provider and is a logical space that contains the service provider's 237 trusted applications. Each security domain requires the management 238 operations of trusted applications (TAs) in the form of installation, 239 update and deletion. 241 The protocol builds on the following properties of the system: 243 1. The SP needs to determine security-relevant information of a 244 device before provisioning information to a TEE. Examples 245 include the verification of the root of trust, the type of 246 firmware installed, and the type of TEE included in a device. 248 2. A TEE in a device needs to determine whether a SP or the TSM is 249 authorized to manage applications in the TEE. 251 3. Secure Boot must be able to ensure a TEE is genuine. 253 This specification defines message payloads exchanged between devices 254 and a TSM but does not mandate a specific transport. 256 2. Requirements Language 258 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 259 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 260 document are to be interpreted as described in RFC 2119 [RFC2119]. 262 3. Terminology 264 3.1. Definitions 266 The definitions provided below are defined as used in this document. 267 The same terms may be defined differently in other documents. 269 Client Application: An application running on a rich OS, such as an 270 Android, Windows, or iOS application, provided by a SP. 272 Device: A physical piece of hardware that hosts symmetric key 273 cryptographic modules 275 OTrP Agent: An application running in the rich OS allowing 276 communication with the TSM and the TEE. 278 Rich Application: Alternative name of "Client Application". In this 279 document we may use these two terms interchangably. 281 Rich Execution Environment (REE) An environment that is provided and 282 governed by a rich OS, potentially in conjunction with other 283 supporting operating systems and hypervisors; it is outside of 284 the TEE. This environment and applications running on it are 285 considered un-trusted. 287 Secure Boot Module (SBM): A firmware in a device that delivers 288 secure boot functionality. It is also referred as Trusted 289 Firmware (TFW) in this document. 291 Service Provider (SP): An entity that wishes to supply Trusted 292 Applications to remote devices. A Service Provider requires the 293 help of a TSM in order to provision the Trusted Applications to 294 the devices. 296 Trust Anchor: A root certificate that a module trusts. It is 297 usually embedded in one validating module, and used to validate 298 the trust of a remote entity's certificate. 300 Trusted Application (TA): Application that runs in TEE. 302 Trusted Execution Environment (TEE): An execution environment that 303 runs alongside but isolated from an REE. A TEE has security 304 capabilities and meets certain security-related requirements: It 305 protects TEE assets from general software attacks, defines rigid 306 safeguards as to data and functions that a program can access, 307 and resists a set of defined threats. There are multiple 308 technologies that can be used to implement a TEE, and the level 309 of security achieved varies accordingly. 311 3.2. Abbreviations 313 CA Certificate Authority 315 OTrP Open Trust Protocol 316 REE Rich Execution Environment 318 SD Security Domain 320 SP Service Provider 322 SBM Secure Boot Module 324 TA Trusted Application 326 TEE Trusted Execution Environment 328 TFW Trusted Firmware 330 TSM Trusted Service Manager 332 4. OTrP Entities and Trust Model 334 4.1. System Components 336 There are the following main components in this OTrP system. 338 TSM: The TSM is responsible for originating and coordinating 339 lifecycle management activity on a particular TEE. 341 A Trust Service Manager (TSM) is at the core to the protocol that 342 manages device trust check on behalf of service providers for the 343 ecosystem scalability. In addition to its device trust 344 management for a service provider, the TSM provides Security 345 Domain management and TA management in a device, in particularly, 346 over-the-air update to keep Trusted Applications up to date and 347 clean up when a version should be removed. 349 In the context of this specification, the term Trusted 350 Application Manager (TAM) and TSM are synonymous. 352 Certificate Authority (CA): Mutual trust between a device and a TSM 353 as well as a Service Provider is based on certificates. A device 354 embeds a list of root certificates, called Trust Anchors, from 355 trusted Certificate Authorities that a TSM will be validated 356 against. A TSM will remotely attest a device by checking whether 357 a device comes with a certificate from a trusted CA. 359 TEE: The TEE resides in the device chip security zone and is 360 responsible for protecting applications from attack, enabling the 361 application to perform secure operations 363 REE: The REE, usually called device OS such as Android OS in a phone 364 device, is responsible for enabling off device communications to 365 be established between the TEE and TSM. OTrP does not require 366 the device OS to be secure. 368 OTrP Agent: An application in the REE that can relay messages 369 between a Client Application and TEE. 371 Secure Boot: Secure boot (for the purposes of OTrP) must enable 372 authenticity checking of TEEs by the TSM. 374 The OTrP establishes appropriate trust anchors to enable TEE and TSMs 375 to communicate in a trusted way when performing lifecycle management 376 transactions. The main trust relationships between the components 377 are the following. 379 1. TSM must be able to ensure a TEE is genuine 381 2. TEE must be able to ensure a TSM is genuine 383 3. Secure Boot must be able to ensure a TEE is genuine 385 4.2. Trusted Anchors in TEE 387 The TEE in each device comes with a trust store that contains a 388 whitelist of TSM's root CA certificates, which are called Trust 389 Anchors. A TSM will be trusted to manage Security Domains and TAs in 390 a device only if its certificate is chained to one of the root CA 391 certificates in this trust store. 393 Such a list is typically embedded in TEE of a device, and the list 394 update is enabled and handled by device OEM provider. 396 4.3. Trusted Anchors in TSM 398 The Trust Anchor set in a TSM consists of a list of Certificate 399 Authority certificates that signs various device TEE certificates. A 400 TSM decides what TEE and TFW it will trust. 402 4.4. Keys and Cerificate Types 404 OTrP Protocol leverages the following list of trust anchors and 405 identities in generating signed and encrypted command messages that 406 are exchanged between a device with TEE and a TSM. With these 407 security artifacts, OTrP Messages are able to deliver end-to-end 408 security without relying on any transport security. 410 +-------------+----------+--------+-------------------+-------------+ 411 | Key Entity | Location | Issuer | Trust Implication | Cardinality | 412 | Name | | | | | 413 +-------------+----------+--------+-------------------+-------------+ 414 | 1. TFW | Device | OEM CA | A white list of | 1 per | 415 | keypair and | secure | | FW root CA | device | 416 | Certificate | storage | | trusted by TSMs | | 417 | | | | | | 418 | 2. TEE | Device | TEE CA | A white list of | 1 per | 419 | keypair and | TEE | under | TEE root CA | device | 420 | Certificate | | a root | trusted by TSMs | | 421 | | | CA | | | 422 | | | | | | 423 | 3. TSM | TSM | TSM CA | A white list of | 1 or | 424 | keypair and | provider | under | TSM root CA | multiple | 425 | Certificate | | a root | embedded in TEE | can be used | 426 | | | CA | | by a TSM | 427 | | | | | | 428 | 4. SP | SP | SP | TSM manages SP. | 1 or | 429 | keypair and | | signer | TA trust is | multiple | 430 | Certificate | | CA | delegated to TSM. | can be used | 431 | | | | TEE trusts TSM to | by a TSM | 432 | | | | ensure that a TA | | 433 | | | | is trustworthy. | | 434 +-------------+----------+--------+-------------------+-------------+ 436 Table 1: Key and Certificate Types 438 1. TFW keypair and Certificate: A key pair and certificate for 439 evidence of secure boot and trustworthy firmware in a device. 441 Location: Device secure storage 443 Supported Key Type: RSA and ECC 445 Issuer: OEM CA 447 Trust Implication: A white list of FW root CA trusted by TSMs 449 Cardinality: One per device 451 2. TEE keypair and Certificate: It is used for device attestation 452 to remote TSM and SP. 454 This key pair is burned into the device at device manufacturer. 455 The key pair and its certificate are valid for the expected 456 lifetime of the device. 458 Location: Device TEE 460 Supported Key Type: RSA and ECC 462 Issuer: TEE CA that chains to a root CA 464 Trust Implication: A white list of TEE root CA trusted by TSMs 466 Cardinality: One per device 468 3. TSM keypair and Certificate: A TSM provider acquires a 469 certificate from a CA that a TEE trusts. 471 Location: TSM provider 473 Supported Key Type: RSA and ECC. 475 Supported Key Size: RSA 2048-bit, ECC P-256 and P-384. 477 Issuer: TSM CA that chains to a root CA 479 Trust Implication: A white list of TSM root CA embedded in TEE 481 Cardinality: One or multiple can be used by a TSM 483 4. SP keypair and Certificate: A SP uses its own key pair and 484 certificate to sign a TA. 486 Location: SP 488 Supported Key Type: RSA and ECC 490 Supported Key Size: RSA 2048-bit, ECC P-256 and P-384 492 Issuer: SP signer CA that chains to a root CA 494 Trust Implication: TSM manages SP. TA trust is delegated to 495 TSM. TEE trusts TSM to ensure that a TA is trustworthy. 497 Cardinality: One or multiple can be used by a SP 499 5. Protocol Scope and Entity Relations 501 This document specifies the minimally required interoperable 502 artifacts to establish mutual trust between a TEE and TSM. The 503 protocol provides specifications for the following three entities: 505 1. Key and certificate types required for device firmware, TEE, TA, 506 SP, and TSM 508 2. Data message formats that should be exchanged between a TEE in a 509 device and a TSM 511 3. An OTrP Agent application in the REE that can relay messages 512 between a Client Application and TEE 514 Figure 1: Protocol Scope and Entity Relationship 516 PKI CA --CA CA-- 517 | | | 518 | | | 519 | | | 520 Device | | ----OTrP Agent --- Rich App --- | 521 SW | | | | | 522 | | | | | 523 | | | | | 524 OTrP | -- TEE TSM------- 525 | 526 | 527 FW 529 Figure 2: OTrP System Diagram 530 ---OTrP Message Protocol-- 531 | | 532 | | 533 -------------------- --------------- ---------- 534 | REE | TEE | | TSM | | SP | 535 | --- | --- | | --- | | -- | 536 | | | | | | | 537 | Client | SD (TAs)| | SD / TA | | TA | 538 | Apps | | | Mgmt | | | 539 | | | | | | | | 540 | | | | | | | | 541 | OTrP | Trusted | | Trusted | | | 542 | Agent | CAs | | FW, TEE CAs | | | 543 | | | | | | | 544 | |TEE Key/ | | TSM Key/ | |SP Key/ | 545 | | Cert | | Cert | | Cert | 546 | | FW Key/ | | | | | 547 | | Cert | | | | | 548 ------------------ --------------- ---------- 549 | | | 550 | | | 551 ----------------------------------------- 552 | 553 | 554 -------------- 555 | CA | 556 -------------- 558 In the previous diagram, different Certificate Authorities can be 559 used respectively for different types of certificates. OTrP Messages 560 are always signed, where the signer keys is the message creator's key 561 pair such as a FW key pair, TEE key pair or TSM key pair. 563 The main OTrP Protocol component is the set of standard JSON messages 564 created by TSM to deliver device SD and TA management commands to a 565 device, and device attestation and response messages created by TEE 566 to respond to TSM OTrP Messages. 568 The communication method of OTrP Messages between a TSM and TEE in a 569 device is left to TSM providers for maximal interoperability. A TSM 570 can work with its SP and Client Applications how it gets OTrP 571 Messages from a TSM. When a Client Application has had an OTrP 572 Message from its TSM, it is imperative to have an interoperable 573 interface to communicate with various TEE types. This is the OTrP 574 Agent interface that serves this purpose. The OTrP Agent doesn't 575 need to know the actual content of OTrP Messages except for the TEE 576 routing information. 578 5.1. A Sample Device Setup Flow 580 TBD 582 5.2. Derived Keys in the Protocol 584 The protocol generates the following two key pairs in run time to 585 assist message communication and anonymous verification between TSM 586 and TEE. 588 1. TEE Anonymous Key (TEE AIK): one derived key pair per TEE in a 589 device 591 The purpose of the key pair is to sign data by a TEE without using 592 its TEE device key for anonymous attestation to a Client Application. 593 This key is generated in the first GetDeviceState query. The public 594 key of the key pair is returned to the caller Client Application for 595 future TEE returned data validation. 597 2. TEE SP AIK: one derived key per SP in a device 599 The purpose of this key pair is for a TSM to encrypt TA binary data 600 when it sends a TA to a device for installation. This key is 601 generated in the first SD creation for a SP. It is deleted when all 602 SDs are removed for a SP in a device. 604 With the presence of a TEE SP AIK, it isn't necessary to have a 605 shared SP independent TEE AIK. For the initial release, this 606 specification will not use TEE AIK. 608 5.3. Security Domain Hierarchy and Ownership 610 The primary job of a TSM is to help a SP to manage its trusted 611 applications. A TA is typically installed in a SD. A SD is commonly 612 created for a SP. 614 When a SP delegates its SD and TA management to a TSM, a SD is 615 created on behalf of a TSM in a TEE and the owner of the SD is 616 assigned to the TSM. A SD may be associated with a SP but the TSM 617 has full privilege to manage the SD for the SP. 619 Each SD for a SP is associated with only one TSM. When a SP changes 620 TSM, a new SP SD must be created to associate with the new TSM. TEE 621 will maintain a registry of TSM ID and SP SD ID mapping. 623 From a SD ownership perspective SD tree is flat and there is only one 624 level. A SD is associated with its owner. It is up to TEE's 625 implementation how it maintains SD binding information for TSM and 626 different SPs under the same TSM. 628 It is an important decision in this protocol specification that a TEE 629 doesn't need to know whether a TSM is authorized to manage SD for a 630 SP. This authorization is implicitly triggered by a SP Client 631 Application, which instructs what TSM it wants to use. A SD is 632 always associated with a TSM in addition to its SP ID. A rogue TSM 633 isn't able to do anything on an unauthorized SP's SD managed by 634 another TSM. 636 Since a TSM may support multiple SPs, sharing the same SD name for 637 different SP creates a dependency in deleting a SD. A SD can be 638 deleted only after all TAs associated with this SD is deleted. A SP 639 cannot delete a Security Domain on its own with a TSM if a TSM 640 decides to introduce such sharing. There are cases where multiple 641 virtual SPs belong to the same organization, and a TSM chooses to use 642 the same SD name for those SPs. This is totally up to the TSM 643 implementation and out of scope of this specification. 645 5.4. SD Owner Identification and TSM Certificate Requirements 647 There is a need of cryptographically binding proof about the owner of 648 a SD in device. When a SD is created on behalf of a TSM, a future 649 request from the TSM must present itself as a way that the TEE can 650 verify it is the true owner. The certificate itself cannot reliably 651 used as the owner because TSM may change its certificate. 653 To this end, each TSM will be associated with a trusted identifier 654 defined as an attribute in the TSM certificate. This field is kept 655 the same when the TSM renew its certificates. A TSM CA is 656 responsible to vet the requested TSM attribute value. 658 This identifier value must not collide among different TSM providers, 659 and one TSM shouldn't be able to claim the identifier used by another 660 TSM provider. 662 The certificate extension name to carry the identifier can initially 663 use SubjectAltName:registeredID. A dedicated new extension name may 664 be registered later. 666 One common choice of the identifier value is the TSM's service URL. 667 A CA can verify the domain ownership of the URL with the TSM in the 668 certificate enrollment process. 670 TEE can assign this certificate attribute value as the TSM owner ID 671 for the SDs that are created for the TSM. 673 An alternative way to represent a SD ownership by a TSM is to have a 674 unique secret key upon SD creation such that only the creator TSM is 675 able to produce a Proof-of-Possession (POP) data with the secret. 677 5.5. Service Provider Container 679 A sample Security Domain hierarchy for the TEE is shown below. 681 [[TBD diagram]] 683 The OTrP assumes that a SP managed by TSM1 cannot be managed by TSM2. 684 Explicit permission grant should happen. SP can authorize TSM. 686 6. OTrP Agent 688 OTrP Agent is an Rich Application or SDK that facilitates 689 communication between a TSM and TEE. It also provides interfaces for 690 TSM SDK or Client Applications to query and trigger TA installation 691 that the application needs to use. 693 This interface for Client Applications may be commonly an Android 694 service call. A Client Application interacts with a TSM, and turns 695 around to pass messages received from TSM to OTrP Agent. 697 In all cases, a Client Application needs to be able to identify an 698 OTrP Agent that it can use. 700 6.1. Role of OTrP Agent 702 OTrP Agent is responsible to communicate with TEE. It takes request 703 messages from an application. The input data is mostly from a TSM 704 that an application communicates. An application may also directly 705 call OTrP Agent for some TA query functions. 707 OTrP Agent may internally process a request from TSM. At least, it 708 needs to know where to route a message, e.g. TEE instance. It 709 doesn't need to process or verify message content. 711 OTrP Agent returns TEE / TFW generated response messages to the 712 caller. OTrP Agent isn't expected to handle any network connection 713 with an application or TSM. 715 OTrP Agent only needs to return an OTrP Agent error message if the 716 TEE is not reachable for some reason. Other errors are represented 717 as response messages returned from the TEE which will then be passed 718 to the TSM. 720 6.2. OTrP Agent and Global Platform TEE Client API 722 A Client Application may rely on Global Platform (GP) TEE API for TA 723 communication. OTrP may use the GP TEE Client API but it is internal 724 to OTrP implementation that converts given messages from TSM. More 725 details can be found at [GPTEE]. 727 6.3. OTrP Agent Implementation Consideration 729 A Provider should consider methods of distribution, scope and 730 concurrency on device and runtime options when implementing an OTrP 731 Agent. Several non-exhaustive options are discussed below. 732 Providers are encouraged to take advantage of the latest 733 communication and platform capabilities to offer the best user 734 experience. 736 6.3.1. OTrP Agent Distribution 738 OTrP Agent installation is commonly carried out at OEM time. A user 739 can dynamically download and install an OTrP Agent on-demand. 741 It is important to ensure a legitimate OTrP Agent is installed and 742 used. If an OTrP Agent is compromised it may send rogue messages to 743 TSM and TEE and introduce additional risks. 745 6.3.2. Number of OTrP Agent 747 We anticipate only one shared OTrP Agent instance in a device. The 748 device's TEE vendor will most probably supply one OTrP Agent. 749 Potentially we expect some open source. 751 With one shared OTrP Agent, the OTrP Agent provider is responsible to 752 allow multiple TSMs and TEE providers to achieve interoperability. 753 With a standard OTrP Agent interface, TSM can implement its own SDK 754 for its SP Client Applications to work with this OTrP Agent. 756 Multiple independent OTrP Agent providers can be used as long as they 757 have standard interface to a Client Application or TSM SDK. Only one 758 OTrP Agent is expected in a device. 760 OTrP Protocol MUST specify a standard way for applications to lookup 761 the active OTrP Agent instance in a device. 763 TSM providers are generally expected to provide SDK for SP 764 applications to interact with OTrP Agent for the TSM and TEE 765 interaction. 767 6.3.3. OTrP Android Service Option 769 OTrP Agent can be a bound service in Android with a service 770 registration ID that a Client Application can use. This option 771 allows a Client Application not to depend on any OTrP Agent SDK or 772 provider. 774 An OTrP Agent is responsible to detect and work with more than one 775 TEE if a device has more than one. In this version, there is only 776 one active TEE such that an OTrP Agent only needs to handle the 777 active TEE. 779 6.4. OTrP Agent API for Client Applications 781 The client application shall be responsible for relaying messages 782 between the OTrP agent and the TSM. 784 OTrP Agent APIs are defined below. An OTrP Agent in the form of an 785 Android bound service can take this to be the functionality it 786 provides via service call. The OTrP Agent implements this interface. 788 If a failure is occured during calling API, an error message 789 described in "Common Errors" section (see Section 7.6) will be 790 returned. 792 interface IOTrPAgentService { 793 String processMessage(String tsmInMsg) throws OTrPAgentException; 794 String getTAInformation(String spid, String taid) 795 throws OTrPAgentException; 796 } 798 public class OTrPAgentException extends Throwable { 799 private int errCode; 800 } 802 6.4.1. API processMessage 804 String processMessage(String tsmInMsg) throws OTrPAgentException; 806 Description 808 A Client Application will use this method of the OTrP Agent in a 809 device to pass OTrP messages from a TSM. The method is 810 responsible for interation with the TEE and for forwarding the 811 input message to the TEE. It also returns TEE generated response 812 message back to the Client Application. 814 Input 815 tsmInMsg - OTrP message generated in a TSM that is passed to this 816 method from a Client Application. 818 Output 820 A TEE generated OTrP response message (which may be a successful 821 response or be a response message containing an error raised 822 within the TEE) for the client application to forward to the TSM. 823 In the event of the OTrP agent not being able to communicate with 824 the TEE, a OTrPAgentException shall be thrown. 826 6.4.2. API getTAInformation 828 String getTAInformation(String spid, String taid) 829 throws OTrPAgentException; 831 Description 833 A Client Application calls this method to query a TA's 834 information. This method is carried out locally by the OTrP Agent 835 without relying on a TSM if it has had the TEE SP AIK. 837 Input 839 spid - SP identifier of the TA 841 taid - the identifier of the TA 843 Output 845 The API returns TA signer and TSM signer certificate along with 846 other metadata information about a TA. 848 The output is a JSON message that is generated by the TEE. It 849 contains the following information: 851 * TSMID 853 * SP ID 855 * TA signer certificate 857 * TSM certificate 859 The message is signed with TEE SP AIK private key. 861 The Client Application is expected to consume the response as 862 follows. 864 The Client Application gets signed TA metadata, in particularly, 865 the TA signer certificate. It is able to verify that the result 866 is from device by checking signer against TEE SP AIK public key it 867 gets in some earlier interaction with TSM. 869 If this is a new Client Application in the device that hasn't had 870 TEE SP AIK public key for the response verification, the 871 application can contact TSM first to do GetDeviceState, and TSM 872 will return TEE SP AIK public key to the app for this operation to 873 proceed. 875 JSON Message 877 { 878 "TAInformationTBS": { 879 "taid": "", 880 "tsmid": "", 882 "spid": "", 883 "signercert": "", 885 "signercacerts": [ // the full list of CA certificate chain 886 // including the root CA 887 "cacert": "" 889 ], 890 "tsmcert": "", 892 "tsmcacerts": [ // the full list of CA certificate chain 893 // including the root CA 894 "cacert":"" 896 ] 897 } 898 } 900 { 901 "TAInformation": { 902 "payload": "", 904 "protected": "", 905 "header": { 906 "signer": {""} 908 }, 909 "signature": "" 911 } 912 } 914 A sample JWK public key representation refers to an example in RFC 915 7517 [RFC7517] . 917 6.5. Sample End-to-End Client Application Flow 919 6.5.1. Case 1: A new Client App uses a TA 921 1. During the Client App installation time, the Client App calls 922 TSM to initialize device preparation 923 A. The Client Application knows it wants to use a TA1 but the 924 application doesn'tknow whether TA1 has been installed or 925 not. It can use GP TEE Client API to check the existence of 926 TA1 first. If it doesn't exist, it will contact TSM to 927 initiate the TA1 installation. Note that TA1 could have 928 been installed that is triggered by other Client 929 Applications of the same service provider in the same 930 device. 932 B. The Client Application sends TSM the TA list that it depends 933 on. The TSM will query a device for the Security Domains 934 and TAs that have been installed, and instructs the device 935 to install any dependent TAs that have not been installed. 937 C. In general, TSM has the latest information of TA list and 938 their status in a device because all operations are 939 instructed by TSM. TSM has such visibility because all 940 Security Domain deletion and TA deletion are managed by TSM; 941 the TSM could have stored the state when a TA is installed, 942 updated and deleted. There is also the possibility that an 943 update command is carried out inside TEE but a response is 944 never received in TSM. There is also possibility that some 945 manual local reset is done in a device that the TSM isn't 946 aware of the changes. 948 2. TSM generates message: GetDeviceStateRequest 950 3. The Client Application passes the JSON message 951 GetDeviceStateRequest to OTrP Agent API processMessage. The 952 communication between a Client Application and OTrP Agent is up 953 to the implementation of OTrP Agent. 955 4. OTrP Agent routes the message to the active TEE. Multiple TEE 956 case: it is up to OTrP Agent to figure this out. This 957 specification limits the support to only one active TEE, which 958 is the typical case today. 960 5. The target active TEE processes the received OTrP message, 961 returns a JSON message GetDeviceStateResponse 963 6. The OTrP Agent passes the GetDeviceStateResponse to the Client 964 App 966 7. The Client Application sends GetDeviceStateResponse to TSM 968 8. TSM processes GetDeviceStateResponse 969 A. Extract TEEspaik for the SP, signs TEEspaik with TSM signer 970 key 972 B. Examine SD list and TA list 974 9. TSM continues to carry out other actions basing on the need. 975 The next call could be instructing the device to install a 976 dependent TA. 978 A. Assume a dependent TA isn't in the device yet, the TSM may 979 do the following: 981 B. 983 Create a SD to install the TA by sending a message 984 CreateSDRequest. The message is sent back to the Client 985 Application, and then OTrP Agent and TEE to process. 987 Install a TA with a message InstallTARequest. 989 C. If a Client Application depends on multiple TAs, the Client 990 Application should expect multiple round trips of the TA 991 installation message exchanges. 993 10. At the last TSM and TEE operation, TSM returns the signed TEE SP 994 AIK public key to the application 996 11. The Client Application shall store the TEEspaik for future 997 loaded TA trust check purpose. 999 12. If the TSM finds that this is a fresh device that does not have 1000 any SD for the SP yet, then the TSM may move on to create a SD 1001 for the SP next. The TSM may move on to create a SD for the SP 1002 next. 1004 13. During Client Application installation, the application checks 1005 whether required Trusted Applications are already installed, 1006 which may have been provided by TEE. If needed, it will contact 1007 its TSM service to determine whether the device is ready or 1008 install TA list that this application needs. 1010 6.5.2. Case 2: A previously installed Client Application calls a TA 1012 1. The Client Application checks the device readiness: (a) whether 1013 it has a TEE; (b) whether it has TA that it depends. It may 1014 happen that TSM has removed TA this application depends on. 1016 2. The Client App calls OTrP Agent method "GetTAInformation" 1017 3. OTrP Agent queries the TEE to get TA information. If the given 1018 TA doesn't exist, an error is returned 1020 4. The Client App parses the TAInformation message. 1022 5. If the TA doesn't exist, the Client App calls its TSM to install 1023 the TA. If the TA exists, the Client App proceeds to call the 1024 TA. 1026 7. OTrP Messages 1028 The main OTrP Protocol component is the set of standard JSON messages 1029 created by TSM to deliver device SD and TA management commands to a 1030 device, and device attestation and response messages created by TEE 1031 to respond to TSM OTrP Messages. 1033 An OTrP Message is designed to provide end-to-end security. It is 1034 always signed by its creator. In addition, an OTrP Message is 1035 typically encrypted such that only the targeted device TEE or TSM 1036 provider is able to decrypt and view the actual content. 1038 7.1. Message Format 1040 OTrP Messages use JSON format for JSON's simple readability and 1041 moderate data size in comparison with alternative TLV and XML 1042 formats. 1044 JSON Message security has developed JSON Web Signing and JSON Web 1045 Encryption standard in the IETF Workgroup JOSE, see JWS [RFC7515] and 1046 JWE [RFC7516]. The OTrP Messages in this protocol will leverage the 1047 basic JWS and JWE to handle JSON signing and encryption. 1049 7.2. Message Naming Convention 1051 For each TSM command "xyz"", OTrP Protocol use the following naming 1052 convention to represent its raw message content and complete request 1053 and response messages: 1055 +-----------------------+----------------+---------------------+ 1056 | Purpose | Message Name | Example | 1057 +-----------------------+----------------+---------------------+ 1058 | Request to be signed | xyzTBSRequest | CreateSDTBSRequest | 1059 | | | | 1060 | Request message | xyzRequest | CreateSDRequest | 1061 | | | | 1062 | Response to be signed | xyzTBSResponse | CreateSDTBSResponse | 1063 | | | | 1064 | Response message | xyzResponse | CreateSDResponse | 1065 +-----------------------+----------------+---------------------+ 1067 7.3. Request and Response Message Template 1069 An OTrP Request message uses the following format: 1071 { 1072 "TBSRequest": { 1073 1074 } 1075 } 1077 A corresponding OTrP Response message will be as follows. 1079 { 1080 "TBSResponse": { 1081 1082 } 1083 } 1085 7.4. Signed Request and Response Message Structure 1087 A signed request message will generally include only one signature, 1088 and uses the flattened JWS JSON Serialization Syntax, see 1089 Section 7.2.2 in RFC7515 [RFC7515] . 1091 A general JWS object looks like the following. 1093 { 1094 "payload": "", 1095 "protected":"", 1096 "header": { 1097 , 1098 }, 1099 "signature":"" 1100 } 1101 OTrP signed messages only requires the signing algorithm as the 1102 mandate header in the property "protected". The "non-integrity- 1103 protected header contents" is optional. 1105 OTrP signed message will be given an explicit Request or Response 1106 property name. In other words, a signed Request or Response uses the 1107 following template. 1109 A general JWS object looks like the following. 1111 { 1112 "[Request | Response]": { 1113 TBS[Request | Response] 1114 } 1115 } 1117 With the standard JWS message format, a signed OTrP Message looks 1118 like the following. 1120 { 1121 "[Request | Response]": { 1122 "payload": "TBS[Request | Response]>", 1123 "protected":"", 1124 "header": , 1125 "signature":"" 1126 } 1127 } 1129 The top element " [Signed][Request | Response]" cannot be fully 1130 trusted to match the content because it doesn't participate the 1131 signature generation. However, a recipient can always match it with 1132 the value associated with the property "payload". It purely serves 1133 to provide a quick reference for reading and method invocation. 1135 Furthermore, most properties in an unsigned OTrP messages are 1136 encrypted to provide end-to-end confidentiality. The only OTrP 1137 message that isn't encrypted is the initial device query message that 1138 asks for the device state information. 1140 Thus a typical OTrP Message consists of an encrypted and then signed 1141 JSON message. Some transaction data such as transaction ID and TEE 1142 information may need to be exposed to OTrP Agent for routing purpose. 1143 Such information is excluded from JSON encryption. The device's 1144 signer certificate itself is encrypted. The overall final message is 1145 a standard signed JSON message. 1147 As required by JSW/JWE, those JWE and JWS related elements will be 1148 BASE64URL encoded. Other binary data elements specific to the OTrP 1149 specification are BASE64 encoded. This specification will identify 1150 elements that should be BASE64 and those elements that are to be 1151 BASE64URL encoded. 1153 7.4.1. Identifying signing and Encryption keys for JWS/JWE messaging 1155 JWS and JWE messaging allow various options for identifying the 1156 signing and encryption keys, for example, it allows optional elements 1157 including "x5c", "x5t" and "kid" in the header to cover various 1158 possibilities. 1160 In order to protect privacy, it is important that the device's 1161 certificate is released only to a trusted TSM, and that it is 1162 encrypted. The TSM will need to know the device certificate, but 1163 untrusted parties must not be able to get the device certificate. 1164 All OTrP messaging conversations between a TSM and device begin with 1165 GetDeviceStateRequest / GetDeviceStateResponse. These messages have 1166 elements built into them to exchange signing certificates, described 1167 in the "Detailed Message Specification" section. Any subsequent 1168 messages in the conversation that follow on from this are implicitly 1169 using the same certificates for signing/encryption, and as a result 1170 the certificates or references may be ommitted in those subsequent 1171 messages. 1173 In other words, the signing key identifier in the use of JWS and JWE 1174 here may be absent in the subsequent messages after the initial 1175 GetDeviceState query. 1177 This has implication on the TEE and TSM implementation: they have to 1178 cache the signer certificates for the subsequent message signature 1179 validation in the session. It may be easier for a TSM service to 1180 cache transaction session information but not so for a TEE in a 1181 device. A TSM should check a device's capability to decide whether 1182 it should include its TSM signer certificate and OCSP data in each 1183 subsequent request message. The device's caching capability is 1184 reported reported in GetDeviceStateResponse signerreq parameter. 1186 7.5. JSON Signing and Encryption Algorithms 1188 The OTrP JSON signing algorithm shall use SHA256 or a stronger hash 1189 method with respective key type. JSON Web Algorithm RS256 or ES256 1190 [RFC7518] SHALL be used for RSA with SHA256 and ECDSA with SHA256. 1191 If RSA with SHA256 is used, the JSON web algorithm representation is 1192 as follows. 1194 {"alg":"RS256"} 1196 The (BASE64URL encoded) "protected" header property in a signed 1197 message looks like the following: 1199 "protected":"eyJhbGciOiJSUzI1NiJ9" 1201 If ECSDA with P-256 curve and SHA256 are used for signing, the JSON 1202 signing algorithm representation is as follows. 1204 {"alg":"ES256"} 1206 The value for the "protected" field will be the following. 1208 eyJhbGciOiJFUzI1NiJ9 1210 Thus a common OTrP signed message with ES256 looks like the 1211 following. 1213 { 1214 "payload": "", 1215 "protected": "eyJhbGciOiJFUzI1NiJ9", 1216 "signature":"" 1217 } 1219 The OTrP JSON message encryption algorithm should use one of the 1220 supported algorithms defined in the later chapter of this document. 1221 JSON encryption uses a symmetric key as its "Content Encryption Key 1222 (CEK)". This CEK is encrypted or wrapped by a recipient's key. OTrP 1223 recipient typically has an asymmetric key pair. Therefore CEK will 1224 be encrypted by the recipient's public key. 1226 Symmetric encryption shall use the following algorithm. 1228 {"enc":"A128CBC-HS256"} 1230 This algorithm represents encryption with AES 128 in CBC mode with 1231 HMAC SHA 256 for integrity. The value of the property "protected" in 1232 a JWE message will be 1234 eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0 1236 An encrypted JSON message looks like the following. 1238 { 1239 "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0", 1240 "recipients": [ 1241 { 1242 "header": { 1243 "alg": "" 1244 }, 1245 "encrypted_key": "" 1246 } 1247 ], 1248 "iv": "", 1249 "ciphertext": "", 1251 "tag": "" 1252 } 1254 OTrP doesn't use JWE AAD (Additional Authenticated Data) because each 1255 message is always signed after the message is encrypted. 1257 7.5.1. Supported JSON Signing Algorithms 1259 The following JSON signature algorithm are mandatory support in TEE 1260 and TSM: 1262 o RS256 1264 ES256 is optional to support. 1266 7.5.2. Support JSON Encryption Algorithms 1268 The following JSON authenticated encryption algorithm is mandatory 1269 support in TEE and TSM. 1271 o A128CBC-HS256 1273 A256CBC-HS512 is optional to support. 1275 7.5.3. Supported JSON Key Management Algorithms 1277 The following JSON key management algorithm is mandatory support in 1278 TEE and TSM. 1280 o RSA1_5 1282 ECDH-ES+A128KW and ECDH-ES+A256KW are optional to support. 1284 7.6. Common Errors 1286 An OTrP Response message typically needs to report operation status 1287 and error causes if an operation fails. The following JSON message 1288 elements should be used across all OTrP Messages. 1290 "status": "pass | fail" 1292 "reason": { 1293 "error-code": "", 1294 "error-message": "" 1295 } 1297 "ver": "" 1299 7.7. OTrP Message List 1301 The following table lists the OTrP commands and therefore 1302 corresponding Request and Response messages defined in this 1303 specification. Additional messages may be added in the future when 1304 new task messages are needed. 1306 GetDeviceState - 1307 A TSM queries a device's current state with a message 1308 GetDeviceStateRequest. A device TEE will report its version, its 1309 FW version, and list of all SD and TA in the device that is 1310 managed by the requesting TSM. TSM may determine whether the 1311 device is trustworthy and decide to carry out additional commands 1312 according to the response from this query. 1314 CreateSD - 1315 A TSM instructs a device TEE to create a SD for a SP. The 1316 recipient TEE will check whether the requesting TSM is 1317 trustworthy. 1319 UpdateSD - 1320 A TSM instructs a device TEE to update an existing SD. A typical 1321 update need comes from SP certificate change, TSM certificate 1322 change and so on. The recipient TEE will verify whether the TSM 1323 is trustworthy and owns the SD. 1325 DeleteSD - 1326 A TSM instructs a device TEE to delete an existing SD. A TEE 1327 conditionally deletes TAs loaded in the SD according to a request 1328 parameter. A SD cannot be deleted until all TAs in this SD are 1329 deleted. If this is the last SD for a SP, TEE can also delete 1330 TEE SP AIK key for this SP. 1332 InstallTA - 1333 A TSM instructs a device to install a TA into a SD for a SP. TEE 1334 in a device will check whether the TSM and TA are trustworthy. 1336 UpdateTA - 1337 A TSM instructs a device to update a TA into a SD for a SP. The 1338 change may commonly be bug fix for a previously installed TA. 1340 DeleteTA - 1341 A TSM instructs a device to delete a TA. TEE in a device will 1342 check whether the TSM and TA are trustworthy. 1344 7.8. OTrP Request Message Routing Rules 1346 For each command that a TSM wants to send to a device, the TSM 1347 generates a request message. This is typically triggered by a Client 1348 Application that uses the TSM. The Client Application initiates 1349 contact with the TSM and receives TSM OTrP Request messages according 1350 to the TSM's implementation. The Client Application forwards the 1351 OTrP message to an OTrP Agent in the device, which in turn sends the 1352 message to the active TEE in the device. 1354 The current version of specification assumes that each device has 1355 only one active TEE, and OTrP Agent is responsible to connect to the 1356 active TEE. This is the case today with devices in the market. 1358 Upon TEE responding with a request, the OTrP Agent gets OTrP response 1359 messages back to the Client Application that sends the request. In 1360 case the target TEE fails to respond the request, the OTrP Agent will 1361 be responsible to generate an error message to reply the Client 1362 Application. The Client Application forwards any data it received to 1363 its TSM. 1365 7.8.1. SP Anonymous Attestation Key (SP AIK) 1367 When the first new Security Domain is created in TEE for a SP, a new 1368 key pair is generated and associated with this SP. This key pair is 1369 used for future device attestation to the service provider instead of 1370 using device's TEE key pair. 1372 8. Detailed Messages Specification 1374 For each message in the following sections all JSON elements are 1375 mandatory if it isn't explicitly indicated as optional. 1377 8.1. GetDeviceState 1379 This is the first command that a TSM will query a device. This 1380 command is triggered when a SP's Client Application contacts its TSM 1381 to check whether the underlying device is ready for TA operations. 1383 This command queries a device's current TEE state. A device TEE will 1384 report its version, its FW version, and list of all SD and TA in the 1385 device that is managed by the requesting TSM. TSM may determine 1386 whether the device is trustworthy and decide to carry out additional 1387 commands according to the response from this query. 1389 The request message of this command is signed by TSM. The response 1390 message from TEE is encrypted. A random message encryption key (MK) 1391 is generated by TEE, and this encrypted key is encrypted by the 1392 receiving TSM public key such that only the TSM who sent the request 1393 is able to decrypt and view the response message. 1395 8.1.1. GetDeviceStateRequest message 1397 { 1398 "GetDeviceStateTBSRequest": { 1399 "ver": "1.0", 1400 "rid": "", 1401 "tid": "", 1402 "ocspdat": "", 1403 "icaocspdat": "", 1404 "supportedsigalgs": "" 1405 } 1406 } 1408 The request message consists of the following data elements: 1410 ver - version of the message format 1412 rid - a unique request ID generated by the TSM 1414 tid - a unique transaction ID to trace request and response. This 1415 can be from a prior transaction's tid field, and can be used in 1416 the subsequent message exchanges in this TSM session. The 1417 combination of rid and tid should be made unique. 1419 ocspdat - OCSP stapling data for the TSM certificate. The TSM 1420 provides OCSP data such that a recipient TEE can validate the 1421 validity of the TSM certificate without making its own external 1422 OCSP service call. This is a mandate field. 1424 icaocspdat - OCSP stapling data for the intermediate CA 1425 certificates of the TSM certificate up to the root. A TEE side 1426 can cache CA OCSP data such that this value isn't needed in each 1427 call. 1429 supportedsigalgs - an optional property to list the signing 1430 algorithms that TSM is able to support. A recipient TEE should 1431 choose algorithm in this list to sign its response message if 1432 this property is present in a request. 1434 The final request message is JSON signed message of the above raw 1435 JSON data with TSM's certificate. 1437 { 1438 "GetDeviceStateRequest": { 1439 "payload":"", 1441 "protected": "", 1442 "header": { 1443 "x5c": "" 1445 }, 1446 "signature":"" 1447 } 1448 } 1450 The signing algorithm should use SHA256 with respective key type. 1451 The mandatory algorithm support is the RSA signing algorithm. The 1452 signer header "x5c" is used to include the TSM signer certificate up 1453 to the root CA certificate. 1455 8.1.2. Request processing requirements at a TEE 1457 Upon receiving a request message GetDeviceStateRequest at a TEE, the 1458 TEE must validate a request: 1460 1. Validate JSON message signing 1462 2. Validate that the request TSM certificate is chained to a trusted 1463 CA that the TEE embeds as its trust anchor. 1465 * Cache the CA OCSP stapling data and certificate revocation 1466 check status for other subsequent requests. 1468 * A TEE can use its own clock time for the OCSP stapling data 1469 validation. 1471 3. Validate JSON message signing 1472 4. Collect Firmware signed data 1474 * This is a capability in ARM architecture that allows a TEE to 1475 query Firmware to get FW signed data. 1477 5. Collect SD information for the SD owned by this TSM 1479 8.1.3. Firmware signed data 1481 Firmware isn't expected to process or produce JSON data. It is 1482 expected to just sign some raw bytes of data. 1484 The data to be signed by TFW key needs be some unique random data 1485 each time. The (UTF-8 encoded) "tid" value from the 1486 GetDeviceStateTBSRequest shall be signed by the firmware. TSM isn't 1487 expected to parse TFW data except the signature validation and signer 1488 trust path validation. 1490 It is possible that a TEE can get some valid TFW signed data from 1491 another device. This is part of the TEE trust assumption where TSM 1492 will trust the TFW data supplied by the TEE. The TFW trust is more 1493 concerned by TEE than a TSM where a TEE needs to ensure that the 1494 underlying device firmware is trustworthy. 1496 TfwData: { 1497 "tbs": "", 1498 "cert": "", 1499 "sigalg": "Signing method", 1500 "sig": "" 1501 } 1503 It is expected that FW use a standard signature methods for maximal 1504 interoperability with TSM providers. The mandatory support list of 1505 signing algorithm is RSA with SHA256. 1507 The JSON object above is constructed by TEE with data returned from 1508 FW. It isn't a standard JSON signed object. The signer information 1509 and data to be signed must be specially processed by TSM according to 1510 definition given here. The data to be signed is the raw data. 1512 8.1.3.1. Supported Firmware Signature Methods 1514 TSM providers shall support the following signature methods. A 1515 firmware provider can choose one of the methods in signature 1516 generation. 1518 o RSA with SHA256 1519 o ECDSA with SHA 256 1521 The value of "sigalg" in the TfwData JSON message should use one of 1522 the following: 1524 o RS256 1526 o ES256 1528 8.1.4. Post Conditions 1530 Upon successful request validation, the TEE information is collected. 1531 There is no change in the TEE in the device. 1533 The response message shall be encrypted where the encryption key 1534 shall be a symmetric key that is wrapped by TSM's public key. The 1535 JSON Content Encryption Key (CEK) is used for this purpose. 1537 8.1.5. GetDeviceStateResponse message 1539 The message has the following structure. 1541 { 1542 "GetDeviceTEEStateTBSResponse": { 1543 "ver": "1.0", 1544 "status": "pass | fail", 1545 "rid": "", 1546 "tid": "", 1547 "signerreq": "true | false about whether TSM needs to send 1548 signer data again in subsequent messages", 1549 "edsi": "" 1550 } 1551 } 1553 where 1555 signerreq - true if the TSM should send its signer certificate and 1556 OCSP data again in the subsequent messages. The value may be 1557 "false" if the TEE caches the TSM's signer certificate and OCSP 1558 status. 1560 rid - the request ID from the request message 1562 tid - the tid from the request message 1564 edsi - the main data element whose value is JSON encrypted message 1565 over the following Device State Information (DSI). 1567 The Device State Information (DSI) message consists of the following. 1569 { 1570 "dsi": { 1571 "tfwdata": { 1572 "tbs": "" 1573 "cert": "", 1574 "sigalg": "Signing method", 1575 "sig": "" 1576 }, 1577 "tee": { 1578 "name": "", 1579 "ver": "", 1580 "cert": "", 1581 "cacert": "", 1583 "sdlist": { 1584 "cnt": "", 1585 "sd": [ 1586 { 1587 "name": "", 1588 "spid": "", 1589 "talist": [ 1590 { 1591 "taid": "", 1592 "taname": "" // optional 1594 } 1595 ] 1596 } 1597 ] 1598 }, 1599 "teeaiklist": [ 1600 { 1601 "spaik": "", 1602 "spaiktype": "", 1603 "spid": "" 1604 } 1605 ] 1606 } 1607 } 1608 } 1610 The encrypted JSON message looks like the following. 1612 { 1613 "protected": "", 1615 "recipients": [ 1616 { 1617 "header": { 1618 "alg": "RSA1_5" 1619 }, 1620 "encrypted_key": "" 1621 } 1622 ], 1623 "iv": "", 1624 "ciphertext": "", 1626 "tag": "" 1627 } 1629 Assume we encrypt plaintext with AES 128 in CBC mode with HMAC SHA 1630 256 for integrity, the encryption algorithm header is: 1632 {"enc":"A128CBC-HS256"} 1634 The value of the property "protected" in the above JWE message will 1635 be 1637 eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0 1639 In other words, the above message looks like the following: 1641 { 1642 "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0", 1643 "recipients": [ 1644 { 1645 "header": { 1646 "alg": "RSA1_5" 1647 }, 1648 "encrypted_key": "" 1649 } 1650 ], 1651 "iv": "", 1652 "ciphertext": "", 1654 "tag": "" 1655 } 1657 The full response message looks like the following: 1659 { 1660 "GetDeviceTEEStateTBSResponse": { 1661 "ver": "1.0", 1662 "status": "pass | fail", 1663 "rid": "", 1664 "tid": "", 1665 "signerreq": "true | false", 1666 "edsi": { 1667 "protected": "", 1669 "recipients": [ 1670 { 1671 "header": { 1672 "alg": "RSA1_5" 1673 }, 1674 "encrypted_key": "" 1675 } 1676 ], 1677 "iv": "", 1678 "ciphertext": "", 1680 "tag": "" 1681 } 1682 } 1683 } 1685 The CEK will be encrypted by the TSM public key in the device. The 1686 TEE signed message has the following structure. 1688 { 1689 "GetDeviceTEEStateResponse": { 1690 "payload": "", 1692 "protected": "", 1693 "signature": "" 1694 } 1695 } 1697 The signing algorithm shall use SHA256 with respective key type, see 1698 Section Section 7.5.1. 1700 The final response message GetDeviceStateResponse consists of array 1701 of TEE response. A typical device will have only one active TEE. An 1702 OTrP Agent is responsible to collect TEE response for all active TEEs 1703 in the future. 1705 { 1706 "GetDeviceStateResponse": [ // JSON array 1707 {"GetDeviceTEEStateResponse": ...}, 1708 ... 1709 {"GetDeviceTEEStateResponse": ...} 1710 ] 1711 } 1713 8.1.6. Error Conditions 1715 An error may occur if a request isn't valid or the TEE runs into some 1716 error. The list of possible error conditions is the following. 1718 ERR_REQUEST_INVALID The TEE meets the following conditions with a 1719 request message: (1) The request from a TSM has an invalid message 1720 structure; mandatory information is absent in the message. 1721 undefined member or structure is included. (2) TEE fails to verify 1722 signature of the message or fails to decrypt its contents. (3) etc. 1724 ERR_UNSUPPORTED_MSG_VERSION TEE receives the version of message that 1725 TEE can't deal with. 1727 ERR_UNSUPPORTED_CRYPTO_ALG TEE receives a request message encoded 1728 with cryptographic algorithms that TEE doesn't support. 1730 ERR_TFW_NOT_TRUSTED TEE may consider the underlying device firmware 1731 be not trustworthy. 1733 ERR_TSM_NOT_TRUSTED TEE needs to make sure whether the TSM is 1734 trustworthy by checking the validity of TSM certificate and OCSP 1735 stapling data and so on. If TEE finds TSM is not reliable, it may 1736 return this error code. 1738 ERR_TEE_FAIL TEE fails to respond to a TSM request. The OTrP Agent 1739 will construct an error message in responding the TSM's request. 1740 And also if TEE fails to process a request because of its internal 1741 error, it will return this error code. 1743 The response message will look like the following if the TEE signing 1744 can work to sign the error response message. 1746 { 1747 "GetDeviceTEEStateTBSResponse": { 1748 "ver": "1.0", 1749 "status": "fail", 1750 "rid": "", 1751 "tid": "", 1752 "reason": {"error-code":""} 1753 "supportedsigalgs": "" 1754 } 1755 } 1757 where 1759 supportedsigalgs - an optional property to list the JWS signing 1760 algorithms that the active TEE supports. When a TSM sends a 1761 signed message that the TEE isn't able to validate, it can 1762 include signature algorithms that it is able to consume in this 1763 status report. A TSM can generate a new request message to retry 1764 the management task with a TEE supported signing algorithm. 1766 If TEE isn't able to sign an error message, a general error message 1767 should be returned. 1769 8.1.7. TSM Processing Requirements 1771 Upon receiving a message of the type GetDeviceStateResponse at a TSM, 1772 the TSM should validate the following. 1774 o Parse to get list of GetDeviceTEEStateResponse JSON object 1776 o Parse the JSON "payload" property and decrypt the JSON element 1777 "edsi" 1779 o The decrypted message contains the TEE signer certificate 1781 o Validate GetDeviceTEEStateResponse JSON signature. The signer 1782 certificate is extracted from the decrypted message in the last 1783 step. 1785 o Extract TEE information and check it against its TEE acceptance 1786 policy. 1788 o Extract TFW signed element, and check the signer and data 1789 integration against its TFW policy 1791 o Check the SD list and TA list and prepare for a subsequent command 1792 such as "CreateSD" if it needs to have a new SD for a SP. 1794 8.2. Security Domain Management 1796 8.2.1. CreateSD 1798 This command is typically preceded with GetDeviceState command that 1799 has acquired the device information of the target device by the TSM. 1800 TSM sends such a command to instruct a TEE to create a new Security 1801 Domain for a SP. 1803 A TSM sends an OTrP Request message CreateSDRequest to a device TEE 1804 to create a Security Domain for a SP. Such a request is signed by 1805 TSM where the TSM signer may or may not be the same as the SP's TA 1806 signer certificate. The resulting SD is associated with two 1807 identifiers for future management: 1809 o TSM as the owner. The owner identifier is a registered unique TSM 1810 ID that is stored in the TSM certificate. 1812 o SP identified by its TA signer certificate as the authorization. 1813 A TSM can add more than one SP certificates to a SD. 1815 A Trusted Application that is signed by a matching SP signer 1816 certificate for a SD is eligible to be installed into that SD. The 1817 TA installation into a SD by a subsequent InstallTARequest message 1818 may be instructed from TSM or a Client Application. 1820 8.2.1.1. CreateSDRequest Message 1821 The request message for CreateSD has the following JSON format. 1823 { 1824 "CreateSDTBSRequest": { 1825 "ver": "1.0", 1826 "rid": "", 1827 "tid": "", // this may be from prior message 1828 "tee": "", 1829 "nextdsi": "true | false", 1830 "dsihash": "", 1831 "content": ENCRYPTED { // this piece of JSON data will be 1832 // encrypted 1833 "spid": "", 1834 "sdname": "", 1835 "spcert": "", 1836 "tsmid": "", 1838 "did": "" 1839 } 1840 } 1841 } 1843 In the message, 1845 rid - A unique value to identify this request 1847 tid - A unique value to identify this transaction. It can have the 1848 same value for the tid in the preceding GetDeviceStateRequest. 1850 tee - TEE ID returned from the previous response 1851 GetDeviceStateResponse 1853 nextdsi - Indicates whether the up to date Device State Information 1854 (DSI) should be returned in the response to this request. 1856 dsihash - The BASE64 encoded SHA256 hash value of the DSI data 1857 returned in the prior TSM operation with this target TEE. This 1858 value is always included such that a receiving TEE can check 1859 whether the device state has changed since its last query. It 1860 helps enforce SD update order in the right sequence without 1861 accidently overwrite an update that was done simultaneously. 1863 content - The "content" is a JSON encrypted message that includes 1864 actual input for the SD creation. The encryption key is TSMmk that 1865 is encrypted by the target TEE's public key. The entire message is 1866 signed by the TSM private key TSMpriv. A separate TSMmk isn't used 1867 in the latest specification because JSON encryption will use a 1868 content encryption key for exactly the same purpose. 1870 spid - A unique id assigned by the TSM for its SP. It should be 1871 unique within a TSM namespace. 1873 sdname - a name unique to the SP. TSM should ensure it is unique 1874 for each SP. 1876 spcert - The SP's TA signer certificate is included in the request. 1877 This certificate will be stored by the device TEE and uses it to 1878 check against TA installation. Only if a TA is signed by a 1879 matching spcert associated with a SD the TA will be installed into 1880 the SD. 1882 tsmid - SD owner claim by TSM - A SD owned by a TSM will be 1883 associated with a trusted identifier defined as an attribute in the 1884 signer TSM certificate. TEE will be responsible to assign this ID 1885 to the SD. The TSM certificate attribute for this attribute TSMID 1886 must be vetted by the TSM signer issuing CA. With this trusted 1887 identifier, SD query at TEE can be fast upon TSM signer 1888 verification. 1890 did - The SHA256 hash of the binary encoded device TEE certificate. 1891 The encryption key CEK will be encrypted the recipient TEE's public 1892 key. This hash value in the "did" property allows the recipient 1893 TEE to check whether it is the expected target to receive such a 1894 request. If this isn't given, an OTrP message for device 2 could 1895 be sent to device 1. It is optional for TEE to check because the 1896 successful decryption of the request message with this device's TEE 1897 private key already proves it is the target. This explicit hash 1898 value makes the protocol not dependent on message encryption method 1899 in future. 1901 Following is the OTrP message template, the full request is signed 1902 message over the CreateSDTBSRequest as follows. 1904 { 1905 "CreateSDRequest": { 1906 "payload":"", 1907 "protected":"", 1908 "header": , 1909 "signature":"" 1910 } 1911 } 1913 TSM signer certificate is included in the "header" property. 1915 8.2.1.2. Request processing requirements at a TEE 1917 Upon receiving a request message CreateSDRequest at a TEE, the TEE 1918 must validate a request: 1920 1. Validate the JSON request message 1922 * Validate JSON message signing 1924 * Validate that the request TSM certificate is chained to a 1925 trusted CA that the TEE embeds as its trust anchor 1927 * Compare dsihash with its current state to make sure nothing 1928 has changed since this request was sent. 1930 * Decrypt to get the plaintext of the content: (a) spid, (b) sd 1931 name, (c) did 1933 * Check that a SPID is supplied 1935 * spcert check: check it is a valid certificate (signature and 1936 format verification only) 1938 * Check "did" is the SHA256 hash of its TEEcert BER raw binary 1939 data 1941 * Check whether the requested SD already exists for the SP 1943 * Check TSMID in the request matches TSM certificate's TSM ID 1944 attribute 1946 2. Create action 1948 * Create a SD for the SP with the given name 1950 * Assign the TSMID from the TSMCert to this SD 1952 * Assign the SPID and SPCert to this SD 1954 * Check whether a TEE SP AIK keypair already exists for the 1955 given SP ID 1957 * Create TEE SP AIK keypair if it doesn't exist for the given SP 1958 ID 1960 * Generate new DSI data if the request asks for updated DSI 1962 3. Construct CreateSDResponse message 1963 * Create raw content 1965 + Operation status 1967 + "did" or full signer certificate information, 1969 + TEE SP AIK public key if DSI isn't going to be included 1971 + Updated DSI data if requested if the request asks for it 1973 * The response message is encrypted with the same JWE CEK of the 1974 request without recreating a new content encryption key. 1976 * The encrypted message is signed with TEEpriv. The signer 1977 information ("did" or TEEcert) is encrypted. 1979 4. Deliver response message. (a) OTrP Agent returns this to the app; 1980 (b) The app passes this back to TSM 1982 5. TSM process. (a) TSM processes the response message; (b) TSM can 1983 look up signer certificate from device ID "did". 1985 If a request is illegitimate or signature doesn't pass, a "status" 1986 property in the response will indicate the error code and cause. 1988 8.2.1.3. CreateSDResponse Message 1990 The response message for a CreateSDRequest contains the following 1991 content. 1993 { 1994 "CreateSDTBSResponse": { 1995 "ver": "1.0", 1996 "status": "", 1997 "rid": "", 1998 "tid": "", 1999 "content": ENCRYPTED { 2000 "reason":"", // optional 2001 "did": "", 2002 "sdname": "", 2003 "teespaik": "", 2004 "dsi": "" 2006 } 2007 } 2008 } 2010 In the response message, the following fields MUST be supplied. 2012 did - The SHA256 hash of the device TEE certificate. This shows 2013 the device ID explicitly to the receiving TSM. 2015 teespaik - The newly generated SP AIK public key for the given SP. 2016 This is an optional value if the device has had another domain for 2017 the SP that has triggered TEE SP AIK keypair for this specific SP. 2019 There is possible extreme error case where TEE isn't reachable or the 2020 TEE final response generation itself fails. In this case, TSM should 2021 still receive a response from the OTrP Agent. OTrP Agent is able to 2022 detect such error from TEE. In this case, a general error response 2023 message should be returned, assuming OTrP Agent even doesn't know any 2024 content and information about the request message. 2026 In other words, TSM should expect receive a TEE successfully signed 2027 JSON message, or a general "status" message. 2029 { 2030 "CreateSDResponse": { 2031 "payload":"", 2032 "protected": { 2033 "" 2034 }, 2035 "signature": "" 2037 } 2038 } 2040 A response message type "status" will be returned when TEE totally 2041 fails to respond. OTrP Agent is responsible to create this message. 2043 { 2044 "status": { 2045 "result": "fail", 2046 "error-code": "ERR_TEE_UNKNOWN", 2047 "error-message": "TEE fails to respond" 2048 } 2049 } 2051 8.2.1.4. Error Conditions 2053 An error may occur if a request isn't valid or the TEE runs into some 2054 error. The list of possible errors are the following. Refer to 2055 section Error Code List (Section 13.1) for detail causes and actions. 2057 ERR_REQUEST_INVALID 2058 ERR_UNSUPPORTED_MSG_VERSION 2060 ERR_UNSUPPORTED_CRYPTO_ALG 2062 ERR_DEV_STATE_MISMATCH 2064 ERR_SD_ALREADY_EXIST 2066 ERR_SD_NOT_FOUND 2068 ERR_SPCERT_INVALID 2070 ERR_TEE_FAIL 2072 ERR_TEE_UNKNOWN 2074 ERR_TSM_NOT_AUTHORIZED 2076 ERR_TSM_NOT_TRUSTED 2078 8.2.2. UpdateSD 2080 This TSM initiated command can update a SP's SD that it manages for 2081 the following need. (a) Update SP signer certificate; (b) Add SP 2082 signer certificate when a SP uses multiple to sign TA binary; (c) 2083 Update SP ID. 2085 The TSM presents the proof of the SD ownership to TEE, and includes 2086 related information in its signed message. The entire request is 2087 also encrypted for the end-to-end confidentiality. 2089 8.2.2.1. UpdateSDRequest Message 2090 The request message for UpdateSD has the following JSON format. 2092 { 2093 "UpdateSDTBSRequest": { 2094 "ver": "1.0", 2095 "rid": "", 2096 "tid": "", // this may be from prior message 2097 "tee": "", 2098 "nextdsi": "true | false", 2099 "dsihash": "", 2100 "content": ENCRYPTED { // this piece of JSON will be encrypted 2101 "tsmid": "", 2102 "spid": "", 2103 "sdname": "", 2104 "changes": { 2105 "newsdname": "", 2106 // Optional 2107 "newspid": "", 2108 // Optional 2109 "spcert": [""], 2110 // Optional 2111 "deloldspcert": [""], 2113 // Optional 2114 "renewteespaik": "true | false" 2115 } 2116 } 2117 } 2118 } 2120 In the message, 2122 rid - A unique value to identify this request 2124 tid - A unique value to identify this transaction. It can have the 2125 same value for the tid in the preceding GetDeviceStateRequest. 2127 tee - TEE ID returned from the previous response 2128 GetDeviceStateResponse 2130 nextdsi - Indicates whether the up to date Device State Information 2131 (DSI) should be returned in the response to this request. 2133 dsihash - The BASE64 encoded SHA256 hash value of the DSI data 2134 returned in the prior TSM operation with this target TEE. This 2135 value is always included such that a receiving TEE can check 2136 whether the device state has changed since its last query. It 2137 helps enforce SD update order in the right sequence without 2138 accidently overwrite an update that was done simultaneously. 2140 content - The "content" is a JSON encrypted message that includes 2141 actual input for the SD update. The standard JSON content 2142 encryption key (CEK) is used, and the CEK is encrypted by the 2143 target TEE's public key. 2145 tsmid - SD owner claim by TSM - A SD owned by a TSM will be 2146 associated with a trusted identifier defined as an attribute in the 2147 signer TSM certificate. 2149 spid - the identifier of the SP whose SD will be updated. This 2150 value is still needed because SD name is considered unique within a 2151 SP only. 2153 sdname - the name of the target SD to be updated. 2155 changes - its content consists of changes that should be updated in 2156 the given SD. 2158 newsdname - the new name of the target SD to be assigned if this 2159 value is present. 2161 newspid - the new SP ID of the target SD to be assigned if this 2162 value is present. 2164 spcert - a new TA signer certificate of this SP to be added to the 2165 SD if this is present. 2167 deloldspcert - a SP certificate assigned into the SD should be 2168 deleted if this is present. The value is the SHA256 fingerprint of 2169 the old SP certificate. 2171 renewteespaik - the value should be 'true' or 'false'. If it is 2172 present and the value is 'true', TEE should regenerate TEE SP AIK 2173 for this SD's owner SP. The newly generated TEE SP AIK for the SP 2174 must be returned in the response message of this request. If there 2175 are more than one SD for the SP, a new SPID for one of the domain 2176 will always trigger a new teespaik generation as if a new SP is 2177 introduced to the TEE. 2179 Following the OTrP message template, the full request is signed 2180 message over the UpdateSDTBSRequest as follows. 2182 { 2183 "UpdateSDRequest": { 2184 "payload":"", 2185 "protected":"", 2186 "header": , 2187 "signature":"" 2188 } 2189 } 2191 TSM signer certificate is included in the "header" property. 2193 8.2.2.2. Request processing requirements at a TEE 2195 Upon receiving a request message UpdateSDRequest at a TEE, the TEE 2196 must validate a request: 2198 1. Validate the JSON request message 2200 * Validate JSON message signing 2202 * Validate that the request TSM certificate is chained to a 2203 trusted CA that the TEE embeds as its trust anchor. TSM 2204 certificate status check is generally not needed anymore in 2205 this request. The prior request should have validated the TSM 2206 certificate's revocation status 2208 * Compare dsihash with TEE cached last response DSI data to this 2209 TSM 2211 * Decrypt to get the plaintext of the content 2213 * Check that the target SD name is supplied 2215 * Check whether the requested SD exists 2217 * Check that the TSM owns this TSM by verifying TSMID in the SD 2218 matches TSM certificate's TSM ID attribute 2220 * Now the TEE is ready to carry out update listed in the 2221 "content" message 2223 2. Update action 2225 * If "newsdname" is given, replace the SD name for the SD to the 2226 new value 2228 * If "newspid" is given, replace the SP ID assigned to this SD 2229 with the given new value 2231 * If "spcert" is given, add this new SP certificate to the SD. 2233 * If "deloldspcert" is present in the content, check previously 2234 assigned SP certificates to this SD, and delete the one that 2235 matches the given certificate hash value. 2237 * If "renewteespaik" is given and has a value as "true", 2238 generate a new TEE SP AIK keypair, and replace the old one 2239 with this. 2241 * Generate new DSI data if the request asks for updated DSI 2243 * Now the TEE is ready to construct the response message 2245 3. Construct UpdateSDResponse message 2247 * Create raw content 2249 + Operation status 2251 + "did" or full signer certificate information, 2253 + TEE SP AIK public key if DSI isn't going to be included 2255 + Updated DSI data if requested if the request asks for it 2257 * The response message is encrypted with the same JWE CEK of the 2258 request without recreating a new content encryption key. 2260 * The encrypted message is signed with TEEpriv. The signer 2261 information ("did" or TEEcert) is encrypted. 2263 4. Deliver response message. (a) OTrP Agent returns this to the app; 2264 (b) The app passes this back to TSM 2266 5. TSM process. (a) TSM processes the response message; (b) TSM can 2267 look up signer certificate from device ID "did". 2269 If a request is illegitimate or signature doesn't pass, a "status" 2270 property in the response will indicate the error code and cause. 2272 8.2.2.3. UpdateSDResponse Message 2274 The response message for a UpdateSDRequest contains the following 2275 content. 2277 { 2278 "UpdateSDTBSResponse": { 2279 "ver": "1.0", 2280 "status": "", 2281 "rid": "", 2282 "tid": "", 2283 "content": ENCRYPTED { 2284 "reason":"", // optional 2285 "did": "", 2286 "cert": "", // optional 2287 "teespaik": "", 2288 "teespaiktype": "", 2289 "dsi": "" 2291 } 2292 } 2293 } 2295 In the response message, the following fields MUST be supplied. 2297 did - The request should have known the signer certificate of this 2298 device from a prior request. This hash value of the device TEE 2299 certificate serves as a quick identifier only. Full device 2300 certificate isn't necessary. 2302 teespaik - the newly generated SP AIK public key for the given SP 2303 if TEE SP AIK for the SP is asked to be renewed in the request. 2304 This is an optional value if "dsi" is included in the response, 2305 which will contain all up to date TEE SP AIK key pairs. 2307 Similar to the template for the creation of the encrypted and signed 2308 CreateSDResponse, the final UpdateSDResponse looks like the 2309 following. 2311 { 2312 "UpdateSDResponse": { 2313 "payload":"", 2314 "protected": { 2315 "" 2316 }, 2317 "signature": "" 2319 } 2320 } 2322 A response message type "status" will be returned when TEE totally 2323 fails to respond. OTrP Agent is responsible to create this message. 2325 { 2326 "status": { 2327 "result": "fail", 2328 "error-code": "ERR_TEE_UNKNOWN", 2329 "error-message": "TEE fails to respond" 2330 } 2331 } 2333 8.2.2.4. Error Conditions 2335 An error may occur if a request isn't valid or the TEE runs into some 2336 error. The list of possible errors are the following. Refer to 2337 section Error Code List (Section 13.1) for detail causes and actions. 2339 ERR_REQUEST_INVALID 2341 ERR_UNSUPPORTED_MSG_VERSION 2343 ERR_UNSUPPORTED_CRYPTO_ALG 2345 ERR_DEV_STATE_MISMATCH 2347 ERR_SD_NOT_FOUND 2349 ERR_SDNAME_ALREADY_USED 2351 ERR_SPCERT_INVALID 2353 ERR_TEE_FAIL 2355 ERR_TEE_UNKNOWN 2357 ERR_TSM_NOT_AUTHORIZED 2358 ERR_TSM_NOT_TRUSTED 2360 8.2.3. DeleteSD 2362 A TSM sends a DeleteSDRequest message to TEE to delete a specified SD 2363 that it owns. A SD can be deleted only if there is no TA associated 2364 with this SD in the device. The request message can contain a flag 2365 to instruct TEE to delete all related TAs in a SD and then delete the 2366 SD. 2368 The target TEE will operate with the following logic. 2370 1. Lookup given SD specified in the request message 2372 2. Check that the TSM owns the SD 2374 3. Check that the device state hasn't changed since the last 2375 operation 2377 4. Check whether there are TAs in this SD 2379 5. If TA exists in a SD, check whether the request instructs whether 2380 TA should be deleted. If the request instructs TEE to delete 2381 TAs, delete all TAs in this SD. If the request doesn't instruct 2382 the TEE to delete TAs, return an error "ERR_SD_NOT_EMPTY". 2384 6. Delete SD 2386 7. If this is the last SD of this SP, delete TEE SP AIK key 2388 8.2.3.1. DeleteSDRequest Message 2389 The request message for DeleteSD has the following JSON format. 2391 { 2392 "DeleteSDTBSRequest": { 2393 "ver": "1.0", 2394 "rid": "", 2395 "tid": "", // this may be from prior message 2396 "tee": "", 2397 "nextdsi": "true | false", 2398 "dsihash": "", 2399 "content": ENCRYPTED { // this piece of JSON will be encrypted 2400 "tsmid": "", 2401 "sdname": "", 2402 "deleteta": "true | false" 2403 } 2404 } 2405 } 2407 In the message, 2409 rid - A unique value to identify this request 2411 tid - A unique value to identify this transaction. It can have the 2412 same value for the tid in the preceding GetDeviceStateRequest. 2414 tee - TEE ID returned from the previous response 2415 GetDeviceStateResponse 2417 nextdsi - Indicates whether the up to date Device State Information 2418 (DSI) should be returned in the response to this request. 2420 dsihash - The BASE64 encoded SHA256 hash value of the DSI data 2421 returned in the prior TSM operation with this target TEE. This 2422 value is always included such that a receiving TEE can check 2423 whether the device state has changed since its last query. It 2424 helps enforce SD update order in the right sequence without 2425 accidently overwrite an update that was done simultaneously. 2427 content - The "content" is a JSON encrypted message that includes 2428 actual input for the SD update. The standard JSON content 2429 encryption key (CEK) is used, and the CEK is encrypted by the 2430 target TEE's public key. 2432 tsmid - SD owner claim by TSM - A SD owned by a TSM will be 2433 associated with a trusted identifier defined as an attribute in the 2434 signer TSM certificate. 2436 sdname - the name of the target SD to be updated. 2438 deleteta - the value should be 'true' or 'false'. If it is present 2439 and the value is 'true', TEE should delete all TAs associated with 2440 the SD in the device. 2442 Following the OTrP message template, the full request is signed 2443 message over the DeleteSDTBSRequest as follows. 2445 { 2446 "DeleteSDRequest": { 2447 "payload":"", 2448 "protected":"", 2449 "header": , 2450 "signature":"" 2451 } 2452 } 2454 TSM signer certificate is included in the "header" property. 2456 8.2.3.2. Request processing requirements at a TEE 2458 Upon receiving a request message DeleteSDRequest at a TEE, the TEE 2459 must validate a request: 2461 1. Validate the JSON request message 2463 * Validate JSON message signing 2465 * Validate that the request TSM certificate is chained to a 2466 trusted CA that the TEE embeds as its trust anchor. TSM 2467 certificate status check is generally not needed anymore in 2468 this request. The prior request should have validated the TSM 2469 certificate's revocation status 2471 * Compare dsihash with TEE cached last response DSI data to this 2472 TSM 2474 * Decrypt to get the plaintext of the content 2476 * Check that the target SD name is supplied 2478 * Check whether the requested SD exists 2480 * Check that the TSM owns this TSM by verifying TSMID in the SD 2481 matches TSM certificate's TSM ID attribute 2483 * Now the TEE is ready to carry out update listed in the 2484 "content" message 2486 2. Deletion action 2488 * Check TA existence in this SD 2490 * If "deleteta" is "true", delete all TAs in this SD. If the 2491 value of "deleteta" is "false" and some TA exists, return an 2492 error "ERR_SD_NOT_EMPTY" 2494 * Delete the SD 2496 * Delete TEE SP AIK key pair if this SD is the last one for the 2497 SP 2499 * Now the TEE is ready to construct the response message 2501 3. Construct DeleteSDResponse message 2503 * Create response content 2505 + Operation status 2507 + "did" or full signer certificate information, 2509 + Updated DSI data if requested if the request asks for it 2511 * The response message is encrypted with the same JWE CEK of the 2512 request without recreating a new content encryption key. 2514 * The encrypted message is signed with TEEpriv. The signer 2515 information ("did" or TEEcert) is encrypted. 2517 4. Deliver response message. (a) OTrP Agent returns this to the app; 2518 (b) The app passes this back to TSM 2520 5. TSM process. (a) TSM processes the response message; (b) TSM can 2521 look up signer certificate from device ID "did". 2523 If a request is illegitimate or signature doesn't pass, a "status" 2524 property in the response will indicate the error code and cause. 2526 8.2.3.3. DeleteSDResponse Message 2528 The response message for a DeleteSDRequest contains the following 2529 content. 2531 { 2532 "DeleteSDTBSResponse": { 2533 "ver": "1.0", 2534 "status": "", 2535 "rid": "", 2536 "tid": "", 2537 "content": ENCRYPTED { 2538 "reason":"", // optional 2539 "did": "", 2540 "dsi": "" 2542 } 2543 } 2544 } 2546 In the response message, the following fields MUST be supplied. 2548 did - The request should have known the signer certificate of this 2549 device from a prior request. This hash value of the device TEE 2550 certificate serves as a quick identifier only. Full device 2551 certificate isn't necessary. 2553 The final DeleteSDResponse looks like the following. 2555 { 2556 "DeleteSDResponse": { 2557 "payload":"", 2558 "protected": { 2559 "" 2560 }, 2561 "signature": "" 2563 } 2564 } 2566 A response message type "status" will be returned when TEE totally 2567 fails to respond. OTrP Agent is responsible to create this message. 2569 { 2570 "status": { 2571 "result": "fail", 2572 "error-code": "ERR_TEE_UNKNOWN", 2573 "error-message": "TEE fails to respond" 2574 } 2575 } 2577 8.2.3.4. Error Conditions 2579 An error may occur if a request isn't valid or the TEE runs into some 2580 error. The list of possible errors are the following. Refer to 2581 section Error Code List (Section 13.1) for detail causes and actions. 2583 ERR_REQUEST_INVALID 2585 ERR_UNSUPPORTED_MSG_VERSION 2587 ERR_UNSUPPORTED_CRYPTO_ALG 2589 ERR_DEV_STATE_MISMATCH 2591 ERR_SD_NOT_EMPTY 2593 ERR_SD_NOT_FOUND 2595 ERR_TEE_FAIL 2597 ERR_TEE_UNKNOWN 2599 ERR_TSM_NOT_AUTHORIZED 2601 ERR_TSM_NOT_TRUSTED 2603 8.3. Trusted Application Management 2605 This protocol doesn't introduce a TA container concept. All the TA 2606 authorization and management will be up to TEE implementation. 2608 The following three TA management commands will be supported. 2610 o InstallTA - provision a TA by TSM 2612 o UpdateTA - update a TA by TSM 2614 o DeleteTA - remove TA registration information with a SD, remove TA 2615 binary from TEE, remove all TA related data in TEE 2617 8.3.1. InstallTA 2619 TA binary data can be from two sources: 2621 1. TSM supplies the signed TA binary 2623 2. Client Application supplies the TA binary 2624 This specification considers only the first case where TSM supplies 2625 TA binary. When such a request is received by TEE, a SD is already 2626 created and is ready to take TA installation. 2628 A TSM sends the following information in message InstallTARequest to 2629 a target TEE: 2631 o The target SD information: SP ID and SD name 2633 o Encrypted TA binary data. TA data is encrypted with TEE SP AIK. 2635 o TA metadata. It is optional to include SP signer certificate for 2636 the SD to add if the SP has changed signer since the SD was 2637 created. 2639 TEE processes command given by TSM to install TA into a SP's SD. It 2640 does the following: 2642 o Validation 2644 * TEE validates TSM message authenticity 2646 * Decrypt to get request content 2648 * Lookup SD with SD name 2650 * Checks that the TSM owns the SD 2652 * Checks DSI hash matches that the device state hasn't changed 2654 o TA validation 2656 * Decrypt to get TA binary and any personalization data with "TEE 2657 SP AIK private key" 2659 * Check that SP ID is the one that is registered with the SP SD 2661 * TA signer is either the newly given SP certificate or the one 2662 in SD. The TA signing method is specific to TEE. This 2663 specification doesn't define how a TA should be signed. 2665 * If a TA signer is given in the request, add this signer into 2666 the SD. 2668 o TA installation 2670 * TEE re-encrypts TA binary and its personalization data with its 2671 own method 2673 * TEE enrolls and stores the TA onto TEE secure storage area. 2675 o Construct a response message. This involves signing a encrypted 2676 status information for the requesting TSM. 2678 8.3.1.1. InstallTARequest Message 2680 The request message for InstallTA has the following JSON format. 2682 { 2683 "InstallTATBSRequest": { 2684 "ver": "1.0", 2685 "rid": "", 2686 "tid": "", 2687 "tee": "", 2688 "nextdsi": "true | false", 2689 "dsihash": "", 2690 "content": ENCRYPTED { 2691 "tsmid": "", 2692 "spid": "", 2693 "sdname": "", 2694 "spcert": "", // optional 2695 "taid": "" 2696 }, 2697 "encrypted_ta": { 2698 "key": "", 2700 "iv": "", 2701 "alg": "", 2703 "cipherpdata": "" 2705 } 2706 } 2707 } 2709 In the message, 2711 rid - A unique value to identify this request 2713 tid - A unique value to identify this transaction. It can have the 2714 same value for the tid in the preceding GetDeviceStateRequest. 2716 tee - TEE ID returned from the previous response 2717 GetDeviceStateResponse 2719 nextdsi - Indicates whether the up to date Device State Information 2720 (DSI) should be returned in the response to this request. 2722 dsihash - The BASE64 encoded SHA256 hash value of the DSI data 2723 returned in the prior TSM operation with this target TEE. This 2724 value is always included such that a receiving TEE can check 2725 whether the device state has changed since its last query. It 2726 helps enforce SD update order in the right sequence without 2727 accidently overwrite an update that was done simultaneously. 2729 content - The "content" is a JSON encrypted message that includes 2730 actual input for the SD update. The standard JSON content 2731 encryption key (CEK) is used, and the CEK is encrypted by the 2732 target TEE's public key. 2734 tsmid - SD owner claim by TSM - A SD owned by a TSM will be 2735 associated with a trusted identifier defined as an attribute in the 2736 signer TSM certificate. 2738 spid - SP identifier of the TA owner SP 2740 spcert - an optional field to specify SP certificate that signed the 2741 TA. This is sent if the SP has a new certificate that hasn't been 2742 previously registered with the target SD where the TA should be 2743 installed. 2745 sdname - the name of the target SD where the TA should be installed 2747 encrypted_ta - the message portion contains encrypted TA binary data 2748 and personalization data. The TA data encryption key is placed in 2749 "key", which is encrypted by the recipient's public key. The TA 2750 data encryption uses symmetric key based encryption such as AESCBC. 2752 Following the OTrP message template, the full request is signed 2753 message over the InstallTATBSRequest as follows. 2755 { 2756 "InstallTARequest": { 2757 "payload":"", 2758 "protected":"", 2759 "header": , 2760 "signature":"" 2761 } 2762 } 2764 8.3.1.2. InstallTAResponse Message 2766 The response message for a InstallTARequest contains the following 2767 content. 2769 { 2770 "InstallTATBSResponse": { 2771 "ver": "1.0", 2772 "status": "", 2773 "rid": "", 2774 "tid": "", 2775 "content": ENCRYPTED { 2776 "reason":"", // optional 2777 "did": "", 2778 "dsi": "" 2780 } 2781 } 2782 } 2784 In the response message, the following fields MUST be supplied. 2786 did - the SHA256 hash of the device TEE certificate. This shows 2787 the device ID explicitly to the receiving TSM. 2789 The final message InstallTAResponse looks like the following. 2791 { 2792 "InstallTAResponse": { 2793 "payload":"", 2794 "protected": { 2795 "" 2796 }, 2797 "signature": "" 2799 } 2800 } 2802 A response message type "status" will be returned when TEE totally 2803 fails to respond. OTrP Agent is responsible to create this message. 2805 { 2806 "status": { 2807 "result": "fail", 2808 "error-code": "ERR_TEE_UNKNOWN", 2809 "error-message": "TEE fails to respond" 2810 } 2811 } 2813 8.3.1.3. Error Conditions 2815 An error may occur if a request isn't valid or the TEE runs into some 2816 error. The list of possible errors are the following. Refer to 2817 section Error Code List (Section 13.1) for detail causes and actions. 2819 ERR_REQUEST_INVALID 2821 ERR_UNSUPPORTED_MSG_VERSION 2823 ERR_UNSUPPORTED_CRYPTO_ALG 2825 ERR_DEV_STATE_MISMATCH 2827 ERR_SD_NOT_FOUND 2829 ERR_TA_INVALID 2831 ERR_TA_ALREADY_INSTALLED 2833 ERR_TEE_FAIL 2835 ERR_TEE_UNKNOWN 2837 ERR_TEE_RESOURCE_FULL 2839 ERR_TSM_NOT_AUTHORIZED 2841 ERR_TSM_NOT_TRUSTED 2843 8.3.2. UpdateTA 2845 This TSM initiated command can update TA and its data in a SP's SD 2846 that it manages for the following purposes. 2848 1. Update TA binary 2850 2. Update TA's personalization data 2852 The TSM presents the proof of the SD ownership to TEE, and includes 2853 related information in its signed message. The entire request is 2854 also encrypted for the end-to-end confidentiality. 2856 TEE processes command given by TSM to update TA of a SP SD. It does 2857 the following: 2859 o Validation 2860 * TEE validates TSM message authenticity 2862 * Decrypt to get request content 2864 * Lookup SD with SD name 2866 * Checks that the TSM 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 TA binary and any personalization data with "TEE 2876 SP AIK private key" 2878 * Check that SP ID is the one that is registered with the SP SD 2880 * TA signer is either the newly given SP certificate or the one 2881 in SD. The TA signing method is specific to TEE. This 2882 specification doesn't define how a TA should be signed. 2884 * If a TA signer is given in the request, add this signer into 2885 the SD 2887 o TA update 2889 * TEE re-encrypts TA binary and its personalization data with its 2890 own method 2892 * TEE replaces the existing TA binary and its personalization 2893 data with the new binary and data. 2895 o Construct a response message. This involves signing a encrypted 2896 status information for the requesting TSM. 2898 8.3.2.1. UpdateTARequest Message 2899 The request message for UpdateTA has the following JSON format. 2901 { 2902 "UpdateTATBSRequest": { 2903 "ver": "1.0", 2904 "rid": "", 2905 "tid": "", 2906 "tee": "", 2907 "nextdsi": "true | false", 2908 "dsihash": "", 2909 "content": ENCRYPTED { 2910 "tsmid": "", 2911 "spid": "", 2912 "sdname": "", 2913 "spcert": "", // optional 2914 "taid": "" 2915 }, 2916 "encrypted_ta": { 2917 "key": "", 2919 "iv": "", 2920 "alg": "", 2923 "ciphernewpdata": "" 2925 // optional 2926 } 2927 } 2928 } 2930 In the message, 2932 rid - A unique value to identify this request 2934 tid - A unique value to identify this transaction. It can have the 2935 same value for the tid in the preceding GetDeviceStateRequest. 2937 tee - TEE ID returned from the previous response 2938 GetDeviceStateResponse 2940 nextdsi - Indicates whether the up to date Device State Information 2941 (DSI) should be returned in the response to this request. 2943 dsihash - The BASE64 encoded SHA256 hash value of the DSI data 2944 returned in the prior TSM operation with this target TEE. This 2945 value is always included such that a receiving TEE can check 2946 whether the device state has changed since its last query. It 2947 helps enforce SD update order in the right sequence without 2948 accidently overwrite an update that was done simultaneously. 2950 content - The "content" is a JSON encrypted message that includes 2951 actual input for the SD update. The standard JSON content 2952 encryption key (CEK) is used, and the CEK is encrypted by the 2953 target TEE's public key. 2955 tsmid - SD owner claim by TSM - A SD owned by a TSM will be 2956 associated with a trusted identifier defined as an attribute in the 2957 signer TSM certificate. 2959 spid - SP identifier of the TA owner SP 2961 spcert - an optional field to specify SP certificate that signed the 2962 TA. This is sent if the SP has a new certificate that hasn't been 2963 previously registered with the target SD where the TA should be 2964 installed. 2966 sdname - the name of the target SD where the TA should be updated 2968 taid - an identifier for the TA application to be updated 2970 encrypted_ta - the message portion contains new encrypted TA binary 2971 data and personalization data. 2973 Following the OTrP message template, the full request is signed 2974 message over the UpdateTATBSRequest as follows. 2976 { 2977 "UpdateTARequest": { 2978 "payload":"", 2979 "protected":"", 2980 "header": , 2981 "signature":"" 2982 } 2983 } 2985 8.3.2.2. UpdateTAResponse Message 2987 The response message for a UpdateTARequest contains the following 2988 content. 2990 { 2991 "UpdateTATBSResponse": { 2992 "ver": "1.0", 2993 "status": "", 2994 "rid": "", 2995 "tid": "", 2996 "content": ENCRYPTED { 2997 "reason":"", // optional 2998 "did": "", 2999 "dsi": "" 3001 } 3002 } 3003 } 3005 In the response message, the following fields MUST be supplied. 3007 did - the SHA256 hash of the device TEE certificate. This shows 3008 the device ID explicitly to the receiving TSM. 3010 The final message UpdateTAResponse looks like the following. 3012 { 3013 "UpdateTAResponse": { 3014 "payload":"", 3015 "protected": { 3016 "" 3017 }, 3018 "signature": "" 3020 } 3021 } 3023 A response message type "status" will be returned when TEE totally 3024 fails to respond. OTrP Agent is responsible to create this message. 3026 { 3027 "status": { 3028 "result": "fail", 3029 "error-code": "ERR_TEE_UNKNOWN", 3030 "error-message": "TEE fails to respond" 3031 } 3032 } 3034 8.3.2.3. Error Conditions 3036 An error may occur if a request isn't valid or the TEE runs into some 3037 error. The list of possible errors are the following. Refer to 3038 section Error Code List (Section 13.1) for detail causes and actions. 3040 ERR_REQUEST_INVALID 3042 ERR_UNSUPPORTED_MSG_VERSION 3044 ERR_UNSUPPORTED_CRYPTO_ALG 3046 ERR_DEV_STATE_MISMATCH 3048 ERR_SD_NOT_FOUND 3050 ERR_TA_INVALID 3052 ERR_TA_NOT_FOUND 3054 ERR_TEE_FAIL 3056 ERR_TEE_UNKNOWN 3058 ERR_TSM_NOT_AUTHORIZED 3060 ERR_TSM_NOT_TRUSTED 3062 8.3.3. DeleteTA 3064 This operation defines OTrP messages that allow a TSM instruct a TEE 3065 to delete a TA for a SP in a given SD. A TEE will delete a TA from a 3066 SD and also TA data in the TEE. A Client Application cannot directly 3067 access TEE or OTrP Agent to delete a TA. 3069 8.3.3.1. DeleteTARequest Message 3070 The request message for DeleteTA has the following JSON format. 3072 { 3073 "DeleteTATBSRequest": { 3074 "ver": "1.0", 3075 "rid": "", 3076 "tid": "", 3077 "tee": "", 3078 "nextdsi": "true | false", 3079 "dsihash": "", 3080 "content": ENCRYPTED { 3081 "tsmid": "", 3082 "sdname": "", 3083 "taid": "" 3085 } 3086 } 3087 } 3089 In the message, 3091 rid - A unique value to identify this request 3093 tid - A unique value to identify this transaction. It can have the 3094 same value for the tid in the preceding GetDeviceStateRequest. 3096 tee - TEE ID returned from the previous response 3097 GetDeviceStateResponse 3099 nextdsi - Indicates whether the up to date Device State Information 3100 (DSI) should be returned in the response to this request. 3102 dsihash - The BASE64 encoded SHA256 hash value of the DSI data 3103 returned in the prior TSM operation with this target TEE. This 3104 value is always included such that a receiving TEE can check 3105 whether the device state has changed since its last query. It 3106 helps enforce SD update order in the right sequence without 3107 accidently overwrite an update that was done simultaneously. 3109 content - The "content" is a JSON encrypted message that includes 3110 actual input for the SD update. The standard JSON content 3111 encryption key (CEK) is used, and the CEK is encrypted by the 3112 target TEE's public key. 3114 tsmid - SD owner claim by TSM - A SD owned by a TSM will be 3115 associated with a trusted identifier defined as an attribute in the 3116 signer TSM certificate. 3118 sdname - the name of the target SD where the TA is installed 3120 taid - an identifier for the TA application to be deleted 3122 Following the OTrP message template, the full request is signed 3123 message over the DeleteTATBSRequest as follows. 3125 { 3126 "DeleteTARequest": { 3127 "payload":"", 3128 "protected":"", 3129 "header": , 3130 "signature":"" 3132 } 3133 } 3135 8.3.3.2. Request processing requirements at a TEE 3137 TEE processes command given by TSM to delete a TA of a SP SD. It 3138 does the following: 3140 1. Validate the JSON request message 3142 * TEE validates TSM message authenticity 3144 * Decrypt to get request content 3146 * Lookup the SD and the TA with the given SD name and TA ID 3148 * Checks that the TSM owns the SD, and TA is installed in the SD 3150 * Checks DSI hash matches that the device state hasn't changed 3152 2. Deletion action 3154 * If all the above validation points pass, the TEE deletes the 3155 TA from the SD 3157 * The TEE may also delete all personalization data for the TA 3159 3. Construct DeleteTAResponse message. 3161 If a request is illegitimate or signature doesn't pass, a "status" 3162 property in the response will indicate the error code and cause. 3164 8.3.3.3. DeleteTAResponse Message 3166 The response message for a DeleteTARequest contains the following 3167 content. 3169 { 3170 "DeleteTATBSResponse": { 3171 "ver": "1.0", 3172 "status": "", 3173 "rid": "", 3174 "tid": "", 3175 "content": ENCRYPTED { 3176 "reason":"", // optional 3177 "did": "", 3178 "dsi": "" 3180 } 3181 } 3182 } 3184 In the response message, the following fields MUST be supplied. 3186 did - the SHA256 hash of the device TEE certificate. This shows 3187 the device ID explicitly to the receiving TSM. 3189 The final message DeleteTAResponse looks like the following. 3191 { 3192 "DeleteTAResponse": { 3193 "payload":"", 3194 "protected": { 3195 "" 3196 }, 3197 "signature": "" 3199 } 3200 } 3202 A response message type "status" will be returned when TEE totally 3203 fails to respond. OTrP Agent is responsible to create this message. 3205 { 3206 "status": { 3207 "result": "fail", 3208 "error-code": "ERR_TEE_UNKNOWN", 3209 "error-message": "TEE fails to respond" 3210 } 3211 } 3213 8.3.3.4. Error Conditions 3215 An error may occur if a request isn't valid or the TEE runs into some 3216 error. The list of possible errors are the following. Refer to 3217 section Error Code List (Section 13.1) for detail causes and actions. 3219 ERR_REQUEST_INVALID 3221 ERR_UNSUPPORTED_MSG_VERSION 3223 ERR_UNSUPPORTED_CRYPTO_ALG 3225 ERR_DEV_STATE_MISMATCH 3227 ERR_SD_NOT_FOUND 3229 ERR_TA_NOT_FOUND 3231 ERR_TEE_FAIL 3233 ERR_TEE_UNKNOWN 3235 ERR_TSM_NOT_AUTHORIZED 3237 ERR_TSM_NOT_TRUSTED 3239 9. Response Messages a TSM May Expect 3241 A TSM expects some feedback from a remote device when a request 3242 message is delivered to a device. The following three types of 3243 responses SHOULD be supplied. 3245 Type 1: Expect a valid TEE generated response message 3247 A valid TEE signed response may contain errors detected by TEE, 3248 e.g. TSM is trusted but TSM supplied data is missing, for 3249 example, SP ID doesn't exist. TEE MUST be able to sign and 3250 encrypt. 3252 If TEE isn't able to sign a response, TEE should returns an error 3253 to OTrP Agent without giving any other internal information. 3254 OTrP Agent will be generating the response. 3256 Type 2: OTrP Agent generated error message when TEE fails. OTrP 3257 Agent errors will be defined in this document. 3259 A Type 2 message has the following format. 3261 { 3262 "OTrPAgentError": { 3263 "ver": "1.0", 3264 "rid": "", 3265 "tid": "", 3266 "errcode": "ERR_TEE_FAIL | ERR_TEE_BUSY" 3267 } 3268 } 3270 Type 3: OTrP Agent itself isn't reachable or fails. A Client 3271 Application is responsible to handle error and response TSM in 3272 its own way. This is out of scope for this specification. 3274 10. Attestation Implementation Consideration 3276 It is important to know that the state of a device is appropriate 3277 before trusting that a device is what it says it is. The attestation 3278 scheme for OTrP must also be able to cope with different TEEs, those 3279 that are OTrP compliant and those that use another mechanism. In the 3280 initial version, only one active TEE is assumed. 3282 It is out of scope about how TSM and device implement the trust 3283 hierarchy verification. However, it is helpful to understand what 3284 each system provider should do in order to properly implement OTrP 3285 trust hierarchy. 3287 In this section, we provide some implementation reference 3288 consideration. 3290 10.1. OTrP Secure Boot Module 3292 10.1.1. Attestation signer 3294 It is proposed that attestation for OTrP is based on the SBM secure 3295 boot layer, and that further attestation is not performed within the 3296 TEE itself during security domain operations. The rationale is that 3297 the device boot process will be defined to start with a secure boot 3298 approach that, using eFuse, only releases attestation signing 3299 capabilities into the SBM once a secure boot has been established. 3301 In this way the release of the attestation signer can be considered 3302 the first "platform configuration metric", using TCG terminology. 3304 10.1.2. SBM initial requirements 3306 R1 SBM must be possible to load securely into the secure boot flow 3308 R2 SBM must allow a public / private key pair to be generated during 3309 device manufacture 3311 R3 The public key and certificate must be possible to store securely 3312 from tamper 3314 R4 The private key must be possible to store encrypted at rest 3316 R5 The private key must only be visible to the SBM when it is 3317 decrypted 3319 R6 The SBM must be able to read a list of root and intermediate 3320 certificates that it can use to check certificate chains with. 3321 The list must be stored such that it cannot be tampered with 3323 R7 Possible need to allow a TEE to access its unique TEE specific 3324 private key 3326 10.2. TEE Loading 3328 During boot SBM is required to start all of the ROOT TEEs. Before 3329 loading them the SBM must first determine whether the code sign 3330 signature of the TEE is valid. If TEE integrity is confirmed it may 3331 be started. The SBM must then be able to receive the identity 3332 certificate from the TEE (if that TEE is OTrP compliant). The 3333 identity certificate and keys will need to be baked into the TEE 3334 image, and therefore also covered by the code signer hash during the 3335 manufacture process. The private key for the identity certificate 3336 must be securely protected. The private key for a TEE identity must 3337 never be released no matter how the public key and certificate are 3338 released to the SBM. 3340 Once the SBM has successfully booted a TEE and retrieved the identity 3341 certificate it will commit this to the platform configuration 3342 register (PCR) set, for later use during attestation. As a minimum 3343 the following data must be committed to the PCR for each TEE: 3345 1. Public key and certificate for the TEE 3347 2. TEE reference that can be used later by a TSM to identify this 3348 TEE 3350 10.3. Attestation Hierarchy 3352 The attestation hierarchy and seed required for TSM protocol 3353 operation must be built into the device at manufacture. Additional 3354 TEEs can be added post manufacture using the scheme proposed however 3355 it is outside of the current scope of this document to detail that. 3357 It should be noted that the attestation scheme described is based on 3358 signatures. The only encryption that takes place is with eFuse to 3359 release the SBM signing key and later during protocol lifecycle 3360 management interchange with the TSM. 3362 10.3.1. Attestation hierarchy establishment: manufacture 3364 During manufacture the following steps are required: 3366 1. Device specific TFW key pair and certificate burnt into device, 3367 encrypted by eFuse. This key pair will be used for signing 3368 operations performed by SBM. 3370 2. TEE images are loaded and include a TEE instance specific key 3371 pair and certificate. The key pair and certificate are included 3372 in the image and covered by the code signing hash. 3374 3. The process for TEE images is repeated for any subordinate TEEs 3376 10.3.2. Attestation hierarchy establishment: device boot 3378 During device boot the following steps are required: 3380 1. Secure boot releases TFW private key by decrypting with eFuse 3382 2. SBM verifies the code-signing signature of the active TEE and 3383 places its TEE public key into a signing buffer, along with their 3384 reference for later access. For non-OTrP TEE, the SBM leaves the 3385 TEE public key field blank. 3387 3. SBM signs the signing buffer with TFW private key 3389 4. Each active TEE performs the same operation as SBM, building up 3390 their own signed buffer containing subordinate TEE information. 3392 10.3.3. Attestation hierarchy establishment: TSM 3394 Before a TSM can begin operation in the marketplace it must obtain a 3395 TSM key pair and certificate (TSMpub, TSMpriv) from a CA that is 3396 registered in the trust store of the TEE. In this way, the TEE can 3397 check the intermediate and root CA and verify that it trusts this TSM 3398 to perform operations on the TEE. 3400 11. Acknowledgements 3402 We thank Alin Mutu for his contribution to many discussion that 3403 helped to design the trust flow mechanisms, and the creation of the 3404 flow diagrams. Alin has contributed the context diagram and brought 3405 good point in trust establishment. 3407 We also thank the following people for their input, review, and 3408 discussions that have greatly helped to shape the document: Sangsu 3409 Baek, Marc Canel, Roger Casals, Rob Coombs, Lubna Dajani, and Richard 3410 Parris. 3412 12. Contributors 3414 Brian Witten 3415 Symantec 3416 900 Corporate Pointe 3417 Culver City, CA 90230 3418 USA 3420 Email: brian_witten@symantec.com 3422 Tyler Kim 3423 Solacia 3424 5F, Daerung Post Tower 2, 306 Digital-ro 3425 Seoul 152-790 3426 Korea 3428 Email: tkkim@sola-cia.com 3430 13. IANA Considerations 3432 The error code listed in the next section will be registered. 3434 13.1. Error Code List 3436 This section lists error codes that could be reported by a TA or TEE 3437 in a device in responding a TSM request. 3439 ERR_DEV_STATE_MISMATCH - TEE will return this error code if DSI hash 3440 value from TSM doesn't match with that of device's current DSI. 3442 ERR_SD_ALREADY_EXIST - This error will occur if SD to be created 3443 already exist in the TEE. 3445 ERR_SD_NOT_EMPTY - This is reported if a target SD isn't empty. 3447 ERR_SDNAME_ALREADY_USED TEE will return this error code if new SD 3448 name already exists in the namespace of TSM in the TEE. 3450 ERR_REQUEST_INVALID - This error will occur if the TEE meets the 3451 following conditions with a request message: (1) The request from a 3452 TSM has an invalid message structure; mandatory information is 3453 absent in the message. undefined member or structure is included. 3454 (2) TEE fails to verify signature of the message or fails to 3455 decrypt its contents. (3) etc. 3457 ERR_SPCERT_INVALID - If new SP certificate for the SD to be updated 3458 is not valid, then TEE will return this error code. 3460 ERR_TA_ALREADY_INSTALLED - while installing TA, TEE will return this 3461 error if the TA already has been installed in the SD. 3463 ERR_TA_INVALID - This error will occur when TEE meets any of 3464 following conditions while checking validity of TA: (1) TA binary 3465 has a format that TEE can't recognize. (2) TEE fails to decrypt the 3466 encoding of TA binary and personalization data. (3) If SP isn't 3467 registered with the SP SD where TA will be installed. (4) etc. 3469 ERR_TA_NOT_FOUND - This error will occurs when target TA doesn't 3470 exist in the SD. 3472 ERR_TEE_BUSY - The device TEE is busy. The request should be 3473 generally sent later to retry. 3475 ERR_TEE_FAIL - TEE fails to respond to a TSM request. The OTrP 3476 Agent will construct an error message in responding the TSM's 3477 request. And also if TEE fails to process a request because of its 3478 internal error, it will return this error code. 3480 ERR_TEE_RESOURCE_FULL - This error is reported when a device 3481 resource isn't available anymore such as storage space is full. 3483 ERR_TEE_UNKNOWN - This error will occur if the receiver TEE is not 3484 supposed to receive the request. That will be determined by 3485 checking TEE name or device id in the request message. 3487 ERR_TFW_NOT_TRUSTED - TEE may concern the underlying device firmware 3488 is trustworthy. If TEE determines TFW is not trustworthy, then 3489 this error will occur. 3491 ERR_TSM_NOT_TRUSTED - Before processing a request, TEE needs to make 3492 sure whether the sender TSM is trustworthy by checking the validity 3493 of TSM certificate etc. If TEE finds TSM is not reliable, then it 3494 will return this error code. 3496 ERR_UNSUPPORTED_CRYPTO_ALG - This error will occur if TEE receives a 3497 request message encoded with cryptographic algorithms that TEE 3498 doesn't support. 3500 ERR_UNSUPPORTED_MSG_VERSION - This error will occur if TEE receives 3501 the version of message that TEE can't deal with. 3503 14. Security Consideration 3505 14.1. Cryptographic Strength 3507 The strength of the cryptographic algorithms, using the measure of 3508 'bits of security' defined in NIST SP800-57 allowed for the OTrP 3509 protocol is: 3511 o At a minimum, 112 bits of security. The limiting factor for this 3512 is the RSA-2048 algorithm, which is indicated as providing 112 3513 bits of symmetric key strength in SP800-57. It is important that 3514 RSA is supported in order to enhance the interoperability of the 3515 protocol. 3517 o The option exists to choose algorithms providing 128 bits of 3518 security. This requires using TEE devices that support ECC P256. 3520 The available algorithms and key sizes specified in this document are 3521 based on industry standards. Over time the recommended or allowed 3522 cryptographic algorithms may change. It is important that the OTrP 3523 protocol allows for crypto-agility. 3525 14.2. Message Security 3527 OTrP messages between the TSM and TEE are protected by message 3528 security using JWS and JWE. The 'Basic protocol profile' section of 3529 this document describes the algorithms used for this. All OTrP TEE 3530 devices and OTrP TSMs must meet the requirements of the basic 3531 profile. In the future additional 'profiles' can be added. 3533 PKI is used to ensure that the TEE will only communicate with a 3534 trusted TSM, and to ensure that the TSM will only communicate with a 3535 trusted TEE. 3537 14.3. TEE Attestation 3539 It is important that the TSM can trust that it is talking to a 3540 trusted TEE. This is achieved through attestation. The TEE has a 3541 private key and certificate built into it at manufacture, which is 3542 used to sign data supplied by the TSM. This allows the TSM to verify 3543 that the TEE is trusted. 3545 It is also important that the TFW (trusted firmware) can be checked. 3546 The TFW has a private key and certificate built into it at 3547 manufacturer, which allows the TEE to check that that the TFW is 3548 trusted. 3550 The GetDeviceState message therefore allows the TSM to check that it 3551 trusts the TEE, and the TEE at this point will check whether it 3552 trusts the TFW. 3554 14.4. TA Protection 3556 TA will be delivered in an encrypted form. This encryption is an 3557 additional layer within the message encryption described in the 3558 'Basic protocol profile' section of this document. The TA binary is 3559 encrypted for each target device with the device's TEE SP AIK public 3560 key. A TSM may do this encryption or provides the TEE SP AIK public 3561 key to a SP such that the SP encrypts the encrypted TA to TSM for 3562 distribution to TEE. 3564 The encryption algorithm can use a randomly AES 256 key "taek" with a 3565 16 byte random IV, and the "taek" is encrypted by the "TEE SP AIK 3566 public key". The following encrypted TA data structure is expected 3567 by TEE: 3569 "encrypted_ta_bin": { 3570 "key": "", 3572 "iv": ", 3573 "alg": "AESCBC", 3574 "cipherdata": "" 3575 } 3577 14.5. TA Personalization Data 3579 A SP or TSM can supply personalization data for a TA to initialize 3580 for a device. Such data is passed through InstallTA command from 3581 TSM. The personalization data itself is (or can be) opaque to the 3582 TSM. The data can be from the SP without being revealed to the TSM. 3583 The data is sent in encrypted manner in a request to a device such 3584 that only the device can decrypt. A device's TEE SP AIK public key 3585 for a SP is used to encrypt the data. 3587 "encrypted_ta_data": { // "TA personalization data" 3588 "key": "", 3590 "iv": "", 3591 "alg": "AESCBC", 3592 "cipherdata": "" 3594 } 3596 14.6. TA trust check at TEE 3598 A TA binary is signed by a TA signer certificate. This TA signing 3599 certificate/private key belongs to the SP, and may be self-signed 3600 (i.e. it need not participate in a trust hierarchy). It is the 3601 responsibility of the TSM to only allow verified TAs from trusted SPs 3602 into the system. Delivery of that TA to the TEE is then the 3603 responsibility of the TEE, using the security mechanisms provided by 3604 the OTrP protocol. 3606 We allow a way for application to check trustworthy of a TA. OTrP 3607 Agent will have a function to allow an application query the metadata 3608 of a TA. 3610 An application in the Rich O/S may perform verification of the TA by 3611 verifying the signature of the TA. The 3612 OTRPService.getTAInformation() function is available to return TEE 3613 supplied TA signer and TSM signer information to the application. An 3614 application can do additional trust check on the certificate returned 3615 for this TA. It may trust TSM, or require additional SP signer trust 3616 chaining. 3618 14.7. One TA Multiple SP Case 3620 A TA for different SP must have different identifier. A TA will be 3621 installed in different SD for the respective SP. 3623 14.8. OTrP Agent Trust Model 3625 An OTrP Agent could be malware in the vulnerable Android OS. A 3626 Client Application will connect its TSM provider for required TA 3627 installation. It gets command messages from TSM, and passes the 3628 message to the OTrP Agent. 3630 The OTrP protocol is a conduit for enabling the TSM to communicate 3631 with the device's TEE to manage SDs and TAs. All TSM messages are 3632 signed and sensitive data is encrypted such that the OTrP Agent 3633 cannot modify or capture sensitive data. 3635 14.9. OCSP Stapling Data for TSM signed messages 3637 The GetDeviceStateRequest message from TSM to TEE shall include OCSP 3638 stapling data for the TSM's signer certificate and that for 3639 intermediate CA certificates up to the root certificate so that the 3640 TEE side can verify the signer certificate's revocation status. 3642 Certificate revocation status check on a TA signer certificate is 3643 optional by a TEE. A TSM is generally expected to do proper TA 3644 application vetting and its SP signer trust validation. A TEE will 3645 trust a TA signer certificate's validation status done by a TSM when 3646 it trusts the TSM. 3648 14.10. Data protection at TSM and TEE 3650 The TEE implementation provides protection of data on the device. It 3651 is the responsibility of the TSM to protect data on its servers. 3653 14.11. Privacy consideration 3655 Devices are issued with a unique TEE certificate to attest a device 3656 validity. This uniqueness also creates a privacy and tracking risk 3657 that must be mitigated. 3659 The TEE will only release the TEE certificate to a trusted TSM (it 3660 must verify the TSM certificate before proceeding). The OTrP 3661 protocol is designed such that only the TSM can obtain the TEE device 3662 certificate and firmware certificate - the GetDeviceState message 3663 requires signature checks to validate the TSM is trusted, and then 3664 delivers the device's certificate(s) encrypted such that only that 3665 TSM may decrypt the response. A Client Application will never see 3666 device certificate. 3668 A SP specific TEE SP AIK (TEE SP Anonymous Key) is generated by the 3669 protocol for Client Applications. This provides a way for the Client 3670 Application to validate data sent from the TEE without requiring the 3671 TEE device certificate to be released to the client device rich O/S , 3672 and to optionally allow an SP to encrypt a TA for a target device 3673 without the SP needing to be supplied the TEE device certificate. 3675 14.12. Threat mitigation 3677 A rogue application may perform excessive TA loading. OTrP Agent 3678 implementation should protect against excessive calls. 3680 Rogue applications may request excessive SD creation request. The 3681 TSM is responsible to ensure this is properly guarded against. 3683 Rogue OTrP Agent could replay or send TSM messages out of 3684 sequence:e.g. TSM sends update1 and update2. OTrP Agent replays 3685 update2 and update1 again, create unexpected result that client 3686 wants. "dsihash" is used to mitigate this. The TEE MUST make sure 3687 it stores DSI state and checks DSI state matches before it does 3688 another update. 3690 Concurrent calls from TSM to TEE should be handled properly by a TEE. 3691 It is up to the device to manage concurrency to the TEE. If multiple 3692 concurrent TSM operations take place these could fail due "dsihash" 3693 being modified by another concurrent operation. If locking is 3694 implemented on the client, this must be done in such a way that one 3695 application cannot lock other applications from using the TEE, except 3696 for a short term duration of the TSM operation taking place. For 3697 example, an OTrP operation that starts but never completes (e.g. loss 3698 of connectivity) must not prevent subsequent OTrP messages from being 3699 executed. 3701 14.13. Compromised CA 3703 If a root CA for TSM certificates is found compromised, some TEE 3704 trust anchor update mechanism should be devised. A compromised 3705 intermediate CA is covered by OCSP stapling and OCSP validation check 3706 in the protocol. A TEE should validate certificate revocation about 3707 a TSM certificate chain. 3709 If the root CA of some TEE device certificates is compromised, these 3710 devices might be rejected by TSM, which is a decision of TSM 3711 implementation and policy choice. Any intermediate CA for TEE device 3712 certificates should be validated by TSM with common CRL or OCSP 3713 method. 3715 14.14. Compromised TSM 3717 The TEE should use validation of the supplied TSM certificates and 3718 OCSP stapled data to validate that the TSM is trustworthy. 3720 Since PKI is used, the integrity of the clock within the TEE 3721 determines the ability of the TEE to reject an expired TSM 3722 certificate, or revoked TSM certificate. Since OCSP stapling 3723 includes signature generation time, certificate validity dates are 3724 compared to the current time. 3726 14.15. Certificate renewal 3728 TFW and TEE device certificates are expected to be long lived, longer 3729 than the lifetime of a device. A TSM certificate usually has a 3730 moderate lifetime of 2 to 5 years. TSM should get renewed or rekeyed 3731 certificates.The root CA certificates for TSM, which is embedded into 3732 the trust anchor store in a device, should have long lifetime that 3733 don't require device trust anchor update. On the other hand, it is 3734 imperative that OEM or device providers plan for support of trust 3735 anchor update in their shipped devices. 3737 15. References 3739 15.1. Normative References 3741 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3742 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 3743 RFC2119, March 1997, 3744 . 3746 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 3747 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 3748 2015, . 3750 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 3751 RFC 7516, DOI 10.17487/RFC7516, May 2015, 3752 . 3754 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/ 3755 RFC7517, May 2015, 3756 . 3758 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 3759 10.17487/RFC7518, May 2015, 3760 . 3762 15.2. Informative References 3764 [GPTEE] Global Platform, "Global Platform, GlobalPlatform Device 3765 Technology: TEE System Architecture, v1.0", 2013. 3767 Appendix A. Sample Messages 3769 A.1. Sample Security Domain Management Messages 3770 A.1.1. Sample GetDeviceState 3772 A.1.1.1. Sample GetDeviceStateRequest 3774 TSM builds a "GetDeviceStateTBSRequest" message. 3776 { 3777 "GetDeviceStateTBSRequest": { 3778 "ver": "1.0", 3779 "rid": "8C6F9DBB-FC39-435c-BC89-4D3614DA2F0B", 3780 "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE", 3781 "ocspdat": "c2FtcGxlIG9jc3BkYXQgQjY0IGVuY29kZWQgQVNOMQ==", 3782 "icaocspdat": "c2FtcGxlIGljYW9jc3BkYXQgQjY0IGVuY29kZWQgQVNOMQ==", 3783 "supportedsigalgs": "RS256" 3784 } 3785 } 3787 TSM signs "GetDeviceStateTBSRequest", creating 3788 "GetDeviceStateRequest" 3790 { 3791 "GetDeviceStateRequest": { 3792 "payload":" 3793 ewoJIkdldERldmljZVN0YXRlVEJTUmVxdWVzdCI6IHsKCQkidmVyIjogIjEuMCIsCgkJ 3794 InJpZCI6IHs4QzZGOURCQi1GQzM5LTQzNWMtQkM4OS00RDM2MTREQTJGMEJ9LAoJCSJ0 3795 aWQiOiAiezRGNDU0QTdGLTAwMkQtNDE1Ny04ODRFLUIwREQxQTA2QThBRX0iLAoJCSJv 3796 Y3NwZGF0IjogImMyRnRjR3hsSUc5amMzQmtZWFFnUWpZMElHVnVZMjlrWldRZ1FWTk9N 3797 UT09IiwKCQkiaWNhb2NzcGRhdCI6ICJjMkZ0Y0d4bElHbGpZVzlqYzNCa1lYUWdRalkw 3798 SUdWdVkyOWtaV1FnUVZOT01RPT0iLAoJCSJzdXBwb3J0ZWRzaWdhbGdzIjogIlJTMjU2 3799 IgoJfQp9", 3800 "protected": "eyJhbGciOiJSUzI1NiJ9", 3801 "header": { 3802 "x5c": ["ZXhhbXBsZSBBU04xIHNpZ25lciBjZXJ0aWZpY2F0ZQ==", 3803 "ZXhhbXBsZSBBU04xIENBIGNlcnRpZmljYXRl"] 3804 }, 3805 "signature":"c2FtcGxlIHNpZ25hdHVyZQ" 3806 } 3807 } 3809 A.1.1.2. Sample GetDeviceStateResponse 3811 TSM sends "GetDeviceStateRequest" to OTrP Agent 3813 OTrP Agent obtains "dsi" from each TEE. (in this example there is a 3814 single TEE). 3816 TEE obtains signed "fwdata" from firmware 3817 TEE builds "dsi" - summarizing device state of TEE 3819 { 3820 "dsi": { 3821 "tfwdata": { 3822 "tbs": "ezRGNDU0QTdGLTAwMkQtNDE1Ny04ODRFLUIwREQxQTA2QThBRX0=", 3823 "cert": "ZXhhbXBsZSBGVyBjZXJ0aWZpY2F0ZQ==", 3824 "sigalg": "RS256", 3825 "sig": "c2FtcGxlIEZXIHNpZ25hdHVyZQ==" 3826 }, 3827 "tee": { 3828 "name": "Primary TEE", 3829 "ver": "1.0", 3830 "cert": "c2FtcGxlIFRFRSBjZXJ0aWZpY2F0ZQ==", 3831 "cacert": [ 3832 "c2FtcGxlIENBIGNlcnRpZmljYXRlIDE=", 3833 "c2FtcGxlIENBIGNlcnRpZmljYXRlIDI=" 3834 ], 3835 "sdlist": { 3836 "cnt": "1", 3837 "sd": [ 3838 { 3839 "name": "default.acmebank.com", 3840 "spid": "acmebank.com", 3841 "talist": [ 3842 { 3843 "taid": "acmebank.secure.banking", 3844 "taname": "Acme secure banking app" 3845 }, 3846 { 3847 "taid": "acmebank.loyalty.rewards", 3848 "taname": "Acme loyalty rewards app" 3849 } 3850 ] 3851 } 3852 ] 3853 }, 3854 "teeaiklist": [ 3855 { 3856 "spaik": "c2FtcGxlIEFTTjEgZW5jb2RlZCBQS0NTMSBwdWJsaWNrZXk=", 3857 "spaiktype": "RSA", 3858 "spid": "acmebank.com" 3859 } 3860 ] 3861 } 3862 } 3863 } 3864 TEE encrypts "dsi", and embeds into "GetDeviceTEEStateTBSResponse" 3865 message 3867 { 3868 "GetDeviceTEEStateTBSResponse": { 3869 "ver": "1.0", 3870 "status": "pass", 3871 "rid": "{8C6F9DBB-FC39-435c-BC89-4D3614DA2F0B}", 3872 "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}", 3873 "signerreq":"false", 3874 "edsi": { 3875 "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0K", 3876 "recipients": [ 3877 { 3878 "header": { 3879 "alg": "RSA1_5" 3880 }, 3881 "encrypted_key": 3882 " 3883 QUVTMTI4IChDRUspIGtleSwgZW5jcnlwdGVkIHdpdGggVFNNIFJTQSBwdWJsaWMg 3884 a2V5LCB1c2luZyBSU0ExXzUgcGFkZGluZw" 3885 } 3886 ], 3887 "iv": "ySGmfZ69YlcEilNr5_SGbA", 3888 "ciphertext": 3889 " 3890 c2FtcGxlIGRzaSBkYXRhIGVuY3J5cHRlZCB3aXRoIEFFUzEyOCBrZXkgZnJvbSByZW 3891 NpcGllbnRzLmVuY3J5cHRlZF9rZXk", 3892 "tag": "c2FtcGxlIGF1dGhlbnRpY2F0aW9uIHRhZw" 3893 } 3894 } 3895 } 3897 TEE signs "GetDeviceTEEStateTBSResponse" and returns to OTrP Agent. 3898 OTrP Agent encodes "GetDeviceTEEStateResponse" into an array to form 3899 "GetDeviceStateResponse" 3901 { 3902 "GetDeviceStateResponse": [ 3903 { 3904 "GetDeviceTEEStateResponse": { 3905 "payload": 3906 " 3907 ewogICJHZXREZXZpY2VURUVTdGF0ZVRCU1Jlc3BvbnNlIjogewogICAgInZlciI6 3908 ICIxLjAiLAogICAgInN0YXR1cyI6ICJwYXNzIiwKICAgICJyaWQiOiAiezhDNkY5 3909 REJCLUZDMzktNDM1Yy1CQzg5LTREMzYxNERBMkYwQn0iLAogICAgInRpZCI6ICJ7 3910 NEY0NTRBN0YtMDAyRC00MTU3LTg4NEUtQjBERDFBMDZBOEFFfSIsCgkic2lnbmVy 3911 cmVxIjoiZmFsc2UiLAogICAgImVkc2kiOiB7CiAgICAgICJwcm90ZWN0ZWQiOiAi 3912 ZXlKbGJtTWlPaUpCTVRJNFEwSkRMVWhUTWpVMkluMEsiLAogICAgICAicmVjaXBp 3913 ZW50cyI6IFsKICAgICAgICB7CiAgICAgICAgICAiaGVhZGVyIjogewogICAgICAg 3914 ICAgImFsZyI6ICJSU0ExXzUiCiAgICAgICAgfSwKICAgICAgICAiZW5jcnlwdGVk 3915 X2tleSI6CiAgICAgICAgIgogICAgICAgIFFVVlRNVEk0SUNoRFJVc3BJR3RsZVN3 3916 Z1pXNWpjbmx3ZEdWa0lIZHBkR2dnVkZOTklGSlRRU0J3ZFdKc2FXTWcKICAgICAg 3917 ICBhMlY1TENCMWMybHVaeUJTVTBFeFh6VWdjR0ZrWkdsdVp3IgogICAgICAgIH0K 3918 ICAgICAgXSwKICAgICAgIml2IjogInlTR21mWjY5WWxjRWlsTnI1X1NHYkEiLAog 3919 ICAgICAiY2lwaGVydGV4dCI6CiAgICAgICIKICAgICAgYzJGdGNHeGxJR1J6YVNC 3920 a1lYUmhJR1Z1WTNKNWNIUmxaQ0IzYVhSb0lFRkZVekV5T0NCclpYa2dabkp2YlNC 3921 eVpXCiAgICAgIE5wY0dsbGJuUnpMbVZ1WTNKNWNIUmxaRjlyWlhrIiwKICAgICAg 3922 InRhZyI6ICJjMkZ0Y0d4bElHRjFkR2hsYm5ScFkyRjBhVzl1SUhSaFp3IgogICAg 3923 fQogIH0KfQ", 3924 "protected": "eyJhbGciOiJSUzI1NiJ9", 3925 "signature": "c2FtcGxlIHNpZ25hdHVyZQ" 3926 } 3927 } 3928 ] 3929 } 3931 TEE returns "GetDeviceStateResponse" back to OTrP Agent, which 3932 returns message back to TSM. 3934 A.1.2. Sample CreateSD 3936 A.1.2.1. Sample CreateSDRequest 3937 { 3938 "CreateSDTBSRequest": { 3939 "ver":"1.0", 3940 "rid":"req-01", 3941 "tid":"tran-01", 3942 "tee":"SecuriTEE", 3943 "nextdsi":"false", 3944 "dsihash":"Iu-c0-fGrpMmzbbtiWI1U8u7wMJE7IK8wkJpsVuf2js", 3945 "content":{ 3946 "spid":"bank.com", 3947 "sdname":"sd.bank.com", 3948 "spcert":"MIIDFjCCAn- 3949 gAwIBAgIJAIk0Tat0tquDMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNVBAYTAktSMQ4wD 3950 AYDVQQIDAVTZW91bDESMBAGA1UEBwwJR3Vyby1kb25nMRAwDgYDVQQKDAdTb2xhY2l 3951 hMRAwDgYDVQQLDAdTb2xhY2lhMRUwEwYDVQQDDAxTb2xhLWNpYS5jb20wHhcNMTUwN 3952 zAyMDg1MTU3WhcNMjAwNjMwMDg1MTU3WjBsMQswCQYDVQQGEwJLUjEOMAwGA1UECAw 3953 FU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU29sYWNpYTEQMA4GA 3954 1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tMIGfMA0GCSqGSIb3DQE 3955 BAQUAA4GNADCBiQKBgQDYWLrFf2OFMEciwSYsyhaLY4kslaWcXA0hCWJRaFzt5mU- 3956 lpSJ4jeu92inBbsXcI8PfRbaItsgW1TD1Wg4gQH4MX_YtaBoOepE-- 3957 3JoZZyPyCWS3AaLYWrDmqFXdbzaO1i8GxB7zz0gWw55bZ9jyzcl5gQzWSqMRpx_dca 3958 d2SP2wIDAQABo4G_MIG8MIGGBgNVHSMEfzB9oXCkbjBsMQswCQYDVQQGEwJLUjEOMA 3959 wGA1UECAwFU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU29sYWNp 3960 YTEQMA4GA1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tggkAiTRNq3 3961 S2q4MwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0lAQH_BAwwCgYIKwYB 3962 BQUHAwMwDQYJKoZIhvcNAQEFBQADgYEAEFMhRwEQ- 3963 LDa9O7P1N0mcLORpo6fW3QuJfuXbRQRQGoXddXMKazI4VjbGaXhey7Bzvk6TZYDa- 3964 GRiZby1J47UPaDQR3UiDzVvXwCOU6S5yUhNJsW_BeMViYj4lssX28iPpNwLUCVm1QV 3965 THILI6afLCRWXXclc1L5KGY290OwIdQ", 3966 "tsmid":"tsm_x.acme.com", 3967 "did":"zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM" 3968 } 3969 } 3970 } 3972 Here is a sample message after the content is encrypted and encoded 3974 { 3975 "CreateSDRequest": { 3976 "payload":" 3977 eyJDcmVhdGVTRFRCU1JlcXVlc3QiOnsidmVyIjoiMS4wIiwicmlkIjoicmVxLTAxIiwidG 3978 lkIjoidHJhbi0wMSIsInRlZSI6IlNlY3VyaVRFRSIsIm5leHRkc2kiOiJmYWxzZSIsImRz 3979 aWhhc2giOiIyMmVmOWNkM2U3YzZhZTkzMjZjZGI2ZWQ4OTYyMzU1M2NiYmJjMGMyNDRlYz 3980 gyYmNjMjQyNjliMTViOWZkYTNiIiwiY29udGVudCI6eyJwcm90ZWN0ZWQiOiJlLUtBbkdW 3981 dVktS0FuVHJpZ0p4Qk1USTRRMEpETFVoVE1qVTI0b0NkZlEiLCJyZWNpcGllbnRzIjpbey 3982 JoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0sImVuY3J5cHRlZF9rZXkiOiJTUzE2NTl4Q2FJ 3983 c1dUeUlsVTZPLUVsZzU4UUhvT1pCekxVRGptVG9vanBaWE54TVpBakRMcWtaSTdEUzhOVG 3984 FIWHcxczFvZjgydVhsM0d6NlVWMkRoZDJ3R2l6Y2VEdGtXc1RwZDg4QVYwaWpEYTNXa3lk 3985 dEpSVmlPOGdkSlEtV29NSUVJRUxzVGthblZCb25wQkF4ZHE0ckVMbl9TZlliaFg4Zm9ub2 3986 gxUVUifV0sIml2IjoiQXhZOERDdERhR2xzYkdsamIzUm9aUSIsImNpcGhlcnRleHQiOiI1 3987 bmVWZXdndm55UXprR3hZeWw5QlFrZTJVNjVaOHp4NDdlb3NzM3FETy0xY2FfNEpFY3NLcj 3988 ZhNjF5QzBUb0doYnJOQWJXbVRSemMwSXB5bTF0ZjdGemp4UlhBaTZBYnVSM2gzSUpRS1Bj 3989 UUVvRUlkZ2tWX0NaZTM2eTBkVDBpRFBMclg0QzFkb0dmMEdvaWViRC1yVUg1VUtEY3BsTW 3990 9lTjZvUnFyd0dnNUhxLTJXM3B4MUlzY0h4SktRZm11dkYxMTJ4ajBmZFNZX0N2WFE1NTJr 3991 TVRDUW1ZbzRPaGF2R0ZvaG9TZVVnaGZSVG1LYWp3OThkTzdhREdrUEpRUlBtYVVHWllEMW 3992 JXd01nMXFRV3RPd19EZlIyZDNzTzVUN0pQMDJDUFprVXBiQ3dZYVcybW9HN1c2Zlc2U3V5 3993 Q2lpd2pQWmZSQmIzSktTVTFTd1kxYXZvdW02OWctaDB6by12TGZvbHRrWFV2LVdPTXZTY0 3994 JzR25NRzZYZnMzbXlTWnJ1WTNRR09wVVRzdjFCQ0JqSTJpdjkwb2U2aXFCcVpxQVBxbzdi 3995 ajYwVlJGQzZPTlNLZExGQTIyU3pqRHo1dmtnTXNEaHkwSzlDeVhYN1Z6MkNLTXJvQjNiUE 3996 xFZF9abTZuVWlkTFN5cVJ5cXJxTmVnN1lmQng3aV93X0dzRW9rX1VYZXd6RGtneHp6RjZj 3997 XzZ6S0s3UFktVnVmYUo0Z2dHZmlpOHEwMm9RZ1VEZTB2Vm1FWDc0c2VQX2RxakVpZVVOYm 3998 xBZE9sS2dBWlFGdEs4dy1xVUMzSzVGTjRoUG9yeDc2b3lPVUpOQTVFZVV2Qy1jR2tMcTNQ 3999 UG1GRmQyaUtOTElCTEJzVWl6c1h3RERvZVA5SmktWGt5ZEQtREN1SHdpcno0OEdNNWVLSj 4000 Q5WVdqRUtFQko2T01NNUNmZHZ4cDNmVG1uUTdfTXcwZ3FZVDRiOUJJSnBfWjA3TTctNUpE 4001 emg0czhyU3dsQzFXU3V2RmhRWlJCcXJtX2RaUlRIb0VaZldXc1VCSWVNWWdxNG1zb0JqTj 4002 NXSzhnRWYwZGI5a3Z6UG9LYmpJRy10UUE2R2l1X3pHaFVfLXFBV1lLemVKMDZ6djRIWlBO 4003 dHktQXRyTGF0WGhtUTdOQlVrX0hvbjdOUWxhU1g1ZHVNVmN4bGs1ZHVrWFZNMDgxa09wYV 4004 kzbDliQVFfYVhTM0FNaFFTTVVsT3dnTDZJazFPYVpaTGFMLUE3ejlITnlESmFEWTVhakZK 4005 TWFDV1lfOG94YlNoQUktNXA2MmNuT0xzV0dNWWNKTlBGVTZpcWlMR19oc3JfNlNKMURhbD 4006 VtQ0YycnBJLUItMlhuckxZR01ZS0NEZ2V2dGFnbi1DVUV6RURwR3ozQ2VLcWdQU0Vqd3BK 4007 N0M3NXduYTlCSmtTUkpOdDNla3hoWElrcnNEazRHVVpMSDdQYzFYZHdRTXhxdWpzNmxJSV 4008 EycjM1NWEtVkotWHdPcFpfY3RPdW96LTA4WHdYQ3RkTEliSFFVTG40RjlMRTRtanU0dUxS 4009 bjNSc043WWZ1S3dCVmVEZDJ6R3NBY0s5SVlDa3hOaDk3dDluYW1iMDZqSXVoWXF5QkhWRU 4010 9nTkhici1rMDY1bW9OVk5lVVUyMm5OdVNKS0ZxVnIxT0dKNGVfNXkzYkNwTmxTeEFPV1Bn 4011 RnJzU0Flc2JJOWw4eVJtVTAwenJYdGc4OWt5SjlCcXN2eXA1RE8wX2FtS1JyMXB1MVJVWF 4012 lFZzB2ampKS1FSdDVZbXRUNFJzaWpqdGRDWDg3UUxJaUdSY0hDdlJzUzZSdDJESmNYR1ht 4013 UGQyc0ZmNUZyNnJnMkFzX3BmUHN3cnF1WlAxbVFLc3RPMFVkTXpqMTlyb2N1NHVxVXlHUD 4014 lWWU54cHVnWVdNSjRYb1dRelJtWGNTUEJ4VEtnenFPS2s3UnRzWWVMNXl4LVM4NjV0cHVz 4015 dTA0bXpzYUJRZ21od1ZFVXBRdWNrcG1YWkNLNHlJUXktaHNFQUlJSmVxdFB3dVAySXF0X2 4016 I5dlk0bzExeXdzeXhzdmp2RnNKN0VVZU1MaGE2R2dSanBSbnU5RWIzRnlJZ0U5M0VVNEEw 4017 T0lUMWlOSGNRYWc0eWtOc3dPdkxQbjZIZ21zQ05ESlgwekc2RlFDMTZRdjBSQ25SVTdfV2 4018 VvblhSTUZwUzZRZ1JiSk45R1NMckN5bklJSWxUcDBxNHBaS05zM0tqQ2tMUzJrb3Bhd2Y0 4019 WF9BUllmTko3a0s5eW5BR0dCcktnUWJNRWVxUEFmMDBKMlYtVXpuU1JMZmQ4SGs3Y2JEdk 4020 5RQlhHQW9BR0ViaGRwVUc0RXFwMlVyQko3dEtyUUVSRlh4RTVsOFNHY2czQ1RmN2Zoazdx 4021 VEFBVjVsWEFnOUtOUDF1c1ZRZk1fUlBleHFNTG9WQVVKV2syQkF6WF9uSEhkVVhaSVBIOG 4022 hLeDctdEFRV0dTWUd0R2FmanZJZzI2c082TzloQWZVd3BpSV90MzF6SkZORDU0OTZURHBz 4023 QmNnd2dMLU1UcVhCRUJ2NEhvQld5SG1DVjVFMUwiLCJ0YWciOiJkbXlEeWZJVlNJUi1Ren 4024 ExOEgybFRIeEMxbl9HZEtrdnZNMDJUcHdsYzQwIn19fQ", 4025 "protected":"e-KAnGFsZ-KAnTrigJxSUzI1NuKAnX0", //RSAwithSHA256 4026 "header": { 4027 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4028 "signer":" 4029 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA 4030 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4031 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh 4032 cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p 4033 YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy 4034 BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4035 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4036 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3 4037 c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4038 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA 4039 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4040 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR 4041 MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq 4042 hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G 4043 SZ1MdyIZV8fwdEmD90IvtMHgtzK- 4044 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA 4045 UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4046 }, 4047 "signature":"nuQUsCTEBLeaRzuwd7q1iPIYEJ2eJfurO5sT5Y- 4048 N03zFRcv1jvrqMHtx_pw0Y9YWjmpoWfpfelhwGEko9SgeeBnznmkZbp7kjS6MmX4CKz 4049 9OApe3-VI7yL9Yp0WNdRh3425eYfuapCy3lcXFln5JBAUnU_OzUg3RWxcU_yGnFsw" 4050 } 4051 } 4053 A.1.2.2. Sample CreateSDResponse 4055 { 4056 "CreateSDTBSResponse": { 4057 "ver":"1.0", 4058 "status":"pass", 4059 "rid":"req-01", 4060 "tid":"tran-01", 4061 "content":{ 4062 "did":"zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM", 4063 "sdname":"sd.bank.com", 4064 "teespaik":"AQABjY9KiwH3hkMmSAAN6CLXot525U85WNlWKAQz5TOdfe_CM8h- 4065 X6_EHX1gOXoyRXaBiKMqWb0YZLCABTw1ytdXy2kWa525imRho8Vqn6HDGsJDZPDru9 4066 GnZR8pZX5ge_dWXB_uljMvDttc5iAWEJ8ZgcpLGtBTGLZnQoQbjtn1lIE", 4067 } 4068 } 4069 } 4071 Here is the response message after the content is encrypted and 4072 encoded. 4074 { 4075 "CreateSDResponse": { 4076 "payload":" 4077 eyJDcmVhdGVTRFRCU1Jlc3BvbnNlIjp7InZlciI6IjEuMCIsInN0YXR1cyI6InBhc3Mi 4078 LCJyaWQiOiJyZXEtMDEiLCJ0aWQiOiJ0cmFuLTAxIiwiY29udGVudCI6eyJwcm90ZWN0 4079 ZWQiOiJlLUtBbkdWdVktS0FuVHJpZ0p4Qk1USTRRMEpETFVoVE1qVTI0b0NkZlEiLCJy 4080 ZWNpcGllbnRzIjpbeyJoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0sImVuY3J5cHRlZF9r 4081 ZXkiOiJOX0I4R3pldUlfN2hwd0wwTFpHSTkxVWVBbmxJRkJfcndmZU1yZERrWnFGak1s 4082 VVhjdlI0XzhhOGhyeFI4SXR3aEtFZnVfRWVLRDBQb0dqQ2pCSHcxdG1ULUN6eWhsbW5v 4083 Slk3LXllWnZzRkRpc2VNTkd0eGE0OGZJYUs2VWx5NUZMYXBCZVc5T1I5bmktOU9GQV9j 4084 aFVuWWl3b2Q4ZTJFa0Vpd0JEZ1EzMk0ifV0sIml2IjoiQXhZOERDdERhR2xzYkdsamIz 4085 Um9aUSIsImNpcGhlcnRleHQiOiJsalh6Wk5JTmR1WjFaMXJHVElkTjBiVUp1RDRVV2xT 4086 QVptLWd6YnJINFVDYy1jMEFQenMtMWdWSFk4NTRUR3VMYkdyRmVHcDFqM2Fsb1lacWZp 4087 ZnE4aEt3Ty16RFlBN2tmVFhBZHp6czM4em9xeG4zbHoyM2w1RUlGUWhrOHBRWTRYTHRW 4088 M3ZBQWlNYnlrQ1Q3VS1CWDdWcjBacVNhYWZTQVZ4OFBLQ1RIU3hHN3hHVko0NkxxRzJS 4089 RE54WXQ4RC1SQ3lZUi1zRTM0MUFKZldEc2FLaGRRbzJXcjNVN1hTOWFqaXJtWjdqTlJ4 4090 cVRodHJBRWlIY1ctOEJMdVFHWEZ1YUhLMTZrenJKUGl4d0VXbzJ4cmw4cmkwc3ZRcHpl 4091 Z2M3MEt2Z0I0NUVaNHZiNXR0YlUya25hN185QU1Wcm4wLUJaQ1Bnb280MWlFblhuNVJn 4092 TXY2c2V2Y1JPQ2xHMnpWSjFoRkVLYjk2akEiLCJ0YWciOiIzOTZISTk4Uk1NQnR0eDlo 4093 ZUtsODROaVZLd0lJSzI0UEt2Z1RGYzFrbEJzIn19fQ", 4094 "protected": "e-KAnGFsZ-KAnTrigJxSUzI1NuKAnX0", 4095 "header": { 4096 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4097 "signer":" 4098 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJ 4099 BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp 4100 Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcN 4101 MTUwNzAyMDkwMTE4WhcNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzET 4102 MBEGA1UECAwKQ2FsaWZvcm5pYTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8G 4103 A1UECgwYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIGfMA0GCSqGSIb3DQEB 4104 AQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4105 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4106 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA 4107 6b_ZI3c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4108 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJ 4109 BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp 4110 Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX 4111 9nxZBNQWDjAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8E 4112 DDAKBggrBgEFBQcDAzANBgkqhkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4iv 4113 em4cIckfxzTBBiPHCjrrjB2X8Ktn8GSZ1MdyIZV8fwdEmD90IvtMHgtzK- 4114 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fV 4115 rJvnYAUBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4116 }, 4117 "signature":"jnJtaB0vFFwrE-qKOR3Pu9pf2gNoI1s67GgPCTq0U- 4118 qrz97svKpuh32WgCP2MWCoQPEswsEX-nxhIx_siTe4zIPO1nBYn- 4119 R7b25rQaF87O8uAOOnBN5Yl2Jk3laIbs- 4120 hGE32aRZDhrVoyEdSvIFrT6AQqD20bIAZGqTR-zA-900" 4121 } 4122 } 4124 A.1.3. Sample UpdateSD 4125 A.1.3.1. Sample UpdateSDRequest 4127 { 4128 "UpdateSDTBSRequest": { 4129 "ver": "1.0", 4130 "rid": "1222DA7D-8993-41A4-AC02-8A2807B31A3A", 4131 "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE", 4132 "tee": "Primary TEE ABC", 4133 "nextdsi": "false", 4134 "dsihash": 4135 " 4136 IsOvwpzDk8Onw4bCrsKTJsONwrbDrcKJYjVTw4vCu8OAw4JEw6zCgsK8w4JCacKxW8Kf 4137 w5o7", 4138 "content": { // NEEDS to BE ENCRYPTED 4139 "tsmid": "id1.tsmxyz.com", 4140 "spid": "com.acmebank.spid1", 4141 "sdname": "com.acmebank.sdname1", 4142 "changes": { 4143 "newsdname": "com.acmebank.sdname2", 4144 "newspid": "com.acquirer.spid1", 4145 "spcert": 4146 "MIIDFjCCAn- 4147 gAwIBAgIJAIk0Tat0tquDMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNVBAYTAktSMQ4 4148 wDAYDVQQIDAVTZW91bDESMBAGA1UEBwwJR3Vyby1kb25nMRAwDgYDVQQKDAdTb2x 4149 hY2lhMRAwDgYDVQQLDAdTb2xhY2lhMRUwEwYDVQQDDAxTb2xhLWNpYS5jb20wHhc 4150 NMTUwNzAyMDg1MTU3WhcNMjAwNjMwMDg1MTU3WjBsMQswCQYDVQQGEwJLUjEOMAw 4151 GA1UECAwFU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU29sYWN 4152 pYTEQMA4GA1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tMIGfMA0 4153 GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDYWLrFf2OFMEciwSYsyhaLY4kslaWcXA0 4154 hCWJRaFzt5mU- 4155 lpSJ4jeu92inBbsXcI8PfRbaItsgW1TD1Wg4gQH4MX_YtaBoOepE-- 4156 3JoZZyPyCWS3AaLYWrDmqFXdbzaO1i8GxB7zz0gWw55bZ9jyzcl5gQzWSqMRpx_d 4157 cad2SP2wIDAQABo4G_MIG8MIGGBgNVHSMEfzB9oXCkbjBsMQswCQYDVQQGEwJLUj 4158 EOMAwGA1UECAwFU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU2 4159 9sYWNpYTEQMA4GA1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tgg 4160 kAiTRNq3S2q4MwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0lAQH_BA 4161 wwCgYIKwYBBQUHAwMwDQYJKoZIhvcNAQEFBQADgYEAEFMhRwEQ- 4162 LDa9O7P1N0mcLORpo6fW3QuJfuXbRQRQGoXddXMKazI4VjbGaXhey7Bzvk6TZYDa 4163 - 4164 GRiZby1J47UPaDQR3UiDzVvXwCOU6S5yUhNJsW_BeMViYj4lssX28iPpNwLUCVm1 4165 QVTHILI6afLCRWXXclc1L5KGY290OwIdQ", 4166 "renewteespaik": "0" 4167 } 4168 } 4169 } 4170 } 4171 A.1.3.2. Sample UpdateSDResponse 4173 { 4174 "UpdateSDTBSResponse": { 4175 "ver": "1.0", 4176 "status": "pass", 4177 "rid": "1222DA7D-8993-41A4-AC02-8A2807B31A3A", 4178 "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE", 4179 "content": { 4180 "did": "MTZENTE5Qzc0Qzk0NkUxMzYxNzk0NjY4NTc3OTY4NTI=", 4181 "teespaik": 4182 "AQABjY9KiwH3hkMmSAAN6CLXot525U85WNlWKAQz5TOdfe_CM8h- 4183 X6_EHX1gOXoyRXaBiKMqWb0YZLCABTw1ytdXy2kWa525imRho8Vqn6HDGsJDZPDru9 4184 GnZR8pZX5ge_dWXB_uljMvDttc5iAWEJ8ZgcpLGtBTGLZnQoQbjtn1lIE", 4185 "teespaiktype": "RSA" 4186 } 4187 } 4188 } 4190 A.1.4. Sample DeleteSD 4192 A.1.4.1. Sample DeleteSDRequest 4194 TSM builds message - including data to be encrypted. 4196 { 4197 "DeleteSDTBSRequest": { 4198 "ver": "1.0", 4199 "rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}", 4200 "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}", 4201 "tee": "Primary TEE", 4202 "nextdsi": "false", 4203 "dsihash": "AAECAwQFBgcICQoLDA0ODwABAgMEBQYHCAkKCwwNDg8=", 4204 "content": ENCRYPTED { 4205 "tsmid": "tsm1.com", 4206 "sdname": "default.acmebank.com", 4207 "deleteta": "1" 4208 } 4209 } 4210 } 4212 TSM encrypts the "content". 4214 { 4215 "DeleteSDTBSRequest": { 4216 "ver": "1.0", 4217 "rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}", 4218 "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}", 4219 "tee": "Primary TEE", 4220 "nextdsi": "false", 4221 "dsihash": "AAECAwQFBgcICQoLDA0ODwABAgMEBQYHCAkKCwwNDg8=", 4222 "content": { 4223 "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0", 4224 "recipients": [ 4225 { 4226 "header": { 4227 "alg": "RSA1_5" 4228 }, 4229 "encrypted_key": 4230 " 4231 QUVTMTI4IChDRUspIGtleSwgZW5jcnlwdGVkIHdpdGggVFNNIFJTQSBwdWJsaWMga2 4232 V5LCB1c2luZyBSU0ExXzUgcGFkZGluZw" 4233 } 4234 ], 4235 "iv": "rWO5DVmQX9ogelMLBIogIA", 4236 "ciphertext": 4237 " 4238 c2FtcGxlIGRzaSBkYXRhIGVuY3J5cHRlZCB3aXRoIEFFUzEyOCBrZXkgZnJvbSByZWNp 4239 cGllbnRzLmVuY3J5cHRlZF9rZXk", 4240 "tag": "c2FtcGxlIGF1dGhlbnRpY2F0aW9uIHRhZw" 4241 } 4242 } 4243 } 4245 TSM signs "DeleteSDTBSRequest" to form "DeleteSDRequest" 4246 { 4247 "DeleteSDRequest": { 4248 "payload":" 4249 ewoJIkRlbGV0ZVNEVEJTUmVxdWVzdCI6IHsKCQkidmVyIjogIjEuMCIsCgkJInJp 4250 ZCI6ICJ7NzEyNTUxRjUtREZCMy00M2YwLTlBNjMtNjYzNDQwQjkxRDQ5fSIsCgkJ 4251 InRpZCI6ICJ7NEY0NTRBN0YtMDAyRC00MTU3LTg4NEUtQjBERDFBMDZBOEFFfSIs 4252 CgkJInRlZSI6ICJQcmltYXJ5IFRFRSIsCgkJIm5leHRkc2kiOiAiZmFsc2UiLAoJ 4253 CSJkc2loYXNoIjogIkFBRUNBd1FGQmdjSUNRb0xEQTBPRHdBQkFnTUVCUVlIQ0Fr 4254 S0N3d05EZzg9IiwKCQkiY29udGVudCI6IHsKCQkJInByb3RlY3RlZCI6ICJleUps 4255 Ym1NaU9pSkJNVEk0UTBKRExVaFRNalUySW4wIiwKCQkJInJlY2lwaWVudHMiOiBb 4256 ewoJCQkJImhlYWRlciI6IHsKCQkJCQkiYWxnIjogIlJTQTFfNSIKCQkJCX0sCgkJ 4257 CQkiZW5jcnlwdGVkX2tleSI6ICJRVVZUTVRJNElDaERSVXNwSUd0bGVTd2daVzVq 4258 Y25sd2RHVmtJSGRwZEdnZ1ZGTk5JRkpUUVNCd2RXSnNhV01nYTJWNUxDQjFjMmx1 4259 WnlCU1UwRXhYelVnY0dGa1pHbHVadyIKCQkJfV0sCgkJCSJpdiI6ICJyV081RFZt 4260 UVg5b2dlbE1MQklvZ0lBIiwKCQkJImNpcGhlcnRleHQiOiAiYzJGdGNHeGxJR1J6 4261 YVNCa1lYUmhJR1Z1WTNKNWNIUmxaQ0IzYVhSb0lFRkZVekV5T0NCclpYa2dabkp2 4262 YlNCeVpXTnBjR2xsYm5SekxtVnVZM0o1Y0hSbFpGOXJaWGsiLAoJCQkidGFnIjog 4263 ImMyRnRjR3hsSUdGMWRHaGxiblJwWTJGMGFXOXVJSFJoWnciCgkJfQoJfQp9", 4264 "protected":"eyJhbGciOiJSUzI1NiJ9", 4265 "header": { 4266 "x5c": ["ZXhhbXBsZSBBU04xIHNpZ25lciBjZXJ0aWZpY2F0ZQ==", 4267 "ZXhhbXBsZSBBU04xIENBIGNlcnRpZmljYXRl"] 4268 }, 4269 "signature":"c2FtcGxlIHNpZ25hdHVyZQ" 4270 } 4271 } 4273 A.1.4.2. Sample DeleteSDResponse 4275 TEE creates "DeleteSDTBSResponse" to respond to the "DeleteSDRequest" 4276 message from the TSM, including data to be encrypted. 4278 { 4279 "DeleteSDTBSResponse": { 4280 "ver": "1.0", 4281 "status": "pass", 4282 "rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}", 4283 "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}", 4284 "content": ENCRYPTED { 4285 "did": "MTZENTE5Qzc0Qzk0NkUxMzYxNzk0NjY4NTc3OTY4NTI=", 4286 } 4287 } 4288 } 4290 TEE encrypts the "content" for the TSM. 4292 { 4293 "DeleteSDTBSResponse": { 4294 "ver": "1.0", 4295 "status": "pass", 4296 "rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}", 4297 "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}", 4298 "content": { 4299 "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0K", 4300 "recipients": [ 4301 { 4302 "header": { 4303 "alg": "RSA1_5" 4304 }, 4305 "encrypted_key": 4306 " 4307 QUVTMTI4IChDRUspIGtleSwgZW5jcnlwdGVkIHdpdGggVFNNIFJTQSBwdWJsaWMg 4308 a2V5LCB1c2luZyBSU0ExXzUgcGFkZGluZw" 4309 } 4310 ], 4311 "iv": "ySGmfZ69YlcEilNr5_SGbA", 4312 "ciphertext": 4313 " 4314 c2FtcGxlIGRzaSBkYXRhIGVuY3J5cHRlZCB3aXRoIEFFUzEyOCBrZXkgZnJvbSByZW 4315 NpcGllbnRzLmVuY3J5cHRlZF9rZXk", 4316 "tag": "c2FtcGxlIGF1dGhlbnRpY2F0aW9uIHRhZw" 4317 } 4318 } 4319 } 4321 TEE signs "DeleteSDTBSResponse" to form "DeleteSDResponse" 4322 { 4323 "DeleteSDResponse": { 4324 "payload":" 4325 ewoJIkRlbGV0ZVNEVEJTUmVzcG9uc2UiOiB7CgkJInZlciI6ICIxLjAiLAoJCSJz 4326 dGF0dXMiOiAicGFzcyIsCgkJInJpZCI6ICJ7NzEyNTUxRjUtREZCMy00M2YwLTlB 4327 NjMtNjYzNDQwQjkxRDQ5fSIsCgkJInRpZCI6ICJ7NEY0NTRBN0YtMDAyRC00MTU3 4328 LTg4NEUtQjBERDFBMDZBOEFFfSIsCgkJImNvbnRlbnQiOiB7CgkJCSJwcm90ZWN0 4329 ZWQiOiAiZXlKbGJtTWlPaUpCTVRJNFEwSkRMVWhUTWpVMkluMEsiLAoJCQkicmVj 4330 aXBpZW50cyI6IFt7CgkJCQkiaGVhZGVyIjogewoJCQkJCSJhbGciOiAiUlNBMV81 4331 IgoJCQkJfSwKCQkJCSJlbmNyeXB0ZWRfa2V5IjogIlFVVlRNVEk0SUNoRFJVc3BJ 4332 R3RsZVN3Z1pXNWpjbmx3ZEdWa0lIZHBkR2dnVkZOTklGSlRRU0J3ZFdKc2FXTWdh 4333 MlY1TENCMWMybHVaeUJTVTBFeFh6VWdjR0ZrWkdsdVp3IgoJCQl9XSwKCQkJIml2 4334 IjogInlTR21mWjY5WWxjRWlsTnI1X1NHYkEiLAoJCQkiY2lwaGVydGV4dCI6ICJj 4335 MkZ0Y0d4bElHUnphU0JrWVhSaElHVnVZM0o1Y0hSbFpDQjNhWFJvSUVGRlV6RXlP 4336 Q0JyWlhrZ1puSnZiU0J5WldOcGNHbGxiblJ6TG1WdVkzSjVjSFJsWkY5clpYayIs 4337 CgkJCSJ0YWciOiAiYzJGdGNHeGxJR0YxZEdobGJuUnBZMkYwYVc5dUlIUmhadyIK 4338 CQl9Cgl9Cn0", 4339 "protected":"eyJhbGciOiJSUzI1NiJ9", 4340 "signature":"c2FtcGxlIHNpZ25hdHVyZQ" 4341 } 4342 } 4344 TEE returns "DeleteSDResponse" back to OTrP Agent, which returns 4345 message back to TSM. 4347 A.2. Sample TA Management Messages 4349 A.2.1. Sample InstallTA 4351 A.2.1.1. Sample InstallTARequest 4352 { 4353 "InstallTATBSRequest": { 4354 "ver": "1.0", 4355 "rid": "24BEB059-0AED-42A6-A381-817DFB7A1207", 4356 "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE", 4357 "tee": "Primary TEE ABC", 4358 "nextdsi": "true", 4359 "dsihash": 4360 " 4361 IsOvwpzDk8Onw4bCrsKTJsONwrbDrcKJYjVTw4vCu8OAw4JEw6zCgsK8w4JCacKxW8Kf 4362 w5o7", 4363 "content": { 4364 "tsmid": "id1.tsmxyz.com", 4365 "spid": "com.acmebank.spid1", 4366 "sdname": "com.acmebank.sdname1", 4367 "taid": "com.acmebank.taid.banking" 4368 }, 4369 "encrypted_ta": { 4370 "key": 4371 "mLBjodcE4j36y64nC/nEs694P3XrLAOokjisXIGfs0H7lOEmT5FtaNDYEMcg9RnE 4372 ftlJGHO7N0lgcNcjoXBmeuY9VI8xzrsZM9gzH6VBKtVONSx0aw5IAFkNcyPZwDdZ 4373 MLwhvrzPJ9Fg+bZtrCoJz18PUz+5aNl/dj8+NM85LCXXcBlZF74btJer1Mw6ffzT 4374 /grPiEQTeJ1nEm9F3tyRsvcTInsnPJ3dEXv7sJXMrhRKAeZsqKzGX4eiZ3rEY+FQ 4375 6nXULC8cAj5XTKpQ/EkZ/iGgS0zcXR7KUJv3wFEmtBtPD/+ze08NILLmxM8olQFj 4376 //Lq0gGtq8vPC8r0oOfmbQ==", 4377 "iv": "4F5472504973426F726E496E32303135", 4378 "alg": "AESCBC", 4379 "ciphertadata": 4380 "......0x/5KGCXWfg1Vrjm7zPVZqtYZ2EovBow+7EmfOJ1tbk......=", 4381 "cipherpdata": "0x/5KGCXWfg1Vrjm7zPVZqtYZ2EovBow+7EmfOJ1tbk=" 4382 } 4383 } 4384 } 4386 A.2.1.2. Sample InstallTAResponse 4388 A sample to-be-signed response of InstallTA looks as follows. 4390 { 4391 "InstallTATBSResponse": { 4392 "ver": "1.0", 4393 "status": "pass", 4394 "rid": "24BEB059-0AED-42A6-A381-817DFB7A1207", 4395 "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE", 4396 "content": { 4397 "did": "MTZENTE5Qzc0Qzk0NkUxMzYxNzk0NjY4NTc3OTY4NTI=", 4398 "dsi": { 4399 "tfwdata": { 4400 "tbs": "ezRGNDU0QTdGLTAwMkQtNDE1Ny04ODRFLUIwREQxQTA2QThBRX0=" 4401 "cert": "ZXhhbXBsZSBGVyBjZXJ0aWZpY2F0ZQ==", 4402 "sigalg": "UlMyNTY=", 4403 "sig": "c2FtcGxlIEZXIHNpZ25hdHVyZQ==" 4404 }, 4405 "tee": { 4406 "name": "Primary TEE", 4407 "ver": "1.0", 4408 "cert": "c2FtcGxlIFRFRSBjZXJ0aWZpY2F0ZQ==", 4409 "cacert": [ 4410 "c2FtcGxlIENBIGNlcnRpZmljYXRlIDE=", 4411 "c2FtcGxlIENBIGNlcnRpZmljYXRlIDI=" 4412 ], 4413 "sdlist": { 4414 "cnt": "1", 4415 "sd": [ 4416 { 4417 "name": "com.acmebank.sdname1", 4418 "spid": "com.acmebank.spid1", 4419 "talist": [ 4420 { 4421 "taid": "com.acmebank.taid.banking", 4422 "taname": "Acme secure banking app" 4423 }, 4424 { 4425 "taid": "acom.acmebank.taid.loyalty.rewards", 4426 "taname": "Acme loyalty rewards app" 4427 } 4428 ] 4429 } 4430 ] 4431 }, 4432 "teeaiklist": [ 4433 { 4434 "spaik": 4435 "c2FtcGxlIEFTTjEgZW5jb2RlZCBQS0NTMSBwdWJsaWNrZXk=", 4436 "spaiktype": "RSA" 4437 "spid": "acmebank.com" 4438 } 4439 ] 4440 } 4441 } 4442 } 4443 } 4444 } 4446 A.2.2. Sample UpdateTA 4448 A.2.2.1. Sample UpdateTARequest 4450 { 4451 "UpdateTATBSRequest": { 4452 "ver": "1.0", 4453 "rid": "req-2", 4454 "tid": "tran-01", 4455 "tee": "SecuriTEE", 4456 "nextdsi": " false", 4457 "dsihash": "gwjul_9MZks3pqUSN1-eL1aViwGXNAxk0AIKW79dn4U", 4458 "content": { 4459 "tsmid": "tsm1.acme.com", 4460 "spid": "bank.com", 4461 "sdname": "sd.bank.com", 4462 "taid": "sd.bank.com.ta" 4463 }, 4464 "encrypted_ta": { 4465 "key": 4466 " 4467 XzmAn_RDVk3IozMwNWhiB6fmZlIs1YUvMKlQAv_UDoZ1fvGGsRGo9bT0A440aYMgLt 4468 GilKypoJjCgijdaHgamaJgRSc4Je2otpnEEagsahvDNoarMCC5nGQdkRxW7Vo2NKgL 4469 A892HGeHkJVshYm1cUlFQ-BhiJ4NAykFwlqC_oc", 4470 "iv": "AxY8DCtDaGlsbGljb3RoZQ", 4471 "alg": "AESCBC", 4472 "ciphernewtadata": 4473 "KHqOxGn7ib1F_14PG4_UX9DBjOcWkiAZhVE-U- 4474 67NsKryHGokeWr2spRWfdU2KWaaNncHoYGwEtbCH7XyNbOFh28nzwUmstep4nHWbAl 4475 XZYTNkENcABPpuw_G3I3HADo" 4476 } 4477 } 4478 } 4480 { 4481 "UpdateTARequest": { 4482 "payload" : 4483 " 4484 eyJVcGRhdGVUQVRCU1JlcXVlc3QiOnsidmVyIjoiMS4wIiwicmlkIjoicmVxLTIiLCJ0 4485 aWQiOiJ0cmFuLTAxIiwidGVlIjoiU2VjdXJpVEVFIiwibmV4dGRzaSI6ImZhbHNlIiwi 4486 ZHNpaGFzaCI6Imd3anVsXzlNWmtzM3BxVVNOMS1lTDFhVml3R1hOQXhrMEFJS1c3OWRu 4487 NFUiLCJjb250ZW50Ijp7InByb3RlY3RlZCI6ImV5SmxibU1pT2lKQk1USTRRMEpETFVo 4488 VE1qVTJJbjAiLCJyZWNpcGllbnRzIjpbeyJoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0s 4489 ImVuY3J5cHRlZF9rZXkiOiJYem1Bbl9SRFZrM0lvek13TldoaUI2Zm1abElzMVlVdk1L 4490 bFFBdl9VRG9aMWZ2R0dzUkdvOWJUMEE0NDBhWU1nTHRHaWxLeXBvSmpDZ2lqZGFIZ2Ft 4491 YUpnUlNjNEplMm90cG5FRWFnc2FodkROb2FyTUNDNW5HUWRrUnhXN1ZvMk5LZ0xBODky 4492 SEdlSGtKVnNoWW0xY1VsRlEtQmhpSjROQXlrRndscUNfb2MifV0sIml2IjoiQXhZOERD 4493 dERhR2xzYkdsamIzUm9aUSIsImNpcGhlcnRleHQiOiJIYTcwVXRZVEtWQmtXRFJuMi0w 4494 SF9IdkZtazl5SGtoVV91bk1OLWc1T3BqLWF1NGFUb2lxWklMYzVzYTdENnZZSjF6eW04 4495 QW1JOEJIVXFqc2l5Z0tOcC1HdURJUjFzRXc0a2NhMVQ5ZENuU0RydHhSUFhESVdrZmt3 4496 azZlR1NQWiIsInRhZyI6Im9UN01UTE41eWtBTFBoTDR0aUh6T1pPTGVFeU9xZ0NWaEM5 4497 MXpkcldMU0UifSwiZW5jcnlwdGVkX3RhIjp7ImtleSI6Ilh6bUFuX1JEVmszSW96TXdO 4498 V2hpQjZmbVpsSXMxWVV2TUtsUUF2X1VEb1oxZnZHR3NSR285YlQwQTQ0MGFZTWdMdEdp 4499 bEt5cG9KakNnaWpkYUhnYW1hSmdSU2M0SmUyb3RwbkVFYWdzYWh2RE5vYXJNQ0M1bkdR 4500 ZGtSeFc3Vm8yTktnTEE4OTJIR2VIa0pWc2hZbTFjVWxGUS1CaGlKNE5BeWtGd2xxQ19v 4501 YyIsIml2IjoiQXhZOERDdERhR2xzYkdsamIzUm9aUSIsImFsZyI6IkFFU0NCQyIsImNp 4502 cGhlcm5ld3RhZGF0YSI6IktIcU94R243aWIxRl8xNFBHNF9VWDlEQmpPY1draUFaaFZF 4503 LVUtNjdOc0tyeUhHb2tlV3Iyc3BSV2ZkVTJLV2FhTm5jSG9ZR3dFdGJDSDdYeU5iT0Zo 4504 MjhuendVbXN0ZXA0bkhXYkFsWFpZVE5rRU5jQUJQcHV3X0czSTNIQURvIn19fQ", 4505 "protected": " eyJhbGciOiJSUzI1NiJ9", 4506 "header": { 4507 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4508 "signer":" 4509 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA 4510 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4511 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh 4512 cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p 4513 YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy 4514 BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4515 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4516 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3 4517 c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4518 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA 4519 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4520 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR 4521 MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq 4522 hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G 4523 SZ1MdyIZV8fwdEmD90IvtMHgtzK- 4524 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA 4525 UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4526 }, 4527 "signature":"inB1K6G3EAhF- 4528 FbID83UI25R5Ao8MI4qfrbrmf0UQhjM3O7_g3l6XxN_JkHrGQaZr- 4529 myOkGPVM8BzbUZW5GqxNZwFXwMeaoCjDKc4Apv4WZkD1qKJxkg1k5jaUCfJz1Jmw_XtX 4530 6MHhrLh9ov03S9PtuT1VAQ0FVUB3qFIvjSnNU" 4531 } 4532 } 4534 A.2.2.2. Sample UpdateTAResponse 4535 { 4536 "UpdateTATBSResponse": { 4537 "ver": "1.0", 4538 "status": "pass", 4539 "rid": "req-2", 4540 "tid": "tran-01", 4541 "content": { 4542 "did": "zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM" 4543 } 4544 } 4545 } 4547 { 4548 "UpdateTAResponse":{ 4549 "payload":" 4550 eyJVcGRhdGVUQVRCU1Jlc3BvbnNlIjp7InZlciI6IjEuMCIsInN0YXR1cyI6InBhc3Mi 4551 LCJyaWQiOiJyZXEtMiIsInRpZCI6InRyYW4tMDEiLCJjb250ZW50Ijp7InByb3RlY3Rl 4552 ZCI6ImV5SmxibU1pT2lKQk1USTRRMEpETFVoVE1qVTJJbjAiLCJyZWNpcGllbnRzIjpb 4553 eyJoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0sImVuY3J5cHRlZF9rZXkiOiJFaGUxLUJB 4554 UUdJLTNEMFNHdXFGY01MZDJtd0gxQm1uRndYQWx1M1FxUFVXZ1RRVm55SUowNFc2MnBK 4555 YWVSREFkeTU0R0FSVjBrVzQ0RGw0MkdUUlhqbE1EZ3BYdXdFLWloc1JVV0tNNldCZ2N3 4556 VXVGQTRUR3gwU0I1NTZCdl92dnBNaFdfMXh2c2FHdFBaQmwxTnZjbXNibzBhY3FobXlu 4557 bzBDTmF5SVAtX1UifV0sIml2IjoiQXhZOERDdERhR2xzYkdsamIzUm9aUSIsImNpcGhl 4558 cnRleHQiOiJwc2o2dGtyaGJXM0lmVElMeE9GMU5HdFUtcTFmeVBidV9KWk9jbklycWIw 4559 eTNPOHN6OTItaWpWR1ZyRW5WbG1sY1FYeWFNZTNyX1JGdEkwV3B4UmRodyIsInRhZyI6 4560 Ik0zb2dNNk11MVJYMUMybEZvaG5rTkN5b25qNjd2TDNqd2RrZXhFdUlpaTgifX19", 4561 "protected":"eyJhbGciOiJSUzI1NiJ9", 4562 "header": { 4563 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4564 "signer":" 4565 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA 4566 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4567 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh 4568 cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p 4569 YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy 4570 BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4571 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4572 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3 4573 c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4574 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA 4575 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4576 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR 4577 MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq 4578 hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G 4579 SZ1MdyIZV8fwdEmD90IvtMHgtzK- 4580 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA 4581 UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4582 }, 4583 "signature":" 4584 Twajmt_BBLIMcNrDsjqr8lI7O7lEQxXZNhlUOtFkOMMqf37wOPKtp_99LoS82CVmdpCo 4585 PLaws8zzh-SNIQ42- 4586 9GYO8_9BaEGCiCwyl8YgWP9fWNfNv2gR2fl2DK4uknkYu1EMBW4YfP81n_pGpb4Gm- 4587 nMk14grVZygwAPej3ZZk" 4588 } 4589 } 4590 A.2.3. Sample DeleteTA 4592 A.2.3.1. Sample DeleteTARequest 4594 { 4595 "DeleteTATBSRequest": { 4596 "ver": "1.0", 4597 "rid": "req-2", 4598 "tid": "tran-01", 4599 "tee": "SecuriTEE", 4600 "nextdsi": "false", 4601 "dsihash": "gwjul_9MZks3pqUSN1-eL1aViwGXNAxk0AIKW79dn4U", 4602 "content": { 4603 "tsmid": "tsm1.acme.com", 4604 "sdname": "sd.bank.com", 4605 "taid": "sd.bank.com.ta" 4606 } 4607 } 4608 } 4610 { 4611 "DeleteTARequest": { 4612 "payload": 4613 " 4614 eyJEZWxldGVUQVRCU1JlcXVlc3QiOnsidmVyIjoiMS4wIiwicmlkIjoicmVxLTIiLCJ0 4615 aWQiOiJ0cmFuLTAxIiwidGVlIjoiU2VjdXJpVEVFIiwibmV4dGRzaSI6ImZhbHNlIiwi 4616 ZHNpaGFzaCI6Imd3anVsXzlNWmtzM3BxVVNOMS1lTDFhVml3R1hOQXhrMEFJS1c3OWRu 4617 NFUiLCJjb250ZW50Ijp7InByb3RlY3RlZCI6eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0s 4618 InJlY2lwaWVudHMiOlt7ImhlYWRlciI6eyJhbGciOiJSU0ExXzUifSwiZW5jcnlwdGVk 4619 X2tleSI6ImtyaGs0d2dpY0RlX3d0VXQyTW4tSUJsdUtvX0JkeXpNY2p1cVlBenBPYnRS 4620 TG9MZzQ0QkFLN2tRVWE1YTg0TEVJRGEzaHNtWDIxdldNZFJLczN4MTJsOUh5VFdfLUNS 4621 WmZtcUx2bEh1LV9MSVdvc1ZyRTZVMlJqUnRndllVOWliUkVLczkzRDRHWm4xVHFuZG9n 4622 d0tXRF9jdG1nWG1sbzZZVXpCWDZhR1dZMCJ9XSwiaXYiOiJBeFk4REN0RGFHbHNiR2xq 4623 YjNSb1pRIiwiY2lwaGVydGV4dCI6IkhhNzBVdFlUS1ZCa1dEUm4yLTBIX1BGa19yQnpQ 4624 dGJHdzhSNktlMXotdklNeFBSY0Nxa1puZmwyTjRjUTZPSTZCSHZJUUFoM2Jic0l0dHlR 4625 bXhDTE5Nbm8wejBrYm9TdkIyVXlxWExpeGVZIiwidGFnIjoidEtUbFRLdlR2LTRtVVlG 4626 Y1dYWnZMMVlhQnRGNloxVlNxOTMzVmI2UEpmcyJ9fX0", 4627 "protected" : "eyJhbGciOiJSUzI1NiJ9", 4628 "header": { 4629 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4630 "signer":" 4631 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA 4632 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4633 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh 4634 cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p 4635 YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy 4636 BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4637 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4638 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3 4639 c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4640 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA 4641 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4642 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR 4643 MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq 4644 hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G 4645 SZ1MdyIZV8fwdEmD90IvtMHgtzK- 4646 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA 4647 UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4648 }, 4649 "signature" : 4650 " 4651 BZS0_Ab6pqvGNXe5lqT4Sc3jakyWQeiK9KlVSnimwWnjCCyMtyB9bwvlbILZba3IJiFe 4652 _3F9bIQpSytGS0f2TQrPTKC7pSjwDw-3kH7HkHcPPJd- 4653 PpMMfQvRx7AIV8vBqO9MijIC62iN0V2se5z2v8VFjGSoRGgq225w7FvrnWE" 4654 } 4655 } 4656 A.2.3.2. Sample DeleteTAResponse 4658 { 4659 "DeleteTATBSResponse": { 4660 "ver": "1.0", 4661 "status": "pass", 4662 "rid": "req-2", 4663 "tid": "tran-01", 4664 "content": { 4665 "did": "zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM" 4666 } 4667 } 4668 } 4670 { 4671 "DeleteTAResponse":{ 4672 "payload":" 4673 ew0KCSJEZWxldGVUQVRCU1Jlc3BvbnNlIjogew0KCQkidmVyIjogIjEuMCIsDQoJCSJz 4674 dGF0dXMiOiAicGFzcyIsDQoJCSJyaWQiOiAicmVxLTIiLA0KCQkidGlkIjogInRyYW4t 4675 MDEiLA0KCQkiY29udGVudCI6IHsNCgkJCSJwcm90ZWN0ZWQiOnsiZW5jIjoiQTEyOENC 4676 Qy1IUzI1NiJ9LA0KCQkJInJlY2lwaWVudHMiOlsNCgkJCQl7DQoJCQkJCSJoZWFkZXIi 4677 OnsiYWxnIjoiUlNBMV81In0sDQoJCQkJCSJlbmNyeXB0ZWRfa2V5IjoiTXdtU1ZHaWU2 4678 eHpfQmxTaFlmTFRKRHhKT3oyNWhvYy1HZ2NEM2o5OWFyM2E4X2lYY182ZE44bFRTb1dD 4679 X19wZEFhaEMyWk5SakdIcTBCZ2JDYTRKalk0eXRkMVBVWDB6M1psbXl1YnRXM291eEpY 4680 el9PMzg1WGM4S3hySndjbElyZGx2WUY2OVZmeERLQkVzUHJCdzlVenVIa1VmSU4xWlFU 4681 bWZ0QmVaSlJnIg0KCQkJCX0NCgkJCV0sDQoJCQkiaXYiOiJBeFk4REN0RGFHbHNiR2xq 4682 YjNSb1pRIiwNCgkJCSJjaXBoZXJ0ZXh0IjoiamhQTlV5ZkFTel9rVV9GbEM2LUtCME01 4683 WDBHNE5MbHc0LWt0bERyajZTWlUteUp6eUFUbC1oY0ZBWWMwLXJMVEF4cF93N1d1WER0 4684 Y3N3SzJSSzRjcWciLA0KCQkJInRhZyI6IlBBeGo5N25oT29qVTNIREhxSll4MGZMNWpt 4685 b0xkTlJkTHRtSmIzUTdrYXciDQoJCX0NCgl9DQp9", 4686 "protected": "eyJhbGciOiJSUzI1NiJ9", 4687 "header": { 4688 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4689 "signer":" 4690 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJ 4691 BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp 4692 Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcN 4693 MTUwNzAyMDkwMTE4WhcNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzET 4694 MBEGA1UECAwKQ2FsaWZvcm5pYTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8G 4695 A1UECgwYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIGfMA0GCSqGSIb3DQEB 4696 AQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4697 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4698 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA 4699 6b_ZI3c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4700 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJ 4701 BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp 4702 Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX 4703 9nxZBNQWDjAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8E 4704 DDAKBggrBgEFBQcDAzANBgkqhkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4iv 4705 em4cIckfxzTBBiPHCjrrjB2X8Ktn8GSZ1MdyIZV8fwdEmD90IvtMHgtzK- 4706 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fV 4707 rJvnYAUBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4708 }, 4709 "signature":" 4710 DfoBOetNelKsnAe_m4Z9K5UbihgWNYZsp5jVybiI05sOagDzv6R4do9npaAlAvpNK8HJ 4711 CxD6D22J8GDUExlIhSR1aDuDCQm6QzmjdkFdxAz5TRYl6zpPCZqgSToN_g1TZxqxEv6V 4712 Ob5fies4g6MHvCH-Il_-KbHq5YpwGxEEFdg" 4713 } 4714 } 4715 Authors' Addresses 4717 Mingliang Pei 4718 Symantec 4719 350 Ellis St 4720 Mountain View, CA 94043 4721 USA 4723 Email: mpei@yahoo.com 4725 Nick Cook 4726 Intercede 4727 St. Mary's Road, Lutterworth 4728 Leicestershire, LE17 4PS 4729 Great Britain 4731 Email: nick.cook@intercede.com 4733 Minho Yoo 4734 Solacia 4735 5F, Daerung Post Tower 2, 306 Digital-ro 4736 Seoul 152-790 4737 Korea 4739 Email: paromix@sola-cia.com 4741 Andrew Atyeo 4742 Intercede 4743 St. Mary's Road, Lutterworth 4744 Leicestershire, LE17 4PS 4745 Great Britain 4747 Email: andrew.atyeo@intercede.com 4749 Hannes Tschofenig 4750 ARM Ltd. 4751 110 Fulbourn Rd 4752 Cambridge, CB1 9NJ 4753 Great Britain 4755 Email: Hannes.tschofenig@arm.com