idnits 2.17.1 draft-pei-opentrustprotocol-05.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 933 has weird spacing: '...cluding the r...' -- The document date (January 14, 2018) is 2294 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CA' is mentioned on line 586, but not defined == Missing Reference: 'Soc' is mentioned on line 588, but not defined == Missing Reference: 'OEM' is mentioned on line 600, but not defined Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Pei 3 Internet-Draft Symantec 4 Intended status: Informational N. Cook 5 Expires: July 18, 2018 ARM Ltd. 6 M. Yoo 7 Solacia 8 A. Atyeo 9 Intercede 10 H. Tschofenig 11 ARM Ltd. 12 January 14, 2018 14 The Open Trust Protocol (OTrP) 15 draft-pei-opentrustprotocol-05.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 July 18, 2018. 46 Copyright Notice 48 Copyright (c) 2018 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 . . . . . . . . . 15 77 5.4. SD Owner Identification and TSM Certificate Requirements 16 78 5.5. Service Provider Container . . . . . . . . . . . . . . . 16 79 6. OTrP Agent . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 6.1. Role of OTrP Agent . . . . . . . . . . . . . . . . . . . 17 81 6.2. OTrP Agent and Global Platform TEE Client API . . . . . . 18 82 6.3. OTrP Agent Implementation Consideration . . . . . . . . . 18 83 6.3.1. OTrP Agent Distribution . . . . . . . . . . . . . . . 18 84 6.3.2. Number of OTrP Agent . . . . . . . . . . . . . . . . 18 85 6.3.3. OTrP Android Service Option . . . . . . . . . . . . . 19 86 6.4. OTrP Agent API for Client Applications . . . . . . . . . 19 87 6.4.1. API processMessage . . . . . . . . . . . . . . . . . 19 88 6.4.2. API getTAInformation . . . . . . . . . . . . . . . . 20 89 6.5. Sample End-to-End Client Application Flow . . . . . . . . 22 90 6.5.1. Case 1: A New Client Application Uses a TA . . . . . 22 91 6.5.2. Case 2: A Previously Installed Client Application 92 Calls a TA . . . . . . . . . . . . . . . . . . . . . 24 93 7. OTrP Messages . . . . . . . . . . . . . . . . . . . . . . . . 25 94 7.1. Message Format . . . . . . . . . . . . . . . . . . . . . 25 95 7.2. Message Naming Convention . . . . . . . . . . . . . . . . 25 96 7.3. Request and Response Message Template . . . . . . . . . . 26 97 7.4. Signed Request and Response Message Structure . . . . . . 26 98 7.4.1. Identifying Signing and Encryption Keys for JWS/JWE 99 Messaging . . . . . . . . . . . . . . . . . . . . . . 28 100 7.5. JSON Signing and Encryption Algorithms . . . . . . . . . 28 101 7.5.1. Supported JSON Signing Algorithms . . . . . . . . . . 30 102 7.5.2. Support JSON Encryption Algorithms . . . . . . . . . 30 103 7.5.3. Supported JSON Key Management Algorithms . . . . . . 30 104 7.6. Common Errors . . . . . . . . . . . . . . . . . . . . . . 31 105 7.7. OTrP Message List . . . . . . . . . . . . . . . . . . . . 31 106 7.8. OTrP Request Message Routing Rules . . . . . . . . . . . 32 107 7.8.1. SP Anonymous Attestation Key (SP AIK) . . . . . . . . 32 108 8. Detailed Messages Specification . . . . . . . . . . . . . . . 32 109 8.1. GetDeviceState . . . . . . . . . . . . . . . . . . . . . 33 110 8.1.1. GetDeviceStateRequest message . . . . . . . . . . . . 33 111 8.1.2. Request processing requirements at a TEE . . . . . . 34 112 8.1.3. Firmware Signed Data . . . . . . . . . . . . . . . . 35 113 8.1.3.1. Supported Firmware Signature Methods . . . . . . 35 114 8.1.4. Post Conditions . . . . . . . . . . . . . . . . . . . 36 115 8.1.5. GetDeviceStateResponse Message . . . . . . . . . . . 36 116 8.1.6. Error Conditions . . . . . . . . . . . . . . . . . . 40 117 8.1.7. TSM Processing Requirements . . . . . . . . . . . . . 41 118 8.2. Security Domain Management . . . . . . . . . . . . . . . 42 119 8.2.1. CreateSD . . . . . . . . . . . . . . . . . . . . . . 42 120 8.2.1.1. CreateSDRequest Message . . . . . . . . . . . . . 42 121 8.2.1.2. Request Processing Requirements at a TEE . . . . 45 122 8.2.1.3. CreateSDResponse Message . . . . . . . . . . . . 46 123 8.2.1.4. Error Conditions . . . . . . . . . . . . . . . . 47 124 8.2.2. UpdateSD . . . . . . . . . . . . . . . . . . . . . . 48 125 8.2.2.1. UpdateSDRequest Message . . . . . . . . . . . . . 48 126 8.2.2.2. Request Processing Requirements at a TEE . . . . 51 127 8.2.2.3. UpdateSDResponse Message . . . . . . . . . . . . 53 128 8.2.2.4. Error Conditions . . . . . . . . . . . . . . . . 54 129 8.2.3. DeleteSD . . . . . . . . . . . . . . . . . . . . . . 55 130 8.2.3.1. DeleteSDRequest Message . . . . . . . . . . . . . 55 131 8.2.3.2. Request Processing Requirements at a TEE . . . . 57 132 8.2.3.3. DeleteSDResponse Message . . . . . . . . . . . . 58 133 8.2.3.4. Error Conditions . . . . . . . . . . . . . . . . 60 134 8.3. Trusted Application Management . . . . . . . . . . . . . 60 135 8.3.1. InstallTA . . . . . . . . . . . . . . . . . . . . . . 60 136 8.3.1.1. InstallTARequest Message . . . . . . . . . . . . 62 137 8.3.1.2. InstallTAResponse Message . . . . . . . . . . . . 64 138 8.3.1.3. Error Conditions . . . . . . . . . . . . . . . . 65 139 8.3.2. UpdateTA . . . . . . . . . . . . . . . . . . . . . . 65 140 8.3.2.1. UpdateTARequest Message . . . . . . . . . . . . . 67 141 8.3.2.2. UpdateTAResponse Message . . . . . . . . . . . . 68 142 8.3.2.3. Error Conditions . . . . . . . . . . . . . . . . 70 143 8.3.3. DeleteTA . . . . . . . . . . . . . . . . . . . . . . 70 144 8.3.3.1. DeleteTARequest Message . . . . . . . . . . . . . 70 145 8.3.3.2. Request Processing Requirements at a TEE . . . . 72 146 8.3.3.3. DeleteTAResponse Message . . . . . . . . . . . . 73 147 8.3.3.4. Error Conditions . . . . . . . . . . . . . . . . 74 148 9. Response Messages a TSM May Expect . . . . . . . . . . . . . 74 149 10. Basic Protocol Profile . . . . . . . . . . . . . . . . . . . 75 150 11. Attestation Implementation Consideration . . . . . . . . . . 76 151 11.1. OTrP Secure Boot Module . . . . . . . . . . . . . . . . 76 152 11.1.1. Attestation signer . . . . . . . . . . . . . . . . . 76 153 11.1.2. SBM Initial Requirements . . . . . . . . . . . . . . 76 154 11.2. TEE Loading . . . . . . . . . . . . . . . . . . . . . . 77 155 11.3. Attestation Hierarchy . . . . . . . . . . . . . . . . . 77 156 11.3.1. Attestation Hierarchy Establishment: Manufacture . . 78 157 11.3.2. Attestation Hierarchy Establishment: Device Boot . . 78 158 11.3.3. Attestation Hierarchy Establishment: TSM . . . . . . 78 159 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78 160 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 79 161 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79 162 14.1. Error Code List . . . . . . . . . . . . . . . . . . . . 79 163 15. Security Consideration . . . . . . . . . . . . . . . . . . . 80 164 15.1. Cryptographic Strength . . . . . . . . . . . . . . . . . 81 165 15.2. Message Security . . . . . . . . . . . . . . . . . . . . 81 166 15.3. TEE Attestation . . . . . . . . . . . . . . . . . . . . 81 167 15.4. TA Protection . . . . . . . . . . . . . . . . . . . . . 82 168 15.5. TA Personalization Data . . . . . . . . . . . . . . . . 82 169 15.6. TA Trust Check at TEE . . . . . . . . . . . . . . . . . 82 170 15.7. One TA Multiple SP Case . . . . . . . . . . . . . . . . 83 171 15.8. OTrP Agent Trust Model . . . . . . . . . . . . . . . . . 83 172 15.9. OCSP Stapling Data for TSM Signed Messages . . . . . . . 83 173 15.10. Data Protection at TSM and TEE . . . . . . . . . . . . . 84 174 15.11. Privacy Consideration . . . . . . . . . . . . . . . . . 84 175 15.12. Threat Mitigation . . . . . . . . . . . . . . . . . . . 84 176 15.13. Compromised CA . . . . . . . . . . . . . . . . . . . . . 85 177 15.14. Compromised TSM . . . . . . . . . . . . . . . . . . . . 85 178 15.15. Certificate Renewal . . . . . . . . . . . . . . . . . . 85 179 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 85 180 16.1. Normative References . . . . . . . . . . . . . . . . . . 85 181 16.2. Informative References . . . . . . . . . . . . . . . . . 86 182 Appendix A. Sample Messages . . . . . . . . . . . . . . . . . . 86 183 A.1. Sample Security Domain Management Messages . . . . . . . 86 184 A.1.1. Sample GetDeviceState . . . . . . . . . . . . . . . . 86 185 A.1.1.1. Sample GetDeviceStateRequest . . . . . . . . . . 86 186 A.1.1.2. Sample GetDeviceStateResponse . . . . . . . . . . 87 187 A.1.2. Sample CreateSD . . . . . . . . . . . . . . . . . . . 90 188 A.1.2.1. Sample CreateSDRequest . . . . . . . . . . . . . 90 189 A.1.2.2. Sample CreateSDResponse . . . . . . . . . . . . . 93 191 A.1.3. Sample UpdateSD . . . . . . . . . . . . . . . . . . . 94 192 A.1.3.1. Sample UpdateSDRequest . . . . . . . . . . . . . 95 193 A.1.3.2. Sample UpdateSDResponse . . . . . . . . . . . . . 96 194 A.1.4. Sample DeleteSD . . . . . . . . . . . . . . . . . . . 96 195 A.1.4.1. Sample DeleteSDRequest . . . . . . . . . . . . . 96 196 A.1.4.2. Sample DeleteSDResponse . . . . . . . . . . . . . 98 197 A.2. Sample TA Management Messages . . . . . . . . . . . . . . 100 198 A.2.1. Sample InstallTA . . . . . . . . . . . . . . . . . . 100 199 A.2.1.1. Sample InstallTARequest . . . . . . . . . . . . . 100 200 A.2.1.2. Sample InstallTAResponse . . . . . . . . . . . . 101 201 A.2.2. Sample UpdateTA . . . . . . . . . . . . . . . . . . . 103 202 A.2.2.1. Sample UpdateTARequest . . . . . . . . . . . . . 103 203 A.2.2.2. Sample UpdateTAResponse . . . . . . . . . . . . . 104 204 A.2.3. Sample DeleteTA . . . . . . . . . . . . . . . . . . . 107 205 A.2.3.1. Sample DeleteTARequest . . . . . . . . . . . . . 107 206 A.2.3.2. Sample DeleteTAResponse . . . . . . . . . . . . . 109 207 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 111 209 1. Introduction 211 The Trusted Execution Environment (TEE) concept has been designed and 212 used to increase security by separating regular operating systems, 213 also referred as Rich Execution Environment (REE), from security- 214 sensitive applications. In an TEE ecosystem, a Trust Service Manager 215 (TSM) is used to authorize manage keys and the Trusted Applications 216 (TA) that run in a device. Different device vendors may use 217 different TEE implementations. Different application providers may 218 use different TSM providers. There arises a need of an open 219 interoperable protocol that allows trustworthy TSM to manage Security 220 Domains and contents running in different Trusted Execution 221 Environment (TEE) of various devices. 223 The Open Trust Protocol (OTrP) defines a protocol between a TSM and a 224 TEE and relies on IETF-defined end-to-end security mechanisms, namely 225 JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Key 226 (JWK). 228 This specification assumes that a device that utilizes this 229 specification is equipped with a TEE and is pre-provisioned with a 230 device-unique public/private key pair, which is securely stored. 231 This key pair is referred as the 'root of trust'. A Service Provider 232 (SP) uses such a device to run Trusted Applications (TA). 234 A security domain is defined as the TEE representation of a service 235 provider and is a logical space that contains the service provider's 236 Trusted Applications. Each security domain requires the management 237 operations of Trusted Applications (TAs) in the form of installation, 238 update and deletion. 240 The protocol builds on the following properties of the system: 242 1. The SP needs to determine security-relevant information of a 243 device before provisioning information to a TEE. Examples 244 include the verification of the root of trust, the type of 245 firmware installed, and the type of TEE included in a device. 247 2. A TEE in a device needs to determine whether a SP or the TSM is 248 authorized to manage applications in the TEE. 250 3. Secure Boot must be able to ensure a TEE is genuine. 252 This specification defines message payloads exchanged between devices 253 and a TSM but does not mandate a specific transport. The messages 254 are designed in anticipation of the use of the most common transport 255 methods such as HTTPS via a wired or wireless network between a 256 device and a remote TSM web service. 258 2. Requirements Language 260 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 261 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 262 document are to be interpreted as described in RFC 2119 [RFC2119]. 264 3. Terminology 266 3.1. Definitions 268 The definitions provided below are defined as used in this document. 269 The same terms may be defined differently in other documents. 271 Client Application: An application running on a rich OS, such as an 272 Android, Windows, or iOS application, provided by a SP. 274 Device: A physical piece of hardware that hosts symmetric key 275 cryptographic modules 277 OTrP Agent: An application running in the rich OS allowing 278 communication with the TSM and the TEE. 280 Rich Application: Alternative name of "Client Application". In this 281 document we may use these two terms interchangably. 283 Rich Execution Environment (REE) An environment that is provided and 284 governed by a rich OS, potentially in conjunction with other 285 supporting operating systems and hypervisors; it is outside of 286 the TEE. This environment and applications running on it are 287 considered un-trusted. 289 Secure Boot Module (SBM): A firmware in a device that delivers 290 secure boot functionality. It is also referred as Trusted 291 Firmware (TFW) in this document. 293 Service Provider (SP): An entity that wishes to supply Trusted 294 Applications to remote devices. A Service Provider requires the 295 help of a TSM in order to provision the Trusted Applications to 296 the devices. 298 Trust Anchor: A root certificate that a module trusts. It is 299 usually embedded in one validating module, and used to validate 300 the trust of a remote entity's certificate. 302 Trusted Application (TA): Application that runs in TEE. 304 Trusted Execution Environment (TEE): An execution environment that 305 runs alongside but isolated from an REE. A TEE has security 306 capabilities and meets certain security-related requirements: It 307 protects TEE assets from general software attacks, defines rigid 308 safeguards as to data and functions that a program can access, 309 and resists a set of defined threats. There are multiple 310 technologies that can be used to implement a TEE, and the level 311 of security achieved varies accordingly. 313 3.2. Abbreviations 315 CA Certificate Authority 317 OTrP Open Trust Protocol 318 REE Rich Execution Environment 320 SD Security Domain 322 SP Service Provider 324 SBM Secure Boot Module 326 TA Trusted Application 328 TEE Trusted Execution Environment 330 TFW Trusted Firmware 332 TSM Trusted Service Manager 334 4. OTrP Entities and Trust Model 336 4.1. System Components 338 There are the following main components in this OTrP system. 340 TSM: The TSM is responsible for originating and coordinating 341 lifecycle management activity on a particular TEE. 343 A Trust Service Manager (TSM) is at the core to the protocol that 344 manages device trust check on behalf of service providers for the 345 ecosystem scalability. In addition to its device trust 346 management for a service provider, the TSM provides Security 347 Domain management and TA management in a device, in particularly, 348 over-the-air update to keep Trusted Applications up to date and 349 clean up when a version should be removed. 351 In the context of this specification, the term Trusted 352 Application Manager (TAM) and TSM are synonymous. 354 Certificate Authority (CA): Mutual trust between a device and a TSM 355 as well as a Service Provider is based on certificates. A device 356 embeds a list of root certificates, called Trust Anchors, from 357 trusted Certificate Authorities that a TSM will be validated 358 against. A TSM will remotely attest a device by checking whether 359 a device comes with a certificate from a trusted CA. 361 TEE: The TEE resides in the device chip security zone and is 362 responsible for protecting applications from attack, enabling the 363 application to perform secure operations 365 REE: The REE, usually called device OS such as Android OS in a phone 366 device, is responsible for enabling off device communications to 367 be established between the TEE and TSM. OTrP does not require 368 the device OS to be secure. 370 OTrP Agent: An application in the REE that can relay messages 371 between a Client Application and TEE. 373 Secure Boot: Secure boot (for the purposes of OTrP) must enable 374 authenticity checking of TEEs by the TSM. 376 The OTrP establishes appropriate trust anchors to enable TEE and TSMs 377 to communicate in a trusted way when performing lifecycle management 378 transactions. The main trust relationships between the components 379 are the following. 381 1. TSM must be able to ensure a TEE is genuine 383 2. TEE must be able to ensure a TSM is genuine 385 3. Secure Boot must be able to ensure a TEE is genuine 387 4.2. Trusted Anchors in TEE 389 The TEE in each device comes with a trust store that contains a 390 whitelist of TSM's root CA certificates, which are called Trust 391 Anchors. A TSM will be trusted to manage Security Domains and TAs in 392 a device only if its certificate is chained to one of the root CA 393 certificates in this trust store. 395 Such a list is typically embedded in TEE of a device, and the list 396 update is enabled and handled by device OEM provider. 398 4.3. Trusted Anchors in TSM 400 The Trust Anchor set in a TSM consists of a list of Certificate 401 Authority certificates that signs various device TEE certificates. A 402 TSM decides what TEE and TFW it will trust. 404 4.4. Keys and Cerificate Types 406 OTrP Protocol leverages the following list of trust anchors and 407 identities in generating signed and encrypted command messages that 408 are exchanged between a device with TEE and a TSM. With these 409 security artifacts, OTrP Messages are able to deliver end-to-end 410 security without relying on any transport security. 412 +-------------+----------+--------+-------------------+-------------+ 413 | Key Entity | Location | Issuer | Trust Implication | Cardinality | 414 | Name | | | | | 415 +-------------+----------+--------+-------------------+-------------+ 416 | 1. TFW | Device | OEM CA | A white list of | 1 per | 417 | keypair and | secure | | FW root CA | device | 418 | Certificate | storage | | trusted by TSMs | | 419 | | | | | | 420 | 2. TEE | Device | TEE CA | A white list of | 1 per | 421 | keypair and | TEE | under | TEE root CA | device | 422 | Certificate | | a root | trusted by TSMs | | 423 | | | CA | | | 424 | | | | | | 425 | 3. TSM | TSM | TSM CA | A white list of | 1 or | 426 | keypair and | provider | under | TSM root CA | multiple | 427 | Certificate | | a root | embedded in TEE | can be used | 428 | | | CA | | by a TSM | 429 | | | | | | 430 | 4. SP | SP | SP | TSM manages SP. | 1 or | 431 | keypair and | | signer | TA trust is | multiple | 432 | Certificate | | CA | delegated to TSM. | can be used | 433 | | | | TEE trusts TSM to | by a TSM | 434 | | | | ensure that a TA | | 435 | | | | is trustworthy. | | 436 +-------------+----------+--------+-------------------+-------------+ 438 Table 1: Key and Certificate Types 440 1. TFW keypair and Certificate: A key pair and certificate for 441 evidence of secure boot and trustworthy firmware in a device. 443 Location: Device secure storage 445 Supported Key Type: RSA and ECC 447 Issuer: OEM CA 449 Trust Implication: A white list of FW root CA trusted by TSMs 451 Cardinality: One per device 453 2. TEE keypair and Certificate: It is used for device attestation 454 to remote TSM and SP. 456 This key pair is burned into the device at device manufacturer. 457 The key pair and its certificate are valid for the expected 458 lifetime of the device. 460 Location: Device TEE 462 Supported Key Type: RSA and ECC 464 Issuer: TEE CA that chains to a root CA 466 Trust Implication: A white list of TEE root CA trusted by TSMs 468 Cardinality: One per device 470 3. TSM keypair and Certificate: A TSM provider acquires a 471 certificate from a CA that a TEE trusts. 473 Location: TSM provider 475 Supported Key Type: RSA and ECC. 477 Supported Key Size: RSA 2048-bit, ECC P-256 and P-384. 479 Issuer: TSM CA that chains to a root CA 481 Trust Implication: A white list of TSM root CA embedded in TEE 483 Cardinality: One or multiple can be used by a TSM 485 4. SP keypair and Certificate: A SP uses its own key pair and 486 certificate to sign a TA. 488 Location: SP 490 Supported Key Type: RSA and ECC 492 Supported Key Size: RSA 2048-bit, ECC P-256 and P-384 494 Issuer: SP signer CA that chains to a root CA 496 Trust Implication: TSM manages SP. TA trust is delegated to 497 TSM. TEE trusts TSM to ensure that a TA is trustworthy. 499 Cardinality: One or multiple can be used by a SP 501 5. Protocol Scope and Entity Relations 503 This document specifies the minimally required interoperable 504 artifacts to establish mutual trust between a TEE and TSM. The 505 protocol provides specifications for the following three entities: 507 1. Key and certificate types required for device firmware, TEE, TA, 508 SP, and TSM 510 2. Data message formats that should be exchanged between a TEE in a 511 device and a TSM 513 3. An OTrP Agent application in the REE that can relay messages 514 between a Client Application and TEE 516 Figure 1: Protocol Scope and Entity Relationship 518 PKI CA --CA CA-- 519 | | | 520 | | | 521 | | | 522 Device | | ----OTrP Agent --- Rich App --- | 523 SW | | | | | 524 | | | | | 525 | | | | | 526 OTrP | -- TEE TSM------- 527 | 528 | 529 FW 531 Figure 2: OTrP System Diagram 532 ---OTrP Message Protocol-- 533 | | 534 | | 535 -------------------- --------------- ---------- 536 | REE | TEE | | TSM | | SP | 537 | --- | --- | | --- | | -- | 538 | | | | | | | 539 | Client | SD (TAs)| | SD / TA | | TA | 540 | Apps | | | Mgmt | | | 541 | | | | | | | | 542 | | | | | | | | 543 | OTrP | Trusted | | Trusted | | | 544 | Agent | CAs | | FW, TEE CAs | | | 545 | | | | | | | 546 | |TEE Key/ | | TSM Key/ | |SP Key/ | 547 | | Cert | | Cert | | Cert | 548 | | FW Key/ | | | | | 549 | | Cert | | | | | 550 ------------------ --------------- ---------- 551 | | | 552 | | | 553 ----------------------------------------- 554 | 555 | 556 -------------- 557 | CA | 558 -------------- 560 In the previous diagram, different Certificate Authorities can be 561 used respectively for different types of certificates. OTrP Messages 562 are always signed, where the signer keys is the message creator's key 563 pair such as a FW key pair, TEE key pair or TSM key pair. 565 The main OTrP Protocol component is the set of standard JSON messages 566 created by TSM to deliver device SD and TA management commands to a 567 device, and device attestation and response messages created by TEE 568 to respond to TSM OTrP Messages. 570 The communication method of OTrP Messages between a TSM and TEE in a 571 device is left to TSM providers for maximal interoperability. A TSM 572 can work with its SP and Client Applications how it gets OTrP 573 Messages from a TSM. When a Client Application has had an OTrP 574 Message from its TSM, it is imperative to have an interoperable 575 interface to communicate with various TEE types. This is the OTrP 576 Agent interface that serves this purpose. The OTrP Agent doesn't 577 need to know the actual content of OTrP Messages except for the TEE 578 routing information. 580 5.1. A Sample Device Setup Flow 582 Step 1: Prepare Images for Devices 584 1. [TEE vendor] Deliver TEE Image (CODE Binary) 586 2. [CA] Deliver root CA Whitelist 588 3. [Soc] Deliver TFW Image 590 Step 2: Inject Key Pairs and Images to Devices 592 1. [OEM] Generate Secure Boot Key Pair (May be shared among multiple 593 devices) 595 2. [OEM] Flash signed TFW Image and signed TEE Image onto devices 596 (signed by Secure Boot Key) 598 Step 3: Setup attestation key pair in devices 600 1. [OEM] Flash Secure Boot Public Key and eFuse Key (eFuse key is 601 unique per device) 603 2. [TFW/TEE] Generate a unique attestation key pair and get a 604 certificate for the device. 606 Step 4: Setup trust anchors in devices 608 1. [TFW/TEE] Store the key and certificate encrypted with the eFuse 609 key 611 2. [TEE vendor or OEM] Store trusted CA certificate list into 612 devices 614 5.2. Derived Keys in The Protocol 616 The protocol generates the following two key pairs in run time to 617 assist message communication and anonymous verification between TSM 618 and TEE. 620 1. TEE Anonymous Key (TEE AIK): one derived key pair per TEE in a 621 device 623 The purpose of the key pair is to sign data by a TEE without using 624 its TEE device key for anonymous attestation to a Client Application. 625 This key is generated in the first GetDeviceState query. The public 626 key of the key pair is returned to the caller Client Application for 627 future TEE returned data validation. 629 2. TEE SP AIK: one derived key per SP in a device 631 The purpose of this key pair is for a TSM to encrypt TA binary data 632 when it sends a TA to a device for installation. This key is 633 generated in the first SD creation for a SP. It is deleted when all 634 SDs are removed for a SP in a device. 636 With the presence of a TEE SP AIK, it isn't necessary to have a 637 shared SP independent TEE AIK. For the initial release, this 638 specification will not use TEE AIK. 640 5.3. Security Domain Hierarchy and Ownership 642 The primary job of a TSM is to help a SP to manage its trusted 643 applications. A TA is typically installed in a SD. A SD is commonly 644 created for a SP. 646 When a SP delegates its SD and TA management to a TSM, a SD is 647 created on behalf of a TSM in a TEE and the owner of the SD is 648 assigned to the TSM. A SD may be associated with a SP but the TSM 649 has full privilege to manage the SD for the SP. 651 Each SD for a SP is associated with only one TSM. When a SP changes 652 TSM, a new SP SD must be created to associate with the new TSM. TEE 653 will maintain a registry of TSM ID and SP SD ID mapping. 655 From a SD ownership perspective SD tree is flat and there is only one 656 level. A SD is associated with its owner. It is up to TEE's 657 implementation how it maintains SD binding information for TSM and 658 different SPs under the same TSM. 660 It is an important decision in this protocol specification that a TEE 661 doesn't need to know whether a TSM is authorized to manage SD for a 662 SP. This authorization is implicitly triggered by a SP Client 663 Application, which instructs what TSM it wants to use. A SD is 664 always associated with a TSM in addition to its SP ID. A rogue TSM 665 isn't able to do anything on an unauthorized SP's SD managed by 666 another TSM. 668 Since a TSM may support multiple SPs, sharing the same SD name for 669 different SP creates a dependency in deleting a SD. A SD can be 670 deleted only after all TAs associated with this SD is deleted. A SP 671 cannot delete a Security Domain on its own with a TSM if a TSM 672 decides to introduce such sharing. There are cases where multiple 673 virtual SPs belong to the same organization, and a TSM chooses to use 674 the same SD name for those SPs. This is totally up to the TSM 675 implementation and out of scope of this specification. 677 5.4. SD Owner Identification and TSM Certificate Requirements 679 There is a need of cryptographically binding proof about the owner of 680 a SD in device. When a SD is created on behalf of a TSM, a future 681 request from the TSM must present itself as a way that the TEE can 682 verify it is the true owner. The certificate itself cannot reliably 683 used as the owner because TSM may change its certificate. 685 To this end, each TSM will be associated with a trusted identifier 686 defined as an attribute in the TSM certificate. This field is kept 687 the same when the TSM renew its certificates. A TSM CA is 688 responsible to vet the requested TSM attribute value. 690 This identifier value must not collide among different TSM providers, 691 and one TSM shouldn't be able to claim the identifier used by another 692 TSM provider. 694 The certificate extension name to carry the identifier can initially 695 use SubjectAltName:registeredID. A dedicated new extension name may 696 be registered later. 698 One common choice of the identifier value is the TSM's service URL. 699 A CA can verify the domain ownership of the URL with the TSM in the 700 certificate enrollment process. 702 TEE can assign this certificate attribute value as the TSM owner ID 703 for the SDs that are created for the TSM. 705 An alternative way to represent a SD ownership by a TSM is to have a 706 unique secret key upon SD creation such that only the creator TSM is 707 able to produce a Proof-of-Possession (POP) data with the secret. 709 5.5. Service Provider Container 711 A sample Security Domain hierarchy for the TEE is shown below. 713 ---------- 714 | TEE | 715 ---------- 716 | 717 | --------------- 718 |----------| SP1 Root SD | 719 | --------------- 720 | | 721 | | -------------- 722 | |----------| SP1 Sub SD | 723 | | -------------- 724 | | -------------- 725 | |----------| SP1 Sub SD | 726 | -------------- 727 | --------------- 728 |----------| SP2 Root SD | 729 --------------- 731 The OTrP assumes that a SP managed by TSM1 cannot be managed by TSM2. 732 Explicit permission grant should happen. SP can authorize TSM. 734 6. OTrP Agent 736 OTrP Agent is an Rich Application or SDK that facilitates 737 communication between a TSM and TEE. It also provides interfaces for 738 TSM SDK or Client Applications to query and trigger TA installation 739 that the application needs to use. 741 This interface for Client Applications may be commonly an Android 742 service call. A Client Application interacts with a TSM, and turns 743 around to pass messages received from TSM to OTrP Agent. 745 In all cases, a Client Application needs to be able to identify an 746 OTrP Agent that it can use. 748 6.1. Role of OTrP Agent 750 OTrP Agent is responsible to communicate with TEE. It takes request 751 messages from an application. The input data is mostly from a TSM 752 that an application communicates. An application may also directly 753 call OTrP Agent for some TA query functions. 755 OTrP Agent may internally process a request from TSM. At least, it 756 needs to know where to route a message, e.g. TEE instance. It 757 doesn't need to process or verify message content. 759 OTrP Agent returns TEE / TFW generated response messages to the 760 caller. OTrP Agent isn't expected to handle any network connection 761 with an application or TSM. 763 OTrP Agent only needs to return an OTrP Agent error message if the 764 TEE is not reachable for some reason. Other errors are represented 765 as response messages returned from the TEE which will then be passed 766 to the TSM. 768 6.2. OTrP Agent and Global Platform TEE Client API 770 A Client Application may rely on Global Platform (GP) TEE API for TA 771 communication. OTrP may use the GP TEE Client API but it is internal 772 to OTrP implementation that converts given messages from TSM. More 773 details can be found at [GPTEE]. 775 6.3. OTrP Agent Implementation Consideration 777 A Provider should consider methods of distribution, scope and 778 concurrency on device and runtime options when implementing an OTrP 779 Agent. Several non-exhaustive options are discussed below. 780 Providers are encouraged to take advantage of the latest 781 communication and platform capabilities to offer the best user 782 experience. 784 6.3.1. OTrP Agent Distribution 786 OTrP Agent installation is commonly carried out at OEM time. A user 787 can dynamically download and install an OTrP Agent on-demand. 789 It is important to ensure a legitimate OTrP Agent is installed and 790 used. If an OTrP Agent is compromised it may send rogue messages to 791 TSM and TEE and introduce additional risks. 793 6.3.2. Number of OTrP Agent 795 We anticipate only one shared OTrP Agent instance in a device. The 796 device's TEE vendor will most probably supply one OTrP Agent. 797 Potentially we expect some open source. 799 With one shared OTrP Agent, the OTrP Agent provider is responsible to 800 allow multiple TSMs and TEE providers to achieve interoperability. 801 With a standard OTrP Agent interface, TSM can implement its own SDK 802 for its SP Client Applications to work with this OTrP Agent. 804 Multiple independent OTrP Agent providers can be used as long as they 805 have standard interface to a Client Application or TSM SDK. Only one 806 OTrP Agent is expected in a device. 808 OTrP Protocol MUST specify a standard way for applications to lookup 809 the active OTrP Agent instance in a device. 811 TSM providers are generally expected to provide SDK for SP 812 applications to interact with OTrP Agent for the TSM and TEE 813 interaction. 815 6.3.3. OTrP Android Service Option 817 OTrP Agent can be a bound service in Android with a service 818 registration ID that a Client Application can use. This option 819 allows a Client Application not to depend on any OTrP Agent SDK or 820 provider. 822 An OTrP Agent is responsible to detect and work with more than one 823 TEE if a device has more than one. In this version, there is only 824 one active TEE such that an OTrP Agent only needs to handle the 825 active TEE. 827 6.4. OTrP Agent API for Client Applications 829 A Client Application shall be responsible for relaying messages 830 between the OTrP agent and the TSM. 832 OTrP Agent APIs are defined below. An OTrP Agent in the form of an 833 Android bound service can take this to be the functionality it 834 provides via service call. The OTrP Agent implements this interface. 836 If a failure is occured during calling API, an error message 837 described in "Common Errors" section (see Section 7.6) will be 838 returned. 840 interface IOTrPAgentService { 841 String processMessage(String tsmInMsg) throws OTrPAgentException; 842 String getTAInformation(String spid, String taid) 843 throws OTrPAgentException; 844 } 846 public class OTrPAgentException extends Throwable { 847 private int errCode; 848 } 850 6.4.1. API processMessage 852 String processMessage(String tsmInMsg) throws OTrPAgentException; 854 Description 855 A Client Application will use this method of the OTrP Agent in a 856 device to pass OTrP messages from a TSM. The method is 857 responsible for interation with the TEE and for forwarding the 858 input message to the TEE. It also returns TEE generated response 859 message back to the Client Application. 861 Input 863 tsmInMsg - OTrP message generated in a TSM that is passed to this 864 method from a Client Application. 866 Output 868 A TEE generated OTrP response message (which may be a successful 869 response or be a response message containing an error raised 870 within the TEE) for the client application to forward to the TSM. 871 In the event of the OTrP agent not being able to communicate with 872 the TEE, a OTrPAgentException shall be thrown. 874 6.4.2. API getTAInformation 876 String getTAInformation(String spid, String taid) 877 throws OTrPAgentException; 879 Description 881 A Client Application calls this method to query a TA's 882 information. This method is carried out locally by the OTrP Agent 883 without relying on a TSM if it has had the TEE SP AIK. 885 Input 887 spid - SP identifier of the TA 889 taid - the identifier of the TA 891 Output 893 The API returns TA signer and TSM signer certificate along with 894 other metadata information about a TA. 896 The output is a JSON message that is generated by the TEE. It 897 contains the following information: 899 * TSMID 901 * SP ID 902 * TA signer certificate 904 * TSM certificate 906 The message is signed with TEE SP AIK private key. 908 The Client Application is expected to consume the response as 909 follows. 911 The Client Application gets signed TA metadata, in particularly, 912 the TA signer certificate. It is able to verify that the result 913 is from device by checking signer against TEE SP AIK public key it 914 gets in some earlier interaction with TSM. 916 If this is a new Client Application in the device that hasn't had 917 TEE SP AIK public key for the response verification, the 918 application can contact TSM first to do GetDeviceState, and TSM 919 will return TEE SP AIK public key to the app for this operation to 920 proceed. 922 JSON Message 924 { 925 "TAInformationTBS": { 926 "taid": "", 927 "tsmid": "", 929 "spid": "", 930 "signercert": "", 932 "signercacerts": [ // the full list of CA certificate chain 933 // including the root CA 934 "cacert": "" 936 ], 937 "tsmcert": "", 939 "tsmcacerts": [ // the full list of CA certificate chain 940 // including the root CA 941 "cacert":"" 943 ] 944 } 945 } 947 { 948 "TAInformation": { 949 "payload": "", 951 "protected": "", 952 "header": { 953 "signer": {""} 955 }, 956 "signature": "" 958 } 959 } 961 A sample JWK public key representation refers to an example in RFC 962 7517 [RFC7517] . 964 6.5. Sample End-to-End Client Application Flow 966 6.5.1. Case 1: A New Client Application Uses a TA 968 1. During the Client Application installation time, the Client 969 Application calls TSM to initialize the device preparation step. 971 A. The Client Application knows it wants to use a Trusted 972 Application TA1 but the application doesn'tknow whether TA1 973 has been installed or not. It can use GP TEE Client API to 974 check the existence of TA1 first. If it detects that TA1 975 doesn't exist, it will contact TSM to initiate the 976 installation of TA1. Note that TA1 could have been 977 previously installed by other Client Applications from the 978 same service provider in the device. 980 B. The Client Application sends TSM the TA list that it depends 981 on. The TSM will query a device for the Security Domains 982 and TAs that have been installed, and instructs the device 983 to install any dependent TAs that have not been installed. 985 C. In general, TSM has the latest information of TA list and 986 their status in a device because all operations are 987 instructed by TSM. TSM has such visibility because all 988 Security Domain deletion and TA deletion are managed by TSM; 989 the TSM could have stored the state when a TA is installed, 990 updated and deleted. There is also the possibility that an 991 update command is carried out inside TEE but a response is 992 never received in TSM. There is also possibility that some 993 manual local reset is done in a device that the TSM isn't 994 aware of the changes. 996 2. TSM generates message: GetDeviceStateRequest 998 3. The Client Application passes the JSON message 999 GetDeviceStateRequest to OTrP Agent API processMessage. The 1000 communication between a Client Application and OTrP Agent is up 1001 to the implementation of OTrP Agent. 1003 4. OTrP Agent routes the message to the active TEE. Multiple TEE 1004 case: it is up to OTrP Agent to figure this out. This 1005 specification limits the support to only one active TEE, which 1006 is the typical case today. 1008 5. The target active TEE processes the received OTrP message, 1009 returns a JSON message GetDeviceStateResponse 1011 6. The OTrP Agent passes the GetDeviceStateResponse to the Client 1012 App 1014 7. The Client Application sends GetDeviceStateResponse to TSM 1016 8. TSM processes GetDeviceStateResponse 1017 A. Extract TEEspaik for the SP, signs TEEspaik with TSM signer 1018 key 1020 B. Examine SD list and TA list 1022 9. TSM continues to carry out other actions basing on the need. 1023 The next call could be instructing the device to install a 1024 dependent TA. 1026 A. Assume a dependent TA isn't in the device yet, the TSM may 1027 do the following: 1029 B. 1031 Create a SD to install the TA by sending a message 1032 CreateSDRequest. The message is sent back to the Client 1033 Application, and then OTrP Agent and TEE to process. 1035 Install a TA with a message InstallTARequest. 1037 C. If a Client Application depends on multiple TAs, the Client 1038 Application should expect multiple round trips of the TA 1039 installation message exchanges. 1041 10. At the last TSM and TEE operation, TSM returns the signed TEE SP 1042 AIK public key to the application 1044 11. The Client Application shall store the TEEspaik for future 1045 loaded TA trust check purpose. 1047 12. If the TSM finds that this is a fresh device that does not have 1048 any SD for the SP yet, then the TSM may move on to create a SD 1049 for the SP next. 1051 13. During Client Application installation, the application checks 1052 whether required Trusted Applications are already installed, 1053 which may have been provided by TEE. If needed, it will contact 1054 its TSM service to determine whether the device is ready or 1055 install TA list that this application needs. 1057 6.5.2. Case 2: A Previously Installed Client Application Calls a TA 1059 1. The Client Application checks the device readiness: (a) whether 1060 it has a TEE; (b) whether it has TA that it depends. It may 1061 happen that TSM has removed TA this application depends on. 1063 2. The Client Application calls OTrP Agent method "GetTAInformation" 1064 3. OTrP Agent queries the TEE to get TA information. If the given 1065 TA doesn't exist, an error is returned. 1067 4. The Client Application parses the TAInformation message. 1069 5. If the TA doesn't exist, the Client Application calls its TSM to 1070 install the TA. If the TA exists, the Client Application 1071 proceeds to call the TA. 1073 7. OTrP Messages 1075 The main OTrP Protocol component is the set of standard JSON messages 1076 created by TSM to deliver device SD and TA management commands to a 1077 device, and device attestation and response messages created by TEE 1078 to respond to TSM OTrP Messages. 1080 An OTrP Message is designed to provide end-to-end security. It is 1081 always signed by its creator. In addition, an OTrP Message is 1082 typically encrypted such that only the targeted device TEE or TSM 1083 provider is able to decrypt and view the actual content. 1085 7.1. Message Format 1087 OTrP Messages use JSON format for JSON's simple readability and 1088 moderate data size in comparison with alternative TLV and XML 1089 formats. 1091 JSON Message security has developed JSON Web Signing and JSON Web 1092 Encryption standard in the IETF Workgroup JOSE, see JWS [RFC7515] and 1093 JWE [RFC7516]. The OTrP Messages in this protocol will leverage the 1094 basic JWS and JWE to handle JSON signing and encryption. 1096 7.2. Message Naming Convention 1098 For each TSM command "xyz"", OTrP Protocol use the following naming 1099 convention to represent its raw message content and complete request 1100 and response messages: 1102 +-----------------------+----------------+---------------------+ 1103 | Purpose | Message Name | Example | 1104 +-----------------------+----------------+---------------------+ 1105 | Request to be signed | xyzTBSRequest | CreateSDTBSRequest | 1106 | | | | 1107 | Request message | xyzRequest | CreateSDRequest | 1108 | | | | 1109 | Response to be signed | xyzTBSResponse | CreateSDTBSResponse | 1110 | | | | 1111 | Response message | xyzResponse | CreateSDResponse | 1112 +-----------------------+----------------+---------------------+ 1114 7.3. Request and Response Message Template 1116 An OTrP Request message uses the following format: 1118 { 1119 "TBSRequest": { 1120 1121 } 1122 } 1124 A corresponding OTrP Response message will be as follows. 1126 { 1127 "TBSResponse": { 1128 1129 } 1130 } 1132 7.4. Signed Request and Response Message Structure 1134 A signed request message will generally include only one signature, 1135 and uses the flattened JWS JSON Serialization Syntax, see 1136 Section 7.2.2 in RFC7515 [RFC7515] . 1138 A general JWS object looks like the following. 1140 { 1141 "payload": "", 1142 "protected":"", 1143 "header": { 1144 , 1145 }, 1146 "signature":"" 1147 } 1148 OTrP signed messages only requires the signing algorithm as the 1149 mandate header in the property "protected". The "non-integrity- 1150 protected header contents" is optional. 1152 OTrP signed message will be given an explicit Request or Response 1153 property name. In other words, a signed Request or Response uses the 1154 following template. 1156 A general JWS object looks like the following. 1158 { 1159 "[Request | Response]": { 1160 TBS[Request | Response] 1161 } 1162 } 1164 With the standard JWS message format, a signed OTrP Message looks 1165 like the following. 1167 { 1168 "[Request | Response]": { 1169 "payload": "TBS[Request | Response]>", 1170 "protected":"", 1171 "header": , 1172 "signature":"" 1173 } 1174 } 1176 The top element " [Signed][Request | Response]" cannot be fully 1177 trusted to match the content because it doesn't participate the 1178 signature generation. However, a recipient can always match it with 1179 the value associated with the property "payload". It purely serves 1180 to provide a quick reference for reading and method invocation. 1182 Furthermore, most properties in an unsigned OTrP messages are 1183 encrypted to provide end-to-end confidentiality. The only OTrP 1184 message that isn't encrypted is the initial device query message that 1185 asks for the device state information. 1187 Thus a typical OTrP Message consists of an encrypted and then signed 1188 JSON message. Some transaction data such as transaction ID and TEE 1189 information may need to be exposed to OTrP Agent for routing purpose. 1190 Such information is excluded from JSON encryption. The device's 1191 signer certificate itself is encrypted. The overall final message is 1192 a standard signed JSON message. 1194 As required by JSW/JWE, those JWE and JWS related elements will be 1195 BASE64URL encoded. Other binary data elements specific to the OTrP 1196 specification are BASE64 encoded. This specification will identify 1197 elements that should be BASE64 and those elements that are to be 1198 BASE64URL encoded. 1200 7.4.1. Identifying Signing and Encryption Keys for JWS/JWE Messaging 1202 JWS and JWE messaging allow various options for identifying the 1203 signing and encryption keys, for example, it allows optional elements 1204 including "x5c", "x5t" and "kid" in the header to cover various 1205 possibilities. 1207 In order to protect privacy, it is important that the device's 1208 certificate is released only to a trusted TSM, and that it is 1209 encrypted. The TSM will need to know the device certificate, but 1210 untrusted parties must not be able to get the device certificate. 1211 All OTrP messaging conversations between a TSM and device begin with 1212 GetDeviceStateRequest / GetDeviceStateResponse. These messages have 1213 elements built into them to exchange signing certificates, described 1214 in the "Detailed Message Specification" section. Any subsequent 1215 messages in the conversation that follow on from this are implicitly 1216 using the same certificates for signing/encryption, and as a result 1217 the certificates or references may be ommitted in those subsequent 1218 messages. 1220 In other words, the signing key identifier in the use of JWS and JWE 1221 here may be absent in the subsequent messages after the initial 1222 GetDeviceState query. 1224 This has implication on the TEE and TSM implementation: they have to 1225 cache the signer certificates for the subsequent message signature 1226 validation in the session. It may be easier for a TSM service to 1227 cache transaction session information but not so for a TEE in a 1228 device. A TSM should check a device's capability to decide whether 1229 it should include its TSM signer certificate and OCSP data in each 1230 subsequent request message. The device's caching capability is 1231 reported in GetDeviceStateResponse signerreq parameter. 1233 7.5. JSON Signing and Encryption Algorithms 1235 The OTrP JSON signing algorithm shall use SHA256 or a stronger hash 1236 method with respective key type. JSON Web Algorithm RS256 or ES256 1237 [RFC7518] SHALL be used for RSA with SHA256 and ECDSA with SHA256. 1238 If RSA with SHA256 is used, the JSON web algorithm representation is 1239 as follows. 1241 {"alg":"RS256"} 1243 The (BASE64URL encoded) "protected" header property in a signed 1244 message looks like the following: 1246 "protected":"eyJhbGciOiJSUzI1NiJ9" 1248 If ECSDA with P-256 curve and SHA256 are used for signing, the JSON 1249 signing algorithm representation is as follows. 1251 {"alg":"ES256"} 1253 The value for the "protected" field will be the following. 1255 eyJhbGciOiJFUzI1NiJ9 1257 Thus a common OTrP signed message with ES256 looks like the 1258 following. 1260 { 1261 "payload": "", 1262 "protected": "eyJhbGciOiJFUzI1NiJ9", 1263 "signature":"" 1264 } 1266 The OTrP JSON message encryption algorithm should use one of the 1267 supported algorithms defined in the later chapter of this document. 1268 JSON encryption uses a symmetric key as its "Content Encryption Key 1269 (CEK)". This CEK is encrypted or wrapped by a recipient's key. OTrP 1270 recipient typically has an asymmetric key pair. Therefore CEK will 1271 be encrypted by the recipient's public key. 1273 Symmetric encryption shall use the following algorithm. 1275 {"enc":"A128CBC-HS256"} 1277 This algorithm represents encryption with AES 128 in CBC mode with 1278 HMAC SHA 256 for integrity. The value of the property "protected" in 1279 a JWE message will be 1281 eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0 1283 An encrypted JSON message looks like the following. 1285 { 1286 "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0", 1287 "recipients": [ 1288 { 1289 "header": { 1290 "alg": "" 1291 }, 1292 "encrypted_key": "" 1293 } 1294 ], 1295 "iv": "", 1296 "ciphertext": "", 1298 "tag": "" 1299 } 1301 OTrP doesn't use JWE AAD (Additional Authenticated Data) because each 1302 message is always signed after the message is encrypted. 1304 7.5.1. Supported JSON Signing Algorithms 1306 The following JSON signature algorithm are mandatory support in TEE 1307 and TSM: 1309 o RS256 1311 ES256 is optional to support. 1313 7.5.2. Support JSON Encryption Algorithms 1315 The following JSON authenticated encryption algorithm is mandatory 1316 support in TEE and TSM. 1318 o A128CBC-HS256 1320 A256CBC-HS512 is optional to support. 1322 7.5.3. Supported JSON Key Management Algorithms 1324 The following JSON key management algorithm is mandatory support in 1325 TEE and TSM. 1327 o RSA1_5 1329 ECDH-ES+A128KW and ECDH-ES+A256KW are optional to support. 1331 7.6. Common Errors 1333 An OTrP Response message typically needs to report operation status 1334 and error causes if an operation fails. The following JSON message 1335 elements should be used across all OTrP Messages. 1337 "status": "pass | fail" 1339 "reason": { 1340 "error-code": "", 1341 "error-message": "" 1342 } 1344 "ver": "" 1346 7.7. OTrP Message List 1348 The following table lists the OTrP commands and therefore 1349 corresponding Request and Response messages defined in this 1350 specification. Additional messages may be added in the future when 1351 new task messages are needed. 1353 GetDeviceState - 1354 A TSM queries a device's current state with a message 1355 GetDeviceStateRequest. A device TEE will report its version, its 1356 FW version, and list of all SD and TA in the device that is 1357 managed by the requesting TSM. TSM may determine whether the 1358 device is trustworthy and decide to carry out additional commands 1359 according to the response from this query. 1361 CreateSD - 1362 A TSM instructs a device TEE to create a SD for a SP. The 1363 recipient TEE will check whether the requesting TSM is 1364 trustworthy. 1366 UpdateSD - 1367 A TSM instructs a device TEE to update an existing SD. A typical 1368 update need comes from SP certificate change, TSM certificate 1369 change and so on. The recipient TEE will verify whether the TSM 1370 is trustworthy and owns the SD. 1372 DeleteSD - 1373 A TSM instructs a device TEE to delete an existing SD. A TEE 1374 conditionally deletes TAs loaded in the SD according to a request 1375 parameter. A SD cannot be deleted until all TAs in this SD are 1376 deleted. If this is the last SD for a SP, TEE can also delete 1377 TEE SP AIK key for this SP. 1379 InstallTA - 1380 A TSM instructs a device to install a TA into a SD for a SP. TEE 1381 in a device will check whether the TSM and TA are trustworthy. 1383 UpdateTA - 1384 A TSM instructs a device to update a TA into a SD for a SP. The 1385 change may commonly be bug fix for a previously installed TA. 1387 DeleteTA - 1388 A TSM instructs a device to delete a TA. TEE in a device will 1389 check whether the TSM and TA are trustworthy. 1391 7.8. OTrP Request Message Routing Rules 1393 For each command that a TSM wants to send to a device, the TSM 1394 generates a request message. This is typically triggered by a Client 1395 Application that uses the TSM. The Client Application initiates 1396 contact with the TSM and receives TSM OTrP Request messages according 1397 to the TSM's implementation. The Client Application forwards the 1398 OTrP message to an OTrP Agent in the device, which in turn sends the 1399 message to the active TEE in the device. 1401 The current version of specification assumes that each device has 1402 only one active TEE, and OTrP Agent is responsible to connect to the 1403 active TEE. This is the case today with devices in the market. 1405 Upon TEE responding with a request, the OTrP Agent gets OTrP response 1406 messages back to the Client Application that sends the request. In 1407 case the target TEE fails to respond the request, the OTrP Agent will 1408 be responsible to generate an error message to reply the Client 1409 Application. The Client Application forwards any data it received to 1410 its TSM. 1412 7.8.1. SP Anonymous Attestation Key (SP AIK) 1414 When the first new Security Domain is created in TEE for a SP, a new 1415 key pair is generated and associated with this SP. This key pair is 1416 used for future device attestation to the service provider instead of 1417 using device's TEE key pair. 1419 8. Detailed Messages Specification 1421 For each message in the following sections all JSON elements are 1422 mandatory if it isn't explicitly indicated as optional. 1424 8.1. GetDeviceState 1426 This is the first command that a TSM will query a device. This 1427 command is triggered when a SP's Client Application contacts its TSM 1428 to check whether the underlying device is ready for TA operations. 1430 This command queries a device's current TEE state. A device TEE will 1431 report its version, its FW version, and list of all SD and TA in the 1432 device that is managed by the requesting TSM. TSM may determine 1433 whether the device is trustworthy and decide to carry out additional 1434 commands according to the response from this query. 1436 The request message of this command is signed by TSM. The response 1437 message from TEE is encrypted. A random message encryption key (MK) 1438 is generated by TEE, and this encrypted key is encrypted by the 1439 receiving TSM public key such that only the TSM who sent the request 1440 is able to decrypt and view the response message. 1442 8.1.1. GetDeviceStateRequest message 1444 { 1445 "GetDeviceStateTBSRequest": { 1446 "ver": "1.0", 1447 "rid": "", 1448 "tid": "", 1449 "ocspdat": "", 1450 "icaocspdat": "", 1451 "supportedsigalgs": "" 1452 } 1453 } 1455 The request message consists of the following data elements: 1457 ver - version of the message format 1459 rid - a unique request ID generated by the TSM 1461 tid - a unique transaction ID to trace request and response. This 1462 can be from a prior transaction's tid field, and can be used in 1463 the subsequent message exchanges in this TSM session. The 1464 combination of rid and tid should be made unique. 1466 ocspdat - OCSP stapling data for the TSM certificate. The TSM 1467 provides OCSP data such that a recipient TEE can validate the 1468 validity of the TSM certificate without making its own external 1469 OCSP service call. This is a mandate field. 1471 icaocspdat - OCSP stapling data for the intermediate CA 1472 certificates of the TSM certificate up to the root. A TEE side 1473 can cache CA OCSP data such that this value isn't needed in each 1474 call. 1476 supportedsigalgs - an optional property to list the signing 1477 algorithms that TSM is able to support. A recipient TEE should 1478 choose algorithm in this list to sign its response message if 1479 this property is present in a request. 1481 The final request message is JSON signed message of the above raw 1482 JSON data with TSM's certificate. 1484 { 1485 "GetDeviceStateRequest": { 1486 "payload":"", 1488 "protected": "", 1489 "header": { 1490 "x5c": "" 1492 }, 1493 "signature":"" 1494 } 1495 } 1497 The signing algorithm should use SHA256 with respective key type. 1498 The mandatory algorithm support is the RSA signing algorithm. The 1499 signer header "x5c" is used to include the TSM signer certificate up 1500 to the root CA certificate. 1502 8.1.2. Request processing requirements at a TEE 1504 Upon receiving a request message GetDeviceStateRequest at a TEE, the 1505 TEE must validate a request: 1507 1. Validate JSON message signing 1509 2. Validate that the request TSM certificate is chained to a trusted 1510 CA that the TEE embeds as its trust anchor. 1512 * Cache the CA OCSP stapling data and certificate revocation 1513 check status for other subsequent requests. 1515 * A TEE can use its own clock time for the OCSP stapling data 1516 validation. 1518 3. Collect Firmware signed data 1519 * This is a capability in ARM architecture that allows a TEE to 1520 query Firmware to get FW signed data. 1522 4. Collect SD information for the SD owned by this TSM 1524 8.1.3. Firmware Signed Data 1526 Firmware isn't expected to process or produce JSON data. It is 1527 expected to just sign some raw bytes of data. 1529 The data to be signed by TFW key needs be some unique random data 1530 each time. The (UTF-8 encoded) "tid" value from the 1531 GetDeviceStateTBSRequest shall be signed by the firmware. TSM isn't 1532 expected to parse TFW data except the signature validation and signer 1533 trust path validation. 1535 It is possible that a TEE can get some valid TFW signed data from 1536 another device. This is part of the TEE trust assumption where TSM 1537 will trust the TFW data supplied by the TEE. The TFW trust is more 1538 concerned by TEE than a TSM where a TEE needs to ensure that the 1539 underlying device firmware is trustworthy. 1541 TfwData: { 1542 "tbs": "", 1543 "cert": "", 1544 "sigalg": "Signing method", 1545 "sig": "" 1546 } 1548 It is expected that FW use a standard signature methods for maximal 1549 interoperability with TSM providers. The mandatory support list of 1550 signing algorithm is RSA with SHA256. 1552 The JSON object above is constructed by TEE with data returned from 1553 FW. It isn't a standard JSON signed object. The signer information 1554 and data to be signed must be specially processed by TSM according to 1555 definition given here. The data to be signed is the raw data. 1557 8.1.3.1. Supported Firmware Signature Methods 1559 TSM providers shall support the following signature methods. A 1560 firmware provider can choose one of the methods in signature 1561 generation. 1563 o RSA with SHA256 1565 o ECDSA with SHA 256 1566 The value of "sigalg" in the TfwData JSON message should use one of 1567 the following: 1569 o RS256 1571 o ES256 1573 8.1.4. Post Conditions 1575 Upon successful request validation, the TEE information is collected. 1576 There is no change in the TEE in the device. 1578 The response message shall be encrypted where the encryption key 1579 shall be a symmetric key that is wrapped by TSM's public key. The 1580 JSON Content Encryption Key (CEK) is used for this purpose. 1582 8.1.5. GetDeviceStateResponse Message 1584 The message has the following structure. 1586 { 1587 "GetDeviceTEEStateTBSResponse": { 1588 "ver": "1.0", 1589 "status": "pass | fail", 1590 "rid": "", 1591 "tid": "", 1592 "signerreq": "true | false about whether TSM needs to send 1593 signer data again in subsequent messages", 1594 "edsi": "" 1595 } 1596 } 1598 where 1600 signerreq - true if the TSM should send its signer certificate and 1601 OCSP data again in the subsequent messages. The value may be 1602 "false" if the TEE caches the TSM's signer certificate and OCSP 1603 status. 1605 rid - the request ID from the request message 1607 tid - the tid from the request message 1609 edsi - the main data element whose value is JSON encrypted message 1610 over the following Device State Information (DSI). 1612 The Device State Information (DSI) message consists of the following. 1614 { 1615 "dsi": { 1616 "tfwdata": { 1617 "tbs": "" 1618 "cert": "", 1619 "sigalg": "Signing method", 1620 "sig": "" 1621 }, 1622 "tee": { 1623 "name": "", 1624 "ver": "", 1625 "cert": "", 1626 "cacert": "", 1628 "sdlist": { 1629 "cnt": "", 1630 "sd": [ 1631 { 1632 "name": "", 1633 "spid": "", 1634 "talist": [ 1635 { 1636 "taid": "", 1637 "taname": "" // optional 1639 } 1640 ] 1641 } 1642 ] 1643 }, 1644 "teeaiklist": [ 1645 { 1646 "spaik": "", 1647 "spaiktype": "", 1648 "spid": "" 1649 } 1650 ] 1651 } 1652 } 1653 } 1655 The encrypted JSON message looks like the following. 1657 { 1658 "protected": "", 1660 "recipients": [ 1661 { 1662 "header": { 1663 "alg": "RSA1_5" 1664 }, 1665 "encrypted_key": "" 1666 } 1667 ], 1668 "iv": "", 1669 "ciphertext": "", 1671 "tag": "" 1672 } 1674 Assume we encrypt plaintext with AES 128 in CBC mode with HMAC SHA 1675 256 for integrity, the encryption algorithm header is: 1677 {"enc":"A128CBC-HS256"} 1679 The value of the property "protected" in the above JWE message will 1680 be 1682 eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0 1684 In other words, the above message looks like the following: 1686 { 1687 "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0", 1688 "recipients": [ 1689 { 1690 "header": { 1691 "alg": "RSA1_5" 1692 }, 1693 "encrypted_key": "" 1694 } 1695 ], 1696 "iv": "", 1697 "ciphertext": "", 1699 "tag": "" 1700 } 1702 The full response message looks like the following: 1704 { 1705 "GetDeviceTEEStateTBSResponse": { 1706 "ver": "1.0", 1707 "status": "pass | fail", 1708 "rid": "", 1709 "tid": "", 1710 "signerreq": "true | false", 1711 "edsi": { 1712 "protected": "", 1714 "recipients": [ 1715 { 1716 "header": { 1717 "alg": "RSA1_5" 1718 }, 1719 "encrypted_key": "" 1720 } 1721 ], 1722 "iv": "", 1723 "ciphertext": "", 1725 "tag": "" 1726 } 1727 } 1728 } 1730 The CEK will be encrypted by the TSM public key in the device. The 1731 TEE signed message has the following structure. 1733 { 1734 "GetDeviceTEEStateResponse": { 1735 "payload": "", 1737 "protected": "", 1738 "signature": "" 1739 } 1740 } 1742 The signing algorithm shall use SHA256 with respective key type, see 1743 Section Section 7.5.1. 1745 The final response message GetDeviceStateResponse consists of array 1746 of TEE response. A typical device will have only one active TEE. An 1747 OTrP Agent is responsible to collect TEE response for all active TEEs 1748 in the future. 1750 { 1751 "GetDeviceStateResponse": [ // JSON array 1752 {"GetDeviceTEEStateResponse": ...}, 1753 ... 1754 {"GetDeviceTEEStateResponse": ...} 1755 ] 1756 } 1758 8.1.6. Error Conditions 1760 An error may occur if a request isn't valid or the TEE runs into some 1761 error. The list of possible error conditions is the following. 1763 ERR_REQUEST_INVALID The TEE meets the following conditions with a 1764 request message: (1) The request from a TSM has an invalid message 1765 structure; mandatory information is absent in the message. 1766 undefined member or structure is included. (2) TEE fails to verify 1767 signature of the message or fails to decrypt its contents. (3) etc. 1769 ERR_UNSUPPORTED_MSG_VERSION TEE receives the version of message that 1770 TEE can't deal with. 1772 ERR_UNSUPPORTED_CRYPTO_ALG TEE receives a request message encoded 1773 with cryptographic algorithms that TEE doesn't support. 1775 ERR_TFW_NOT_TRUSTED TEE may consider the underlying device firmware 1776 be not trustworthy. 1778 ERR_TSM_NOT_TRUSTED TEE needs to make sure whether the TSM is 1779 trustworthy by checking the validity of TSM certificate and OCSP 1780 stapling data and so on. If TEE finds TSM is not reliable, it may 1781 return this error code. 1783 ERR_TEE_FAIL TEE fails to respond to a TSM request. The OTrP Agent 1784 will construct an error message in responding the TSM's request. 1785 And also if TEE fails to process a request because of its internal 1786 error, it will return this error code. 1788 The response message will look like the following if the TEE signing 1789 can work to sign the error response message. 1791 { 1792 "GetDeviceTEEStateTBSResponse": { 1793 "ver": "1.0", 1794 "status": "fail", 1795 "rid": "", 1796 "tid": "", 1797 "reason": {"error-code":""} 1798 "supportedsigalgs": "" 1799 } 1800 } 1802 where 1804 supportedsigalgs - an optional property to list the JWS signing 1805 algorithms that the active TEE supports. When a TSM sends a 1806 signed message that the TEE isn't able to validate, it can 1807 include signature algorithms that it is able to consume in this 1808 status report. A TSM can generate a new request message to retry 1809 the management task with a TEE supported signing algorithm. 1811 If TEE isn't able to sign an error message, a general error message 1812 should be returned. 1814 8.1.7. TSM Processing Requirements 1816 Upon receiving a message of the type GetDeviceStateResponse at a TSM, 1817 the TSM should validate the following. 1819 o Parse to get list of GetDeviceTEEStateResponse JSON object 1821 o Parse the JSON "payload" property and decrypt the JSON element 1822 "edsi" 1824 o The decrypted message contains the TEE signer certificate 1826 o Validate GetDeviceTEEStateResponse JSON signature. The signer 1827 certificate is extracted from the decrypted message in the last 1828 step. 1830 o Extract TEE information and check it against its TEE acceptance 1831 policy. 1833 o Extract TFW signed element, and check the signer and data 1834 integration against its TFW policy 1836 o Check the SD list and TA list and prepare for a subsequent command 1837 such as "CreateSD" if it needs to have a new SD for a SP. 1839 8.2. Security Domain Management 1841 8.2.1. CreateSD 1843 This command is typically preceded with GetDeviceState command that 1844 has acquired the device information of the target device by the TSM. 1845 TSM sends such a command to instruct a TEE to create a new Security 1846 Domain for a SP. 1848 A TSM sends an OTrP Request message CreateSDRequest to a device TEE 1849 to create a Security Domain for a SP. Such a request is signed by 1850 TSM where the TSM signer may or may not be the same as the SP's TA 1851 signer certificate. The resulting SD is associated with two 1852 identifiers for future management: 1854 o TSM as the owner. The owner identifier is a registered unique TSM 1855 ID that is stored in the TSM certificate. 1857 o SP identified by its TA signer certificate as the authorization. 1858 A TSM can add more than one SP certificates to a SD. 1860 A Trusted Application that is signed by a matching SP signer 1861 certificate for a SD is eligible to be installed into that SD. The 1862 TA installation into a SD by a subsequent InstallTARequest message 1863 may be instructed from TSM or a Client Application. 1865 8.2.1.1. CreateSDRequest Message 1866 The request message for CreateSD has the following JSON format. 1868 { 1869 "CreateSDTBSRequest": { 1870 "ver": "1.0", 1871 "rid": "", 1872 "tid": "", // this may be from prior message 1873 "tee": "", 1874 "nextdsi": "true | false", 1875 "dsihash": "", 1876 "content": ENCRYPTED { // this piece of JSON data will be 1877 // encrypted 1878 "spid": "", 1879 "sdname": "", 1880 "spcert": "", 1881 "tsmid": "", 1883 "did": "" 1884 } 1885 } 1886 } 1888 In the message, 1890 rid - A unique value to identify this request 1892 tid - A unique value to identify this transaction. It can have the 1893 same value for the tid in the preceding GetDeviceStateRequest. 1895 tee - TEE ID returned from the previous response 1896 GetDeviceStateResponse 1898 nextdsi - Indicates whether the up to date Device State Information 1899 (DSI) should be returned in the response to this request. 1901 dsihash - The BASE64 encoded SHA256 hash value of the DSI data 1902 returned in the prior TSM operation with this target TEE. This 1903 value is always included such that a receiving TEE can check 1904 whether the device state has changed since its last query. It 1905 helps enforce SD update order in the right sequence without 1906 accidently overwrite an update that was done simultaneously. 1908 content - The "content" is a JSON encrypted message that includes 1909 actual input for the SD creation. The encryption key is TSMmk that 1910 is encrypted by the target TEE's public key. The entire message is 1911 signed by the TSM private key TSMpriv. A separate TSMmk isn't used 1912 in the latest specification because JSON encryption will use a 1913 content encryption key for exactly the same purpose. 1915 spid - A unique id assigned by the TSM for its SP. It should be 1916 unique within a TSM namespace. 1918 sdname - a name unique to the SP. TSM should ensure it is unique 1919 for each SP. 1921 spcert - The SP's TA signer certificate is included in the request. 1922 This certificate will be stored by the device TEE and uses it to 1923 check against TA installation. Only if a TA is signed by a 1924 matching spcert associated with a SD the TA will be installed into 1925 the SD. 1927 tsmid - SD owner claim by TSM - A SD owned by a TSM will be 1928 associated with a trusted identifier defined as an attribute in the 1929 signer TSM certificate. TEE will be responsible to assign this ID 1930 to the SD. The TSM certificate attribute for this attribute TSMID 1931 must be vetted by the TSM signer issuing CA. With this trusted 1932 identifier, SD query at TEE can be fast upon TSM signer 1933 verification. 1935 did - The SHA256 hash of the binary encoded device TEE certificate. 1936 The encryption key CEK will be encrypted the recipient TEE's public 1937 key. This hash value in the "did" property allows the recipient 1938 TEE to check whether it is the expected target to receive such a 1939 request. If this isn't given, an OTrP message for device 2 could 1940 be sent to device 1. It is optional for TEE to check because the 1941 successful decryption of the request message with this device's TEE 1942 private key already proves it is the target. This explicit hash 1943 value makes the protocol not dependent on message encryption method 1944 in future. 1946 Following is the OTrP message template, the full request is signed 1947 message over the CreateSDTBSRequest as follows. 1949 { 1950 "CreateSDRequest": { 1951 "payload":"", 1952 "protected":"", 1953 "header": , 1954 "signature":"" 1955 } 1956 } 1958 TSM signer certificate is included in the "header" property. 1960 8.2.1.2. Request Processing Requirements at a TEE 1962 Upon receiving a request message CreateSDRequest at a TEE, the TEE 1963 must validate a request: 1965 1. Validate the JSON request message 1967 * Validate JSON message signing 1969 * Validate that the request TSM certificate is chained to a 1970 trusted CA that the TEE embeds as its trust anchor 1972 * Compare dsihash with its current state to make sure nothing 1973 has changed since this request was sent. 1975 * Decrypt to get the plaintext of the content: (a) spid, (b) sd 1976 name, (c) did 1978 * Check that a SPID is supplied 1980 * spcert check: check it is a valid certificate (signature and 1981 format verification only) 1983 * Check "did" is the SHA256 hash of its TEEcert BER raw binary 1984 data 1986 * Check whether the requested SD already exists for the SP 1988 * Check TSMID in the request matches TSM certificate's TSM ID 1989 attribute 1991 2. Create action 1993 * Create a SD for the SP with the given name 1995 * Assign the TSMID from the TSMCert to this SD 1997 * Assign the SPID and SPCert to this SD 1999 * Check whether a TEE SP AIK keypair already exists for the 2000 given SP ID 2002 * Create TEE SP AIK keypair if it doesn't exist for the given SP 2003 ID 2005 * Generate new DSI data if the request asks for updated DSI 2007 3. Construct CreateSDResponse message 2008 * Create raw content 2010 + Operation status 2012 + "did" or full signer certificate information, 2014 + TEE SP AIK public key if DSI isn't going to be included 2016 + Updated DSI data if requested if the request asks for it 2018 * The response message is encrypted with the same JWE CEK of the 2019 request without recreating a new content encryption key. 2021 * The encrypted message is signed with TEEpriv. The signer 2022 information ("did" or TEEcert) is encrypted. 2024 4. Deliver response message. (a) OTrP Agent returns this to the app; 2025 (b) The app passes this back to TSM 2027 5. TSM process. (a) TSM processes the response message; (b) TSM can 2028 look up signer certificate from device ID "did". 2030 If a request is illegitimate or signature doesn't pass, a "status" 2031 property in the response will indicate the error code and cause. 2033 8.2.1.3. CreateSDResponse Message 2035 The response message for a CreateSDRequest contains the following 2036 content. 2038 { 2039 "CreateSDTBSResponse": { 2040 "ver": "1.0", 2041 "status": "", 2042 "rid": "", 2043 "tid": "", 2044 "content": ENCRYPTED { 2045 "reason":"", // optional 2046 "did": "", 2047 "sdname": "", 2048 "teespaik": "", 2049 "dsi": "" 2051 } 2052 } 2053 } 2055 In the response message, the following fields MUST be supplied. 2057 did - The SHA256 hash of the device TEE certificate. This shows 2058 the device ID explicitly to the receiving TSM. 2060 teespaik - The newly generated SP AIK public key for the given SP. 2061 This is an optional value if the device has had another domain for 2062 the SP that has triggered TEE SP AIK keypair for this specific SP. 2064 There is possible extreme error case where TEE isn't reachable or the 2065 TEE final response generation itself fails. In this case, TSM should 2066 still receive a response from the OTrP Agent. OTrP Agent is able to 2067 detect such error from TEE. In this case, a general error response 2068 message should be returned, assuming OTrP Agent even doesn't know any 2069 content and information about the request message. 2071 In other words, TSM should expect receive a TEE successfully signed 2072 JSON message, or a general "status" message. 2074 { 2075 "CreateSDResponse": { 2076 "payload":"", 2077 "protected": { 2078 "" 2079 }, 2080 "signature": "" 2082 } 2083 } 2085 A response message type "status" will be returned when TEE totally 2086 fails to respond. OTrP Agent is responsible to create this message. 2088 { 2089 "status": { 2090 "result": "fail", 2091 "error-code": "ERR_TEE_UNKNOWN", 2092 "error-message": "TEE fails to respond" 2093 } 2094 } 2096 8.2.1.4. Error Conditions 2098 An error may occur if a request isn't valid or the TEE runs into some 2099 error. The list of possible errors are the following. Refer to 2100 section Error Code List (Section 14.1) for detail causes and actions. 2102 ERR_REQUEST_INVALID 2103 ERR_UNSUPPORTED_MSG_VERSION 2105 ERR_UNSUPPORTED_CRYPTO_ALG 2107 ERR_DEV_STATE_MISMATCH 2109 ERR_SD_ALREADY_EXIST 2111 ERR_SD_NOT_FOUND 2113 ERR_SPCERT_INVALID 2115 ERR_TEE_FAIL 2117 ERR_TEE_UNKNOWN 2119 ERR_TSM_NOT_AUTHORIZED 2121 ERR_TSM_NOT_TRUSTED 2123 8.2.2. UpdateSD 2125 This TSM initiated command can update a SP's SD that it manages for 2126 the following need. (a) Update SP signer certificate; (b) Add SP 2127 signer certificate when a SP uses multiple to sign TA binary; (c) 2128 Update SP ID. 2130 The TSM presents the proof of the SD ownership to TEE, and includes 2131 related information in its signed message. The entire request is 2132 also encrypted for the end-to-end confidentiality. 2134 8.2.2.1. UpdateSDRequest Message 2135 The request message for UpdateSD has the following JSON format. 2137 { 2138 "UpdateSDTBSRequest": { 2139 "ver": "1.0", 2140 "rid": "", 2141 "tid": "", // this may be from prior message 2142 "tee": "", 2143 "nextdsi": "true | false", 2144 "dsihash": "", 2145 "content": ENCRYPTED { // this piece of JSON will be encrypted 2146 "tsmid": "", 2147 "spid": "", 2148 "sdname": "", 2149 "changes": { 2150 "newsdname": "", 2151 // Optional 2152 "newspid": "", 2153 // Optional 2154 "spcert": [""], 2155 // Optional 2156 "deloldspcert": [""], 2158 // Optional 2159 "renewteespaik": "true | false" 2160 } 2161 } 2162 } 2163 } 2165 In the message, 2167 rid - A unique value to identify this request 2169 tid - A unique value to identify this transaction. It can have the 2170 same value for the tid in the preceding GetDeviceStateRequest. 2172 tee - TEE ID returned from the previous response 2173 GetDeviceStateResponse 2175 nextdsi - Indicates whether the up to date Device State Information 2176 (DSI) should be returned in the response to this request. 2178 dsihash - The BASE64 encoded SHA256 hash value of the DSI data 2179 returned in the prior TSM operation with this target TEE. This 2180 value is always included such that a receiving TEE can check 2181 whether the device state has changed since its last query. It 2182 helps enforce SD update order in the right sequence without 2183 accidently overwrite an update that was done simultaneously. 2185 content - The "content" is a JSON encrypted message that includes 2186 actual input for the SD update. The standard JSON content 2187 encryption key (CEK) is used, and the CEK is encrypted by the 2188 target TEE's public key. 2190 tsmid - SD owner claim by TSM - A SD owned by a TSM will be 2191 associated with a trusted identifier defined as an attribute in the 2192 signer TSM certificate. 2194 spid - the identifier of the SP whose SD will be updated. This 2195 value is still needed because SD name is considered unique within a 2196 SP only. 2198 sdname - the name of the target SD to be updated. 2200 changes - its content consists of changes that should be updated in 2201 the given SD. 2203 newsdname - the new name of the target SD to be assigned if this 2204 value is present. 2206 newspid - the new SP ID of the target SD to be assigned if this 2207 value is present. 2209 spcert - a new TA signer certificate of this SP to be added to the 2210 SD if this is present. 2212 deloldspcert - a SP certificate assigned into the SD should be 2213 deleted if this is present. The value is the SHA256 fingerprint of 2214 the old SP certificate. 2216 renewteespaik - the value should be 'true' or 'false'. If it is 2217 present and the value is 'true', TEE should regenerate TEE SP AIK 2218 for this SD's owner SP. The newly generated TEE SP AIK for the SP 2219 must be returned in the response message of this request. If there 2220 are more than one SD for the SP, a new SPID for one of the domain 2221 will always trigger a new teespaik generation as if a new SP is 2222 introduced to the TEE. 2224 Following the OTrP message template, the full request is signed 2225 message over the UpdateSDTBSRequest as follows. 2227 { 2228 "UpdateSDRequest": { 2229 "payload":"", 2230 "protected":"", 2231 "header": , 2232 "signature":"" 2233 } 2234 } 2236 TSM signer certificate is included in the "header" property. 2238 8.2.2.2. Request Processing Requirements at a TEE 2240 Upon receiving a request message UpdateSDRequest at a TEE, the TEE 2241 must validate a request: 2243 1. Validate the JSON request message 2245 * Validate JSON message signing 2247 * Validate that the request TSM certificate is chained to a 2248 trusted CA that the TEE embeds as its trust anchor. TSM 2249 certificate status check is generally not needed anymore in 2250 this request. The prior request should have validated the TSM 2251 certificate's revocation status 2253 * Compare dsihash with TEE cached last response DSI data to this 2254 TSM 2256 * Decrypt to get the plaintext of the content 2258 * Check that the target SD name is supplied 2260 * Check whether the requested SD exists 2262 * Check that the TSM owns this TSM by verifying TSMID in the SD 2263 matches TSM certificate's TSM ID attribute 2265 * Now the TEE is ready to carry out update listed in the 2266 "content" message 2268 2. Update action 2270 * If "newsdname" is given, replace the SD name for the SD to the 2271 new value 2273 * If "newspid" is given, replace the SP ID assigned to this SD 2274 with the given new value 2276 * If "spcert" is given, add this new SP certificate to the SD. 2278 * If "deloldspcert" is present in the content, check previously 2279 assigned SP certificates to this SD, and delete the one that 2280 matches the given certificate hash value. 2282 * If "renewteespaik" is given and has a value as "true", 2283 generate a new TEE SP AIK keypair, and replace the old one 2284 with this. 2286 * Generate new DSI data if the request asks for updated DSI 2288 * Now the TEE is ready to construct the response message 2290 3. Construct UpdateSDResponse message 2292 * Create raw content 2294 + Operation status 2296 + "did" or full signer certificate information, 2298 + TEE SP AIK public key if DSI isn't going to be included 2300 + Updated DSI data if requested if the request asks for it 2302 * The response message is encrypted with the same JWE CEK of the 2303 request without recreating a new content encryption key. 2305 * The encrypted message is signed with TEEpriv. The signer 2306 information ("did" or TEEcert) is encrypted. 2308 4. Deliver response message. (a) OTrP Agent returns this to the app; 2309 (b) The app passes this back to TSM 2311 5. TSM process. (a) TSM processes the response message; (b) TSM can 2312 look up signer certificate from device ID "did". 2314 If a request is illegitimate or signature doesn't pass, a "status" 2315 property in the response will indicate the error code and cause. 2317 8.2.2.3. UpdateSDResponse Message 2319 The response message for a UpdateSDRequest contains the following 2320 content. 2322 { 2323 "UpdateSDTBSResponse": { 2324 "ver": "1.0", 2325 "status": "", 2326 "rid": "", 2327 "tid": "", 2328 "content": ENCRYPTED { 2329 "reason":"", // optional 2330 "did": "", 2331 "cert": "", // optional 2332 "teespaik": "", 2333 "teespaiktype": "", 2334 "dsi": "" 2336 } 2337 } 2338 } 2340 In the response message, the following fields MUST be supplied. 2342 did - The request should have known the signer certificate of this 2343 device from a prior request. This hash value of the device TEE 2344 certificate serves as a quick identifier only. Full device 2345 certificate isn't necessary. 2347 teespaik - the newly generated SP AIK public key for the given SP 2348 if TEE SP AIK for the SP is asked to be renewed in the request. 2349 This is an optional value if "dsi" is included in the response, 2350 which will contain all up to date TEE SP AIK key pairs. 2352 Similar to the template for the creation of the encrypted and signed 2353 CreateSDResponse, the final UpdateSDResponse looks like the 2354 following. 2356 { 2357 "UpdateSDResponse": { 2358 "payload":"", 2359 "protected": { 2360 "" 2361 }, 2362 "signature": "" 2364 } 2365 } 2367 A response message type "status" will be returned when TEE totally 2368 fails to respond. OTrP Agent is responsible to create this message. 2370 { 2371 "status": { 2372 "result": "fail", 2373 "error-code": "ERR_TEE_UNKNOWN", 2374 "error-message": "TEE fails to respond" 2375 } 2376 } 2378 8.2.2.4. Error Conditions 2380 An error may occur if a request isn't valid or the TEE runs into some 2381 error. The list of possible errors are the following. Refer to 2382 section Error Code List (Section 14.1) for detail causes and actions. 2384 ERR_REQUEST_INVALID 2386 ERR_UNSUPPORTED_MSG_VERSION 2388 ERR_UNSUPPORTED_CRYPTO_ALG 2390 ERR_DEV_STATE_MISMATCH 2392 ERR_SD_NOT_FOUND 2394 ERR_SDNAME_ALREADY_USED 2396 ERR_SPCERT_INVALID 2398 ERR_TEE_FAIL 2400 ERR_TEE_UNKNOWN 2402 ERR_TSM_NOT_AUTHORIZED 2403 ERR_TSM_NOT_TRUSTED 2405 8.2.3. DeleteSD 2407 A TSM sends a DeleteSDRequest message to TEE to delete a specified SD 2408 that it owns. A SD can be deleted only if there is no TA associated 2409 with this SD in the device. The request message can contain a flag 2410 to instruct TEE to delete all related TAs in a SD and then delete the 2411 SD. 2413 The target TEE will operate with the following logic. 2415 1. Lookup given SD specified in the request message 2417 2. Check that the TSM owns the SD 2419 3. Check that the device state hasn't changed since the last 2420 operation 2422 4. Check whether there are TAs in this SD 2424 5. If TA exists in a SD, check whether the request instructs whether 2425 TA should be deleted. If the request instructs TEE to delete 2426 TAs, delete all TAs in this SD. If the request doesn't instruct 2427 the TEE to delete TAs, return an error "ERR_SD_NOT_EMPTY". 2429 6. Delete SD 2431 7. If this is the last SD of this SP, delete TEE SP AIK key 2433 8.2.3.1. DeleteSDRequest Message 2434 The request message for DeleteSD has the following JSON format. 2436 { 2437 "DeleteSDTBSRequest": { 2438 "ver": "1.0", 2439 "rid": "", 2440 "tid": "", // this may be from prior message 2441 "tee": "", 2442 "nextdsi": "true | false", 2443 "dsihash": "", 2444 "content": ENCRYPTED { // this piece of JSON will be encrypted 2445 "tsmid": "", 2446 "sdname": "", 2447 "deleteta": "true | false" 2448 } 2449 } 2450 } 2452 In the message, 2454 rid - A unique value to identify this request 2456 tid - A unique value to identify this transaction. It can have the 2457 same value for the tid in the preceding GetDeviceStateRequest. 2459 tee - TEE ID returned from the previous response 2460 GetDeviceStateResponse 2462 nextdsi - Indicates whether the up to date Device State Information 2463 (DSI) should be returned in the response to this request. 2465 dsihash - The BASE64 encoded SHA256 hash value of the DSI data 2466 returned in the prior TSM operation with this target TEE. This 2467 value is always included such that a receiving TEE can check 2468 whether the device state has changed since its last query. It 2469 helps enforce SD update order in the right sequence without 2470 accidently overwrite an update that was done simultaneously. 2472 content - The "content" is a JSON encrypted message that includes 2473 actual input for the SD update. The standard JSON content 2474 encryption key (CEK) is used, and the CEK is encrypted by the 2475 target TEE's public key. 2477 tsmid - SD owner claim by TSM - A SD owned by a TSM will be 2478 associated with a trusted identifier defined as an attribute in the 2479 signer TSM certificate. 2481 sdname - the name of the target SD to be updated. 2483 deleteta - the value should be 'true' or 'false'. If it is present 2484 and the value is 'true', TEE should delete all TAs associated with 2485 the SD in the device. 2487 Following the OTrP message template, the full request is signed 2488 message over the DeleteSDTBSRequest as follows. 2490 { 2491 "DeleteSDRequest": { 2492 "payload":"", 2493 "protected":"", 2494 "header": , 2495 "signature":"" 2496 } 2497 } 2499 TSM signer certificate is included in the "header" property. 2501 8.2.3.2. Request Processing Requirements at a TEE 2503 Upon receiving a request message DeleteSDRequest at a TEE, the TEE 2504 must validate a request: 2506 1. Validate the JSON request message 2508 * Validate JSON message signing 2510 * Validate that the request TSM certificate is chained to a 2511 trusted CA that the TEE embeds as its trust anchor. TSM 2512 certificate status check is generally not needed anymore in 2513 this request. The prior request should have validated the TSM 2514 certificate's revocation status 2516 * Compare dsihash with TEE cached last response DSI data to this 2517 TSM 2519 * Decrypt to get the plaintext of the content 2521 * Check that the target SD name is supplied 2523 * Check whether the requested SD exists 2525 * Check that the TSM owns this TSM by verifying TSMID in the SD 2526 matches TSM certificate's TSM ID attribute 2528 * Now the TEE is ready to carry out update listed in the 2529 "content" message 2531 2. Deletion action 2533 * Check TA existence in this SD 2535 * If "deleteta" is "true", delete all TAs in this SD. If the 2536 value of "deleteta" is "false" and some TA exists, return an 2537 error "ERR_SD_NOT_EMPTY" 2539 * Delete the SD 2541 * Delete TEE SP AIK key pair if this SD is the last one for the 2542 SP 2544 * Now the TEE is ready to construct the response message 2546 3. Construct DeleteSDResponse message 2548 * Create response content 2550 + Operation status 2552 + "did" or full signer certificate information, 2554 + Updated DSI data if requested if the request asks for it 2556 * The response message is encrypted with the same JWE CEK of the 2557 request without recreating a new content encryption key. 2559 * The encrypted message is signed with TEEpriv. The signer 2560 information ("did" or TEEcert) is encrypted. 2562 4. Deliver response message. (a) OTrP Agent returns this to the app; 2563 (b) The app passes this back to TSM 2565 5. TSM process. (a) TSM processes the response message; (b) TSM can 2566 look up signer certificate from device ID "did". 2568 If a request is illegitimate or signature doesn't pass, a "status" 2569 property in the response will indicate the error code and cause. 2571 8.2.3.3. DeleteSDResponse Message 2573 The response message for a DeleteSDRequest contains the following 2574 content. 2576 { 2577 "DeleteSDTBSResponse": { 2578 "ver": "1.0", 2579 "status": "", 2580 "rid": "", 2581 "tid": "", 2582 "content": ENCRYPTED { 2583 "reason":"", // optional 2584 "did": "", 2585 "dsi": "" 2587 } 2588 } 2589 } 2591 In the response message, the following fields MUST be supplied. 2593 did - The request should have known the signer certificate of this 2594 device from a prior request. This hash value of the device TEE 2595 certificate serves as a quick identifier only. Full device 2596 certificate isn't necessary. 2598 The final DeleteSDResponse looks like the following. 2600 { 2601 "DeleteSDResponse": { 2602 "payload":"", 2603 "protected": { 2604 "" 2605 }, 2606 "signature": "" 2608 } 2609 } 2611 A response message type "status" will be returned when TEE totally 2612 fails to respond. OTrP Agent is responsible to create this message. 2614 { 2615 "status": { 2616 "result": "fail", 2617 "error-code": "ERR_TEE_UNKNOWN", 2618 "error-message": "TEE fails to respond" 2619 } 2620 } 2622 8.2.3.4. Error Conditions 2624 An error may occur if a request isn't valid or the TEE runs into some 2625 error. The list of possible errors are the following. Refer to 2626 section Error Code List (Section 14.1) for detail causes and actions. 2628 ERR_REQUEST_INVALID 2630 ERR_UNSUPPORTED_MSG_VERSION 2632 ERR_UNSUPPORTED_CRYPTO_ALG 2634 ERR_DEV_STATE_MISMATCH 2636 ERR_SD_NOT_EMPTY 2638 ERR_SD_NOT_FOUND 2640 ERR_TEE_FAIL 2642 ERR_TEE_UNKNOWN 2644 ERR_TSM_NOT_AUTHORIZED 2646 ERR_TSM_NOT_TRUSTED 2648 8.3. Trusted Application Management 2650 This protocol doesn't introduce a TA container concept. All the TA 2651 authorization and management will be up to TEE implementation. 2653 The following three TA management commands will be supported. 2655 o InstallTA - provision a TA by TSM 2657 o UpdateTA - update a TA by TSM 2659 o DeleteTA - remove TA registration information with a SD, remove TA 2660 binary from TEE, remove all TA related data in TEE 2662 8.3.1. InstallTA 2664 TA binary data can be from two sources: 2666 1. TSM supplies the signed TA binary 2668 2. Client Application supplies the TA binary 2669 This specification considers only the first case where TSM supplies 2670 TA binary. When such a request is received by TEE, a SD is already 2671 created and is ready to take TA installation. 2673 A TSM sends the following information in message InstallTARequest to 2674 a target TEE: 2676 o The target SD information: SP ID and SD name 2678 o Encrypted TA binary data. TA data is encrypted with TEE SP AIK. 2680 o TA metadata. It is optional to include SP signer certificate for 2681 the SD to add if the SP has changed signer since the SD was 2682 created. 2684 TEE processes command given by TSM to install TA into a SP's SD. It 2685 does the following: 2687 o Validation 2689 * TEE validates TSM message authenticity 2691 * Decrypt to get request content 2693 * Lookup SD with SD name 2695 * Checks that the TSM owns the SD 2697 * Checks DSI hash matches that the device state hasn't changed 2699 o TA validation 2701 * Decrypt to get TA binary and any personalization data with "TEE 2702 SP AIK private key" 2704 * Check that SP ID is the one that is registered with the SP SD 2706 * TA signer is either the newly given SP certificate or the one 2707 in SD. The TA signing method is specific to TEE. This 2708 specification doesn't define how a TA should be signed. 2710 * If a TA signer is given in the request, add this signer into 2711 the SD. 2713 o TA installation 2715 * TEE re-encrypts TA binary and its personalization data with its 2716 own method 2718 * TEE enrolls and stores the TA onto TEE secure storage area. 2720 o Construct a response message. This involves signing a encrypted 2721 status information for the requesting TSM. 2723 8.3.1.1. InstallTARequest Message 2725 The request message for InstallTA has the following JSON format. 2727 { 2728 "InstallTATBSRequest": { 2729 "ver": "1.0", 2730 "rid": "", 2731 "tid": "", 2732 "tee": "", 2733 "nextdsi": "true | false", 2734 "dsihash": "", 2735 "content": ENCRYPTED { 2736 "tsmid": "", 2737 "spid": "", 2738 "sdname": "", 2739 "spcert": "", // optional 2740 "taid": "" 2741 }, 2742 "encrypted_ta": { 2743 "key": "", 2745 "iv": "", 2746 "alg": "", 2748 "cipherpdata": "" 2750 } 2751 } 2752 } 2754 In the message, 2756 rid - A unique value to identify this request 2758 tid - A unique value to identify this transaction. It can have the 2759 same value for the tid in the preceding GetDeviceStateRequest. 2761 tee - TEE ID returned from the previous response 2762 GetDeviceStateResponse 2764 nextdsi - Indicates whether the up to date Device State Information 2765 (DSI) should be returned in the response to this request. 2767 dsihash - The BASE64 encoded SHA256 hash value of the DSI data 2768 returned in the prior TSM operation with this target TEE. This 2769 value is always included such that a receiving TEE can check 2770 whether the device state has changed since its last query. It 2771 helps enforce SD update order in the right sequence without 2772 accidently overwrite an update that was done simultaneously. 2774 content - The "content" is a JSON encrypted message that includes 2775 actual input for the SD update. The standard JSON content 2776 encryption key (CEK) is used, and the CEK is encrypted by the 2777 target TEE's public key. 2779 tsmid - SD owner claim by TSM - A SD owned by a TSM will be 2780 associated with a trusted identifier defined as an attribute in the 2781 signer TSM certificate. 2783 spid - SP identifier of the TA owner SP 2785 sdname - the name of the target SD where the TA should be installed 2787 spcert - an optional field to specify SP certificate that signed the 2788 TA. This is sent if the SP has a new certificate that hasn't been 2789 previously registered with the target SD where the TA should be 2790 installed. 2792 taid - the identifier of the TA application to be installed 2794 encrypted_ta - the message portion contains encrypted TA binary data 2795 and personalization data. The TA data encryption key is placed in 2796 "key", which is encrypted by the recipient's public key. The TA 2797 data encryption uses symmetric key based encryption such as AESCBC. 2799 Following the OTrP message template, the full request is signed 2800 message over the InstallTATBSRequest as follows. 2802 { 2803 "InstallTARequest": { 2804 "payload":"", 2805 "protected":"", 2806 "header": , 2807 "signature":"" 2808 } 2809 } 2811 8.3.1.2. InstallTAResponse Message 2813 The response message for a InstallTARequest contains the following 2814 content. 2816 { 2817 "InstallTATBSResponse": { 2818 "ver": "1.0", 2819 "status": "", 2820 "rid": "", 2821 "tid": "", 2822 "content": ENCRYPTED { 2823 "reason":"", // optional 2824 "did": "", 2825 "dsi": "" 2827 } 2828 } 2829 } 2831 In the response message, the following fields MUST be supplied. 2833 did - the SHA256 hash of the device TEE certificate. This shows 2834 the device ID explicitly to the receiving TSM. 2836 The final message InstallTAResponse looks like the following. 2838 { 2839 "InstallTAResponse": { 2840 "payload":"", 2841 "protected": { 2842 "" 2843 }, 2844 "signature": "" 2846 } 2847 } 2849 A response message type "status" will be returned when TEE totally 2850 fails to respond. OTrP Agent is responsible to create this message. 2852 { 2853 "status": { 2854 "result": "fail", 2855 "error-code": "ERR_TEE_UNKNOWN", 2856 "error-message": "TEE fails to respond" 2857 } 2858 } 2860 8.3.1.3. Error Conditions 2862 An error may occur if a request isn't valid or the TEE runs into some 2863 error. The list of possible errors are the following. Refer to 2864 section Error Code List (Section 14.1) for detail causes and actions. 2866 ERR_REQUEST_INVALID 2868 ERR_UNSUPPORTED_MSG_VERSION 2870 ERR_UNSUPPORTED_CRYPTO_ALG 2872 ERR_DEV_STATE_MISMATCH 2874 ERR_SD_NOT_FOUND 2876 ERR_TA_INVALID 2878 ERR_TA_ALREADY_INSTALLED 2880 ERR_TEE_FAIL 2882 ERR_TEE_UNKNOWN 2884 ERR_TEE_RESOURCE_FULL 2886 ERR_TSM_NOT_AUTHORIZED 2888 ERR_TSM_NOT_TRUSTED 2890 8.3.2. UpdateTA 2892 This TSM initiated command can update TA and its data in a SP's SD 2893 that it manages for the following purposes. 2895 1. Update TA binary 2897 2. Update TA's personalization data 2898 The TSM presents the proof of the SD ownership to TEE, and includes 2899 related information in its signed message. The entire request is 2900 also encrypted for the end-to-end confidentiality. 2902 TEE processes command given by TSM to update TA of a SP SD. It does 2903 the following: 2905 o Validation 2907 * TEE validates TSM message authenticity 2909 * Decrypt to get request content 2911 * Lookup SD with SD name 2913 * Checks that the TSM owns the SD 2915 * Checks DSI hash matches that the device state hasn't changed 2917 o TA validation 2919 * Both TA binary and personalization data are optional, but at 2920 least one of them shall be present in the message 2922 * Decrypt to get TA binary and any personalization data with "TEE 2923 SP AIK private key" 2925 * Check that SP ID is the one that is registered with the SP SD 2927 * TA signer is either the newly given SP certificate or the one 2928 in SD. The TA signing method is specific to TEE. This 2929 specification doesn't define how a TA should be signed. 2931 * If a TA signer is given in the request, add this signer into 2932 the SD 2934 o TA update 2936 * TEE re-encrypts TA binary and its personalization data with its 2937 own method 2939 * TEE replaces the existing TA binary and its personalization 2940 data with the new binary and data. 2942 o Construct a response message. This involves signing a encrypted 2943 status information for the requesting TSM. 2945 8.3.2.1. UpdateTARequest Message 2947 The request message for UpdateTA has the following JSON format. 2949 { 2950 "UpdateTATBSRequest": { 2951 "ver": "1.0", 2952 "rid": "", 2953 "tid": "", 2954 "tee": "", 2955 "nextdsi": "true | false", 2956 "dsihash": "", 2957 "content": ENCRYPTED { 2958 "tsmid": "", 2959 "spid": "", 2960 "sdname": "", 2961 "spcert": "", // optional 2962 "taid": "" 2963 }, 2964 "encrypted_ta": { 2965 "key": "", 2967 "iv": "", 2968 "alg": "", 2971 "ciphernewpdata": "" 2973 // optional 2974 } 2975 } 2976 } 2978 In the message, 2980 rid - A unique value to identify this request 2982 tid - A unique value to identify this transaction. It can have the 2983 same value for the tid in the preceding GetDeviceStateRequest. 2985 tee - TEE ID returned from the previous response 2986 GetDeviceStateResponse 2988 nextdsi - Indicates whether the up to date Device State Information 2989 (DSI) should be returned in the response to this request. 2991 dsihash - The BASE64 encoded SHA256 hash value of the DSI data 2992 returned in the prior TSM operation with this target TEE. This 2993 value is always included such that a receiving TEE can check 2994 whether the device state has changed since its last query. It 2995 helps enforce SD update order in the right sequence without 2996 accidently overwrite an update that was done simultaneously. 2998 content - The "content" is a JSON encrypted message that includes 2999 actual input for the SD update. The standard JSON content 3000 encryption key (CEK) is used, and the CEK is encrypted by the 3001 target TEE's public key. 3003 tsmid - SD owner claim by TSM - A SD owned by a TSM will be 3004 associated with a trusted identifier defined as an attribute in the 3005 signer TSM certificate. 3007 spid - SP identifier of the TA owner SP 3009 spcert - an optional field to specify SP certificate that signed the 3010 TA. This is sent if the SP has a new certificate that hasn't been 3011 previously registered with the target SD where the TA should be 3012 installed. 3014 sdname - the name of the target SD where the TA should be updated 3016 taid - an identifier for the TA application to be updated 3018 encrypted_ta - the message portion contains new encrypted TA binary 3019 data and personalization data. 3021 Following the OTrP message template, the full request is signed 3022 message over the UpdateTATBSRequest as follows. 3024 { 3025 "UpdateTARequest": { 3026 "payload":"", 3027 "protected":"", 3028 "header": , 3029 "signature":"" 3030 } 3031 } 3033 8.3.2.2. UpdateTAResponse Message 3035 The response message for a UpdateTARequest contains the following 3036 content. 3038 { 3039 "UpdateTATBSResponse": { 3040 "ver": "1.0", 3041 "status": "", 3042 "rid": "", 3043 "tid": "", 3044 "content": ENCRYPTED { 3045 "reason":"", // optional 3046 "did": "", 3047 "dsi": "" 3049 } 3050 } 3051 } 3053 In the response message, the following fields MUST be supplied. 3055 did - the SHA256 hash of the device TEE certificate. This shows 3056 the device ID explicitly to the receiving TSM. 3058 The final message UpdateTAResponse looks like the following. 3060 { 3061 "UpdateTAResponse": { 3062 "payload":"", 3063 "protected": { 3064 "" 3065 }, 3066 "signature": "" 3068 } 3069 } 3071 A response message type "status" will be returned when TEE totally 3072 fails to respond. OTrP Agent is responsible to create this message. 3074 { 3075 "status": { 3076 "result": "fail", 3077 "error-code": "ERR_TEE_UNKNOWN", 3078 "error-message": "TEE fails to respond" 3079 } 3080 } 3082 8.3.2.3. Error Conditions 3084 An error may occur if a request isn't valid or the TEE runs into some 3085 error. The list of possible errors are the following. Refer to 3086 section Error Code List (Section 14.1) for detail causes and actions. 3088 ERR_REQUEST_INVALID 3090 ERR_UNSUPPORTED_MSG_VERSION 3092 ERR_UNSUPPORTED_CRYPTO_ALG 3094 ERR_DEV_STATE_MISMATCH 3096 ERR_SD_NOT_FOUND 3098 ERR_TA_INVALID 3100 ERR_TA_NOT_FOUND 3102 ERR_TEE_FAIL 3104 ERR_TEE_UNKNOWN 3106 ERR_TSM_NOT_AUTHORIZED 3108 ERR_TSM_NOT_TRUSTED 3110 8.3.3. DeleteTA 3112 This operation defines OTrP messages that allow a TSM instruct a TEE 3113 to delete a TA for a SP in a given SD. A TEE will delete a TA from a 3114 SD and also TA data in the TEE. A Client Application cannot directly 3115 access TEE or OTrP Agent to delete a TA. 3117 8.3.3.1. DeleteTARequest Message 3118 The request message for DeleteTA has the following JSON format. 3120 { 3121 "DeleteTATBSRequest": { 3122 "ver": "1.0", 3123 "rid": "", 3124 "tid": "", 3125 "tee": "", 3126 "nextdsi": "true | false", 3127 "dsihash": "", 3128 "content": ENCRYPTED { 3129 "tsmid": "", 3130 "sdname": "", 3131 "taid": "" 3133 } 3134 } 3135 } 3137 In the message, 3139 rid - A unique value to identify this request 3141 tid - A unique value to identify this transaction. It can have the 3142 same value for the tid in the preceding GetDeviceStateRequest. 3144 tee - TEE ID returned from the previous response 3145 GetDeviceStateResponse 3147 nextdsi - Indicates whether the up to date Device State Information 3148 (DSI) should be returned in the response to this request. 3150 dsihash - The BASE64 encoded SHA256 hash value of the DSI data 3151 returned in the prior TSM operation with this target TEE. This 3152 value is always included such that a receiving TEE can check 3153 whether the device state has changed since its last query. It 3154 helps enforce SD update order in the right sequence without 3155 accidently overwrite an update that was done simultaneously. 3157 content - The "content" is a JSON encrypted message that includes 3158 actual input for the SD update. The standard JSON content 3159 encryption key (CEK) is used, and the CEK is encrypted by the 3160 target TEE's public key. 3162 tsmid - SD owner claim by TSM - A SD owned by a TSM will be 3163 associated with a trusted identifier defined as an attribute in the 3164 signer TSM certificate. 3166 sdname - the name of the target SD where the TA is installed 3168 taid - an identifier for the TA application to be deleted 3170 Following the OTrP message template, the full request is signed 3171 message over the DeleteTATBSRequest as follows. 3173 { 3174 "DeleteTARequest": { 3175 "payload":"", 3176 "protected":"", 3177 "header": , 3178 "signature":"" 3180 } 3181 } 3183 8.3.3.2. Request Processing Requirements at a TEE 3185 TEE processes command given by TSM to delete a TA of a SP SD. It 3186 does the following: 3188 1. Validate the JSON request message 3190 * TEE validates TSM message authenticity 3192 * Decrypt to get request content 3194 * Lookup the SD and the TA with the given SD name and TA ID 3196 * Checks that the TSM owns the SD, and TA is installed in the SD 3198 * Checks DSI hash matches that the device state hasn't changed 3200 2. Deletion action 3202 * If all the above validation points pass, the TEE deletes the 3203 TA from the SD 3205 * The TEE may also delete all personalization data for the TA 3207 3. Construct DeleteTAResponse message. 3209 If a request is illegitimate or signature doesn't pass, a "status" 3210 property in the response will indicate the error code and cause. 3212 8.3.3.3. DeleteTAResponse Message 3214 The response message for a DeleteTARequest contains the following 3215 content. 3217 { 3218 "DeleteTATBSResponse": { 3219 "ver": "1.0", 3220 "status": "", 3221 "rid": "", 3222 "tid": "", 3223 "content": ENCRYPTED { 3224 "reason":"", // optional 3225 "did": "", 3226 "dsi": "" 3228 } 3229 } 3230 } 3232 In the response message, the following fields MUST be supplied. 3234 did - the SHA256 hash of the device TEE certificate. This shows 3235 the device ID explicitly to the receiving TSM. 3237 The final message DeleteTAResponse looks like the following. 3239 { 3240 "DeleteTAResponse": { 3241 "payload":"", 3242 "protected": { 3243 "" 3244 }, 3245 "signature": "" 3247 } 3248 } 3250 A response message type "status" will be returned when TEE totally 3251 fails to respond. OTrP Agent is responsible to create this message. 3253 { 3254 "status": { 3255 "result": "fail", 3256 "error-code": "ERR_TEE_UNKNOWN", 3257 "error-message": "TEE fails to respond" 3258 } 3259 } 3261 8.3.3.4. Error Conditions 3263 An error may occur if a request isn't valid or the TEE runs into some 3264 error. The list of possible errors are the following. Refer to 3265 section Error Code List (Section 14.1) for detail causes and actions. 3267 ERR_REQUEST_INVALID 3269 ERR_UNSUPPORTED_MSG_VERSION 3271 ERR_UNSUPPORTED_CRYPTO_ALG 3273 ERR_DEV_STATE_MISMATCH 3275 ERR_SD_NOT_FOUND 3277 ERR_TA_NOT_FOUND 3279 ERR_TEE_FAIL 3281 ERR_TEE_UNKNOWN 3283 ERR_TSM_NOT_AUTHORIZED 3285 ERR_TSM_NOT_TRUSTED 3287 9. Response Messages a TSM May Expect 3289 A TSM expects some feedback from a remote device when a request 3290 message is delivered to a device. The following three types of 3291 responses SHOULD be supplied. 3293 Type 1: Expect a valid TEE generated response message 3295 A valid TEE signed response may contain errors detected by TEE, 3296 e.g. TSM is trusted but TSM supplied data is missing, for 3297 example, SP ID doesn't exist. TEE MUST be able to sign and 3298 encrypt. 3300 If TEE isn't able to sign a response, TEE should returns an error 3301 to OTrP Agent without giving any other internal information. 3302 OTrP Agent will be generating the response. 3304 Type 2: OTrP Agent generated error message when TEE fails. OTrP 3305 Agent errors will be defined in this document. 3307 A Type 2 message has the following format. 3309 { 3310 "OTrPAgentError": { 3311 "ver": "1.0", 3312 "rid": "", 3313 "tid": "", 3314 "errcode": "ERR_TEE_FAIL | ERR_TEE_BUSY" 3315 } 3316 } 3318 Type 3: OTrP Agent itself isn't reachable or fails. A Client 3319 Application is responsible to handle error and response TSM in 3320 its own way. This is out of scope for this specification. 3322 10. Basic Protocol Profile 3324 This section describes a baseline for interoperability among the 3325 protocol entities, mainly, the TSM and TEE. 3327 A TEE MUST support RSA algorithms. It is optional to support ECC 3328 algorithms. A TSM should use a RSA certificate for TSM message 3329 signing. It may use an ECC certificate if it detects that the TEE 3330 supports ECC. 3332 A TSM MUST support both RSA 2048-bit algorithm and ECC P-256 3333 algorithms. With this, a TEE and TFW certificate can be either RSA 3334 or ECC type. 3336 JSON signing algorithms 3338 o RSA PKCS#1 with SHA256 signing : "RS256" 3340 o ECDSA with SHA256 signing : "ES256" 3342 JSON asymmetric encryption algorithms (describes key-exchange or key- 3343 agreement algorithm for sharing symmetric key with TEE): 3345 o RSA PKCS#1 : "RSA1_5" 3346 o ECDH using TEE ECC P-256 key and ephemeral ECC key generated by 3347 TSM : "ECDH-ES+A128W" 3349 JSON symmetric encryption algorithms (describes symmetric algorithm 3350 for encrypting body of data, using symmetric key transferred to TEE 3351 using asymmetric encryption): 3353 o Authenticated encryption AES 128 CBC with SHA256 : 3354 {"enc":"A128CBC-HS256"} 3356 11. Attestation Implementation Consideration 3358 It is important to know that the state of a device is appropriate 3359 before trusting that a device is what it says it is. The attestation 3360 scheme for OTrP must also be able to cope with different TEEs, those 3361 that are OTrP compliant and those that use another mechanism. In the 3362 initial version, only one active TEE is assumed. 3364 It is out of scope about how TSM and device implement the trust 3365 hierarchy verification. However, it is helpful to understand what 3366 each system provider should do in order to properly implement OTrP 3367 trust hierarchy. 3369 In this section, we provide some implementation reference 3370 consideration. 3372 11.1. OTrP Secure Boot Module 3374 11.1.1. Attestation signer 3376 It is proposed that attestation for OTrP is based on the SBM secure 3377 boot layer, and that further attestation is not performed within the 3378 TEE itself during security domain operations. The rationale is that 3379 the device boot process will be defined to start with a secure boot 3380 approach that, using eFuse, only releases attestation signing 3381 capabilities into the SBM once a secure boot has been established. 3382 In this way the release of the attestation signer can be considered 3383 the first "platform configuration metric", using TCG terminology. 3385 11.1.2. SBM Initial Requirements 3387 R1 SBM must be possible to load securely into the secure boot flow 3389 R2 SBM must allow a public / private key pair to be generated during 3390 device manufacture 3392 R3 The public key and certificate must be possible to store securely 3393 from tamper 3395 R4 The private key must be possible to store encrypted at rest 3397 R5 The private key must only be visible to the SBM when it is 3398 decrypted 3400 R6 The SBM must be able to read a list of root and intermediate 3401 certificates that it can use to check certificate chains with. 3402 The list must be stored such that it cannot be tampered with 3404 R7 Possible need to allow a TEE to access its unique TEE specific 3405 private key 3407 11.2. TEE Loading 3409 During boot SBM is required to start all of the ROOT TEEs. Before 3410 loading them the SBM must first determine whether the code sign 3411 signature of the TEE is valid. If TEE integrity is confirmed it may 3412 be started. The SBM must then be able to receive the identity 3413 certificate from the TEE (if that TEE is OTrP compliant). The 3414 identity certificate and keys will need to be baked into the TEE 3415 image, and therefore also covered by the code signer hash during the 3416 manufacture process. The private key for the identity certificate 3417 must be securely protected. The private key for a TEE identity must 3418 never be released no matter how the public key and certificate are 3419 released to the SBM. 3421 Once the SBM has successfully booted a TEE and retrieved the identity 3422 certificate it will commit this to the platform configuration 3423 register (PCR) set, for later use during attestation. As a minimum 3424 the following data must be committed to the PCR for each TEE: 3426 1. Public key and certificate for the TEE 3428 2. TEE reference that can be used later by a TSM to identify this 3429 TEE 3431 11.3. Attestation Hierarchy 3433 The attestation hierarchy and seed required for TSM protocol 3434 operation must be built into the device at manufacture. Additional 3435 TEEs can be added post manufacture using the scheme proposed however 3436 it is outside of the current scope of this document to detail that. 3438 It should be noted that the attestation scheme described is based on 3439 signatures. The only encryption that takes place is with eFuse to 3440 release the SBM signing key and later during protocol lifecycle 3441 management interchange with the TSM. 3443 11.3.1. Attestation Hierarchy Establishment: Manufacture 3445 During manufacture the following steps are required: 3447 1. Device specific TFW key pair and certificate burnt into device, 3448 encrypted by eFuse. This key pair will be used for signing 3449 operations performed by SBM. 3451 2. TEE images are loaded and include a TEE instance specific key 3452 pair and certificate. The key pair and certificate are included 3453 in the image and covered by the code signing hash. 3455 3. The process for TEE images is repeated for any subordinate TEEs 3457 11.3.2. Attestation Hierarchy Establishment: Device Boot 3459 During device boot the following steps are required: 3461 1. Secure boot releases TFW private key by decrypting with eFuse 3463 2. SBM verifies the code-signing signature of the active TEE and 3464 places its TEE public key into a signing buffer, along with their 3465 reference for later access. For non-OTrP TEE, the SBM leaves the 3466 TEE public key field blank. 3468 3. SBM signs the signing buffer with TFW private key 3470 4. Each active TEE performs the same operation as SBM, building up 3471 their own signed buffer containing subordinate TEE information. 3473 11.3.3. Attestation Hierarchy Establishment: TSM 3475 Before a TSM can begin operation in the marketplace it must obtain a 3476 TSM key pair and certificate (TSMpub, TSMpriv) from a CA that is 3477 registered in the trust store of the TEE. In this way, the TEE can 3478 check the intermediate and root CA and verify that it trusts this TSM 3479 to perform operations on the TEE. 3481 12. Acknowledgements 3483 We thank Alin Mutu for his contribution to many discussion that 3484 helped to design the trust flow mechanisms, and the creation of the 3485 flow diagrams. We also thank the following people (by alphabetical 3486 order) for their input and review: Sangsu Baek, Marc Canel, Roger 3487 Casals, Rob Coombs, Lubna Dajani, Richard Parris, and Pengfei Zhao. 3489 13. Contributors 3491 Brian Witten 3492 Symantec 3493 900 Corporate Pointe 3494 Culver City, CA 90230 3495 USA 3497 Email: brian_witten@symantec.com 3499 Tyler Kim 3500 Solacia 3501 5F, Daerung Post Tower 2, 306 Digital-ro 3502 Seoul 152-790 3503 Korea 3505 Email: tkkim@sola-cia.com 3507 14. IANA Considerations 3509 The error code listed in the next section will be registered. 3511 14.1. Error Code List 3513 This section lists error codes that could be reported by a TA or TEE 3514 in a device in responding a TSM request. 3516 ERR_DEV_STATE_MISMATCH - TEE will return this error code if DSI hash 3517 value from TSM doesn't match with that of device's current DSI. 3519 ERR_SD_ALREADY_EXIST - This error will occur if SD to be created 3520 already exist in the TEE. 3522 ERR_SD_NOT_EMPTY - This is reported if a target SD isn't empty. 3524 ERR_SDNAME_ALREADY_USED TEE will return this error code if new SD 3525 name already exists in the namespace of TSM in the TEE. 3527 ERR_REQUEST_INVALID - This error will occur if the TEE meets the 3528 following conditions with a request message: (1) The request from a 3529 TSM has an invalid message structure; mandatory information is 3530 absent in the message. undefined member or structure is included. 3531 (2) TEE fails to verify signature of the message or fails to 3532 decrypt its contents. (3) etc. 3534 ERR_SPCERT_INVALID - If new SP certificate for the SD to be updated 3535 is not valid, then TEE will return this error code. 3537 ERR_TA_ALREADY_INSTALLED - while installing TA, TEE will return this 3538 error if the TA already has been installed in the SD. 3540 ERR_TA_INVALID - This error will occur when TEE meets any of 3541 following conditions while checking validity of TA: (1) TA binary 3542 has a format that TEE can't recognize. (2) TEE fails to decrypt the 3543 encoding of TA binary and personalization data. (3) If SP isn't 3544 registered with the SP SD where TA will be installed. (4) etc. 3546 ERR_TA_NOT_FOUND - This error will occurs when target TA doesn't 3547 exist in the SD. 3549 ERR_TEE_BUSY - The device TEE is busy. The request should be 3550 generally sent later to retry. 3552 ERR_TEE_FAIL - TEE fails to respond to a TSM request. The OTrP 3553 Agent will construct an error message in responding the TSM's 3554 request. And also if TEE fails to process a request because of its 3555 internal error, it will return this error code. 3557 ERR_TEE_RESOURCE_FULL - This error is reported when a device 3558 resource isn't available anymore such as storage space is full. 3560 ERR_TEE_UNKNOWN - This error will occur if the receiver TEE is not 3561 supposed to receive the request. That will be determined by 3562 checking TEE name or device id in the request message. 3564 ERR_TFW_NOT_TRUSTED - TEE may concern the underlying device firmware 3565 is trustworthy. If TEE determines TFW is not trustworthy, then 3566 this error will occur. 3568 ERR_TSM_NOT_TRUSTED - Before processing a request, TEE needs to make 3569 sure whether the sender TSM is trustworthy by checking the validity 3570 of TSM certificate etc. If TEE finds TSM is not reliable, then it 3571 will return this error code. 3573 ERR_UNSUPPORTED_CRYPTO_ALG - This error will occur if TEE receives a 3574 request message encoded with cryptographic algorithms that TEE 3575 doesn't support. 3577 ERR_UNSUPPORTED_MSG_VERSION - This error will occur if TEE receives 3578 the version of message that TEE can't deal with. 3580 15. Security Consideration 3581 15.1. Cryptographic Strength 3583 The strength of the cryptographic algorithms, using the measure of 3584 'bits of security' defined in NIST SP800-57 allowed for the OTrP 3585 protocol is: 3587 o At a minimum, 112 bits of security. The limiting factor for this 3588 is the RSA-2048 algorithm, which is indicated as providing 112 3589 bits of symmetric key strength in SP800-57. It is important that 3590 RSA is supported in order to enhance the interoperability of the 3591 protocol. 3593 o The option exists to choose algorithms providing 128 bits of 3594 security. This requires using TEE devices that support ECC P256. 3596 The available algorithms and key sizes specified in this document are 3597 based on industry standards. Over time the recommended or allowed 3598 cryptographic algorithms may change. It is important that the OTrP 3599 protocol allows for crypto-agility. 3601 15.2. Message Security 3603 OTrP messages between the TSM and TEE are protected by message 3604 security using JWS and JWE. The 'Basic protocol profile' section of 3605 this document describes the algorithms used for this. All OTrP TEE 3606 devices and OTrP TSMs must meet the requirements of the basic 3607 profile. In the future additional 'profiles' can be added. 3609 PKI is used to ensure that the TEE will only communicate with a 3610 trusted TSM, and to ensure that the TSM will only communicate with a 3611 trusted TEE. 3613 15.3. TEE Attestation 3615 It is important that the TSM can trust that it is talking to a 3616 trusted TEE. This is achieved through attestation. The TEE has a 3617 private key and certificate built into it at manufacture, which is 3618 used to sign data supplied by the TSM. This allows the TSM to verify 3619 that the TEE is trusted. 3621 It is also important that the TFW (trusted firmware) can be checked. 3622 The TFW has a private key and certificate built into it at 3623 manufacturer, which allows the TEE to check that that the TFW is 3624 trusted. 3626 The GetDeviceState message therefore allows the TSM to check that it 3627 trusts the TEE, and the TEE at this point will check whether it 3628 trusts the TFW. 3630 15.4. TA Protection 3632 TA will be delivered in an encrypted form. This encryption is an 3633 additional layer within the message encryption described in the 3634 'Basic protocol profile' section of this document. The TA binary is 3635 encrypted for each target device with the device's TEE SP AIK public 3636 key. A TSM may do this encryption or provides the TEE SP AIK public 3637 key to a SP such that the SP encrypts the encrypted TA to TSM for 3638 distribution to TEE. 3640 The encryption algorithm can use a randomly AES 256 key "taek" with a 3641 16 byte random IV, and the "taek" is encrypted by the "TEE SP AIK 3642 public key". The following encrypted TA data structure is expected 3643 by TEE: 3645 "encrypted_ta_bin": { 3646 "key": "", 3648 "iv": ", 3649 "alg": "AESCBC", 3650 "cipherdata": "" 3651 } 3653 15.5. TA Personalization Data 3655 A SP or TSM can supply personalization data for a TA to initialize 3656 for a device. Such data is passed through InstallTA command from 3657 TSM. The personalization data itself is (or can be) opaque to the 3658 TSM. The data can be from the SP without being revealed to the TSM. 3659 The data is sent in encrypted manner in a request to a device such 3660 that only the device can decrypt. A device's TEE SP AIK public key 3661 for a SP is used to encrypt the data. 3663 "encrypted_ta_data": { // "TA personalization data" 3664 "key": "", 3666 "iv": "", 3667 "alg": "AESCBC", 3668 "cipherdata": "" 3670 } 3672 15.6. TA Trust Check at TEE 3674 A TA binary is signed by a TA signer certificate. This TA signing 3675 certificate/private key belongs to the SP, and may be self-signed 3676 (i.e. it need not participate in a trust hierarchy). It is the 3677 responsibility of the TSM to only allow verified TAs from trusted SPs 3678 into the system. Delivery of that TA to the TEE is then the 3679 responsibility of the TEE, using the security mechanisms provided by 3680 the OTrP protocol. 3682 We allow a way for application to check trustworthy of a TA. OTrP 3683 Agent will have a function to allow an application query the metadata 3684 of a TA. 3686 An application in the Rich O/S may perform verification of the TA by 3687 verifying the signature of the TA. The 3688 OTRPService.getTAInformation() function is available to return TEE 3689 supplied TA signer and TSM signer information to the application. An 3690 application can do additional trust check on the certificate returned 3691 for this TA. It may trust TSM, or require additional SP signer trust 3692 chaining. 3694 15.7. One TA Multiple SP Case 3696 A TA for different SP must have different identifier. A TA will be 3697 installed in different SD for the respective SP. 3699 15.8. OTrP Agent Trust Model 3701 An OTrP Agent could be malware in the vulnerable Android OS. A 3702 Client Application will connect its TSM provider for required TA 3703 installation. It gets command messages from TSM, and passes the 3704 message to the OTrP Agent. 3706 The OTrP protocol is a conduit for enabling the TSM to communicate 3707 with the device's TEE to manage SDs and TAs. All TSM messages are 3708 signed and sensitive data is encrypted such that the OTrP Agent 3709 cannot modify or capture sensitive data. 3711 15.9. OCSP Stapling Data for TSM Signed Messages 3713 The GetDeviceStateRequest message from TSM to TEE shall include OCSP 3714 stapling data for the TSM's signer certificate and that for 3715 intermediate CA certificates up to the root certificate so that the 3716 TEE side can verify the signer certificate's revocation status. 3718 Certificate revocation status check on a TA signer certificate is 3719 optional by a TEE. A TSM is generally expected to do proper TA 3720 application vetting and its SP signer trust validation. A TEE will 3721 trust a TA signer certificate's validation status done by a TSM when 3722 it trusts the TSM. 3724 15.10. Data Protection at TSM and TEE 3726 The TEE implementation provides protection of data on the device. It 3727 is the responsibility of the TSM to protect data on its servers. 3729 15.11. Privacy Consideration 3731 Devices are issued with a unique TEE certificate to attest a device 3732 validity. This uniqueness also creates a privacy and tracking risk 3733 that must be mitigated. 3735 The TEE will only release the TEE certificate to a trusted TSM (it 3736 must verify the TSM certificate before proceeding). The OTrP 3737 protocol is designed such that only the TSM can obtain the TEE device 3738 certificate and firmware certificate - the GetDeviceState message 3739 requires signature checks to validate the TSM is trusted, and then 3740 delivers the device's certificate(s) encrypted such that only that 3741 TSM may decrypt the response. A Client Application will never see 3742 device certificate. 3744 A SP specific TEE SP AIK (TEE SP Anonymous Key) is generated by the 3745 protocol for Client Applications. This provides a way for the Client 3746 Application to validate data sent from the TEE without requiring the 3747 TEE device certificate to be released to the client device rich O/S , 3748 and to optionally allow an SP to encrypt a TA for a target device 3749 without the SP needing to be supplied the TEE device certificate. 3751 15.12. Threat Mitigation 3753 A rogue application may perform excessive TA loading. OTrP Agent 3754 implementation should protect against excessive calls. 3756 Rogue applications may request excessive SD creation request. The 3757 TSM is responsible to ensure this is properly guarded against. 3759 Rogue OTrP Agent could replay or send TSM messages out of 3760 sequence:e.g. TSM sends update1 and update2. OTrP Agent replays 3761 update2 and update1 again, create unexpected result that client 3762 wants. "dsihash" is used to mitigate this. The TEE MUST make sure 3763 it stores DSI state and checks DSI state matches before it does 3764 another update. 3766 Concurrent calls from TSM to TEE should be handled properly by a TEE. 3767 It is up to the device to manage concurrency to the TEE. If multiple 3768 concurrent TSM operations take place these could fail due "dsihash" 3769 being modified by another concurrent operation. If locking is 3770 implemented on the client, this must be done in such a way that one 3771 application cannot lock other applications from using the TEE, except 3772 for a short term duration of the TSM operation taking place. For 3773 example, an OTrP operation that starts but never completes (e.g. loss 3774 of connectivity) must not prevent subsequent OTrP messages from being 3775 executed. 3777 15.13. Compromised CA 3779 If a root CA for TSM certificates is found compromised, some TEE 3780 trust anchor update mechanism should be devised. A compromised 3781 intermediate CA is covered by OCSP stapling and OCSP validation check 3782 in the protocol. A TEE should validate certificate revocation about 3783 a TSM certificate chain. 3785 If the root CA of some TEE device certificates is compromised, these 3786 devices might be rejected by TSM, which is a decision of TSM 3787 implementation and policy choice. Any intermediate CA for TEE device 3788 certificates should be validated by TSM with common CRL or OCSP 3789 method. 3791 15.14. Compromised TSM 3793 The TEE should use validation of the supplied TSM certificates and 3794 OCSP stapled data to validate that the TSM is trustworthy. 3796 Since PKI is used, the integrity of the clock within the TEE 3797 determines the ability of the TEE to reject an expired TSM 3798 certificate, or revoked TSM certificate. Since OCSP stapling 3799 includes signature generation time, certificate validity dates are 3800 compared to the current time. 3802 15.15. Certificate Renewal 3804 TFW and TEE device certificates are expected to be long lived, longer 3805 than the lifetime of a device. A TSM certificate usually has a 3806 moderate lifetime of 2 to 5 years. TSM should get renewed or rekeyed 3807 certificates.The root CA certificates for TSM, which is embedded into 3808 the trust anchor store in a device, should have long lifetime that 3809 don't require device trust anchor update. On the other hand, it is 3810 imperative that OEM or device providers plan for support of trust 3811 anchor update in their shipped devices. 3813 16. References 3815 16.1. Normative References 3817 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3818 Requirement Levels", BCP 14, RFC 2119, 3819 DOI 10.17487/RFC2119, March 1997, . 3822 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 3823 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 3824 2015, . 3826 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 3827 RFC 7516, DOI 10.17487/RFC7516, May 2015, 3828 . 3830 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 3831 DOI 10.17487/RFC7517, May 2015, . 3834 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 3835 DOI 10.17487/RFC7518, May 2015, . 3838 16.2. Informative References 3840 [GPTEE] Global Platform, "Global Platform, GlobalPlatform Device 3841 Technology: TEE System Architecture, v1.0", 2013. 3843 Appendix A. Sample Messages 3845 A.1. Sample Security Domain Management Messages 3847 A.1.1. Sample GetDeviceState 3849 A.1.1.1. Sample GetDeviceStateRequest 3851 TSM builds a "GetDeviceStateTBSRequest" message. 3853 { 3854 "GetDeviceStateTBSRequest": { 3855 "ver": "1.0", 3856 "rid": "8C6F9DBB-FC39-435c-BC89-4D3614DA2F0B", 3857 "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE", 3858 "ocspdat": "c2FtcGxlIG9jc3BkYXQgQjY0IGVuY29kZWQgQVNOMQ==", 3859 "icaocspdat": "c2FtcGxlIGljYW9jc3BkYXQgQjY0IGVuY29kZWQgQVNOMQ==", 3860 "supportedsigalgs": "RS256" 3861 } 3862 } 3863 TSM signs "GetDeviceStateTBSRequest", creating 3864 "GetDeviceStateRequest" 3866 { 3867 "GetDeviceStateRequest": { 3868 "payload":" 3869 ewoJIkdldERldmljZVN0YXRlVEJTUmVxdWVzdCI6IHsKCQkidmVyIjogIjEuMCIsCgkJ 3870 InJpZCI6IHs4QzZGOURCQi1GQzM5LTQzNWMtQkM4OS00RDM2MTREQTJGMEJ9LAoJCSJ0 3871 aWQiOiAiezRGNDU0QTdGLTAwMkQtNDE1Ny04ODRFLUIwREQxQTA2QThBRX0iLAoJCSJv 3872 Y3NwZGF0IjogImMyRnRjR3hsSUc5amMzQmtZWFFnUWpZMElHVnVZMjlrWldRZ1FWTk9N 3873 UT09IiwKCQkiaWNhb2NzcGRhdCI6ICJjMkZ0Y0d4bElHbGpZVzlqYzNCa1lYUWdRalkw 3874 SUdWdVkyOWtaV1FnUVZOT01RPT0iLAoJCSJzdXBwb3J0ZWRzaWdhbGdzIjogIlJTMjU2 3875 IgoJfQp9", 3876 "protected": "eyJhbGciOiJSUzI1NiJ9", 3877 "header": { 3878 "x5c": ["ZXhhbXBsZSBBU04xIHNpZ25lciBjZXJ0aWZpY2F0ZQ==", 3879 "ZXhhbXBsZSBBU04xIENBIGNlcnRpZmljYXRl"] 3880 }, 3881 "signature":"c2FtcGxlIHNpZ25hdHVyZQ" 3882 } 3883 } 3885 A.1.1.2. Sample GetDeviceStateResponse 3887 TSM sends "GetDeviceStateRequest" to OTrP Agent 3889 OTrP Agent obtains "dsi" from each TEE. (in this example there is a 3890 single TEE). 3892 TEE obtains signed "fwdata" from firmware 3894 TEE builds "dsi" - summarizing device state of TEE 3895 { 3896 "dsi": { 3897 "tfwdata": { 3898 "tbs": "ezRGNDU0QTdGLTAwMkQtNDE1Ny04ODRFLUIwREQxQTA2QThBRX0=", 3899 "cert": "ZXhhbXBsZSBGVyBjZXJ0aWZpY2F0ZQ==", 3900 "sigalg": "RS256", 3901 "sig": "c2FtcGxlIEZXIHNpZ25hdHVyZQ==" 3902 }, 3903 "tee": { 3904 "name": "Primary TEE", 3905 "ver": "1.0", 3906 "cert": "c2FtcGxlIFRFRSBjZXJ0aWZpY2F0ZQ==", 3907 "cacert": [ 3908 "c2FtcGxlIENBIGNlcnRpZmljYXRlIDE=", 3909 "c2FtcGxlIENBIGNlcnRpZmljYXRlIDI=" 3910 ], 3911 "sdlist": { 3912 "cnt": "1", 3913 "sd": [ 3914 { 3915 "name": "default.acmebank.com", 3916 "spid": "acmebank.com", 3917 "talist": [ 3918 { 3919 "taid": "acmebank.secure.banking", 3920 "taname": "Acme secure banking app" 3921 }, 3922 { 3923 "taid": "acmebank.loyalty.rewards", 3924 "taname": "Acme loyalty rewards app" 3925 } 3926 ] 3927 } 3928 ] 3929 }, 3930 "teeaiklist": [ 3931 { 3932 "spaik": "c2FtcGxlIEFTTjEgZW5jb2RlZCBQS0NTMSBwdWJsaWNrZXk=", 3933 "spaiktype": "RSA", 3934 "spid": "acmebank.com" 3935 } 3936 ] 3937 } 3938 } 3939 } 3941 TEE encrypts "dsi", and embeds into "GetDeviceTEEStateTBSResponse" 3942 message 3944 { 3945 "GetDeviceTEEStateTBSResponse": { 3946 "ver": "1.0", 3947 "status": "pass", 3948 "rid": "{8C6F9DBB-FC39-435c-BC89-4D3614DA2F0B}", 3949 "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}", 3950 "signerreq":"false", 3951 "edsi": { 3952 "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0K", 3953 "recipients": [ 3954 { 3955 "header": { 3956 "alg": "RSA1_5" 3957 }, 3958 "encrypted_key": 3959 " 3960 QUVTMTI4IChDRUspIGtleSwgZW5jcnlwdGVkIHdpdGggVFNNIFJTQSBwdWJsaWMg 3961 a2V5LCB1c2luZyBSU0ExXzUgcGFkZGluZw" 3962 } 3963 ], 3964 "iv": "ySGmfZ69YlcEilNr5_SGbA", 3965 "ciphertext": 3966 " 3967 c2FtcGxlIGRzaSBkYXRhIGVuY3J5cHRlZCB3aXRoIEFFUzEyOCBrZXkgZnJvbSByZW 3968 NpcGllbnRzLmVuY3J5cHRlZF9rZXk", 3969 "tag": "c2FtcGxlIGF1dGhlbnRpY2F0aW9uIHRhZw" 3970 } 3971 } 3972 } 3974 TEE signs "GetDeviceTEEStateTBSResponse" and returns to OTrP Agent. 3975 OTrP Agent encodes "GetDeviceTEEStateResponse" into an array to form 3976 "GetDeviceStateResponse" 3978 { 3979 "GetDeviceStateResponse": [ 3980 { 3981 "GetDeviceTEEStateResponse": { 3982 "payload": 3983 " 3984 ewogICJHZXREZXZpY2VURUVTdGF0ZVRCU1Jlc3BvbnNlIjogewogICAgInZlciI6 3985 ICIxLjAiLAogICAgInN0YXR1cyI6ICJwYXNzIiwKICAgICJyaWQiOiAiezhDNkY5 3986 REJCLUZDMzktNDM1Yy1CQzg5LTREMzYxNERBMkYwQn0iLAogICAgInRpZCI6ICJ7 3987 NEY0NTRBN0YtMDAyRC00MTU3LTg4NEUtQjBERDFBMDZBOEFFfSIsCgkic2lnbmVy 3988 cmVxIjoiZmFsc2UiLAogICAgImVkc2kiOiB7CiAgICAgICJwcm90ZWN0ZWQiOiAi 3989 ZXlKbGJtTWlPaUpCTVRJNFEwSkRMVWhUTWpVMkluMEsiLAogICAgICAicmVjaXBp 3990 ZW50cyI6IFsKICAgICAgICB7CiAgICAgICAgICAiaGVhZGVyIjogewogICAgICAg 3991 ICAgImFsZyI6ICJSU0ExXzUiCiAgICAgICAgfSwKICAgICAgICAiZW5jcnlwdGVk 3992 X2tleSI6CiAgICAgICAgIgogICAgICAgIFFVVlRNVEk0SUNoRFJVc3BJR3RsZVN3 3993 Z1pXNWpjbmx3ZEdWa0lIZHBkR2dnVkZOTklGSlRRU0J3ZFdKc2FXTWcKICAgICAg 3994 ICBhMlY1TENCMWMybHVaeUJTVTBFeFh6VWdjR0ZrWkdsdVp3IgogICAgICAgIH0K 3995 ICAgICAgXSwKICAgICAgIml2IjogInlTR21mWjY5WWxjRWlsTnI1X1NHYkEiLAog 3996 ICAgICAiY2lwaGVydGV4dCI6CiAgICAgICIKICAgICAgYzJGdGNHeGxJR1J6YVNC 3997 a1lYUmhJR1Z1WTNKNWNIUmxaQ0IzYVhSb0lFRkZVekV5T0NCclpYa2dabkp2YlNC 3998 eVpXCiAgICAgIE5wY0dsbGJuUnpMbVZ1WTNKNWNIUmxaRjlyWlhrIiwKICAgICAg 3999 InRhZyI6ICJjMkZ0Y0d4bElHRjFkR2hsYm5ScFkyRjBhVzl1SUhSaFp3IgogICAg 4000 fQogIH0KfQ", 4001 "protected": "eyJhbGciOiJSUzI1NiJ9", 4002 "signature": "c2FtcGxlIHNpZ25hdHVyZQ" 4003 } 4004 } 4005 ] 4006 } 4008 TEE returns "GetDeviceStateResponse" back to OTrP Agent, which 4009 returns message back to TSM. 4011 A.1.2. Sample CreateSD 4013 A.1.2.1. Sample CreateSDRequest 4014 { 4015 "CreateSDTBSRequest": { 4016 "ver":"1.0", 4017 "rid":"req-01", 4018 "tid":"tran-01", 4019 "tee":"SecuriTEE", 4020 "nextdsi":"false", 4021 "dsihash":"Iu-c0-fGrpMmzbbtiWI1U8u7wMJE7IK8wkJpsVuf2js", 4022 "content":{ 4023 "spid":"bank.com", 4024 "sdname":"sd.bank.com", 4025 "spcert":"MIIDFjCCAn- 4026 gAwIBAgIJAIk0Tat0tquDMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNVBAYTAktSMQ4wD 4027 AYDVQQIDAVTZW91bDESMBAGA1UEBwwJR3Vyby1kb25nMRAwDgYDVQQKDAdTb2xhY2l 4028 hMRAwDgYDVQQLDAdTb2xhY2lhMRUwEwYDVQQDDAxTb2xhLWNpYS5jb20wHhcNMTUwN 4029 zAyMDg1MTU3WhcNMjAwNjMwMDg1MTU3WjBsMQswCQYDVQQGEwJLUjEOMAwGA1UECAw 4030 FU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU29sYWNpYTEQMA4GA 4031 1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tMIGfMA0GCSqGSIb3DQE 4032 BAQUAA4GNADCBiQKBgQDYWLrFf2OFMEciwSYsyhaLY4kslaWcXA0hCWJRaFzt5mU- 4033 lpSJ4jeu92inBbsXcI8PfRbaItsgW1TD1Wg4gQH4MX_YtaBoOepE-- 4034 3JoZZyPyCWS3AaLYWrDmqFXdbzaO1i8GxB7zz0gWw55bZ9jyzcl5gQzWSqMRpx_dca 4035 d2SP2wIDAQABo4G_MIG8MIGGBgNVHSMEfzB9oXCkbjBsMQswCQYDVQQGEwJLUjEOMA 4036 wGA1UECAwFU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU29sYWNp 4037 YTEQMA4GA1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tggkAiTRNq3 4038 S2q4MwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0lAQH_BAwwCgYIKwYB 4039 BQUHAwMwDQYJKoZIhvcNAQEFBQADgYEAEFMhRwEQ- 4040 LDa9O7P1N0mcLORpo6fW3QuJfuXbRQRQGoXddXMKazI4VjbGaXhey7Bzvk6TZYDa- 4041 GRiZby1J47UPaDQR3UiDzVvXwCOU6S5yUhNJsW_BeMViYj4lssX28iPpNwLUCVm1QV 4042 THILI6afLCRWXXclc1L5KGY290OwIdQ", 4043 "tsmid":"tsm_x.acme.com", 4044 "did":"zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM" 4045 } 4046 } 4047 } 4049 Here is a sample message after the content is encrypted and encoded 4051 { 4052 "CreateSDRequest": { 4053 "payload":" 4054 eyJDcmVhdGVTRFRCU1JlcXVlc3QiOnsidmVyIjoiMS4wIiwicmlkIjoicmVxLTAxIiwidG 4055 lkIjoidHJhbi0wMSIsInRlZSI6IlNlY3VyaVRFRSIsIm5leHRkc2kiOiJmYWxzZSIsImRz 4056 aWhhc2giOiIyMmVmOWNkM2U3YzZhZTkzMjZjZGI2ZWQ4OTYyMzU1M2NiYmJjMGMyNDRlYz 4057 gyYmNjMjQyNjliMTViOWZkYTNiIiwiY29udGVudCI6eyJwcm90ZWN0ZWQiOiJlLUtBbkdW 4058 dVktS0FuVHJpZ0p4Qk1USTRRMEpETFVoVE1qVTI0b0NkZlEiLCJyZWNpcGllbnRzIjpbey 4059 JoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0sImVuY3J5cHRlZF9rZXkiOiJTUzE2NTl4Q2FJ 4060 c1dUeUlsVTZPLUVsZzU4UUhvT1pCekxVRGptVG9vanBaWE54TVpBakRMcWtaSTdEUzhOVG 4061 FIWHcxczFvZjgydVhsM0d6NlVWMkRoZDJ3R2l6Y2VEdGtXc1RwZDg4QVYwaWpEYTNXa3lk 4062 dEpSVmlPOGdkSlEtV29NSUVJRUxzVGthblZCb25wQkF4ZHE0ckVMbl9TZlliaFg4Zm9ub2 4063 gxUVUifV0sIml2IjoiQXhZOERDdERhR2xzYkdsamIzUm9aUSIsImNpcGhlcnRleHQiOiI1 4064 bmVWZXdndm55UXprR3hZeWw5QlFrZTJVNjVaOHp4NDdlb3NzM3FETy0xY2FfNEpFY3NLcj 4065 ZhNjF5QzBUb0doYnJOQWJXbVRSemMwSXB5bTF0ZjdGemp4UlhBaTZBYnVSM2gzSUpRS1Bj 4066 UUVvRUlkZ2tWX0NaZTM2eTBkVDBpRFBMclg0QzFkb0dmMEdvaWViRC1yVUg1VUtEY3BsTW 4067 9lTjZvUnFyd0dnNUhxLTJXM3B4MUlzY0h4SktRZm11dkYxMTJ4ajBmZFNZX0N2WFE1NTJr 4068 TVRDUW1ZbzRPaGF2R0ZvaG9TZVVnaGZSVG1LYWp3OThkTzdhREdrUEpRUlBtYVVHWllEMW 4069 JXd01nMXFRV3RPd19EZlIyZDNzTzVUN0pQMDJDUFprVXBiQ3dZYVcybW9HN1c2Zlc2U3V5 4070 Q2lpd2pQWmZSQmIzSktTVTFTd1kxYXZvdW02OWctaDB6by12TGZvbHRrWFV2LVdPTXZTY0 4071 JzR25NRzZYZnMzbXlTWnJ1WTNRR09wVVRzdjFCQ0JqSTJpdjkwb2U2aXFCcVpxQVBxbzdi 4072 ajYwVlJGQzZPTlNLZExGQTIyU3pqRHo1dmtnTXNEaHkwSzlDeVhYN1Z6MkNLTXJvQjNiUE 4073 xFZF9abTZuVWlkTFN5cVJ5cXJxTmVnN1lmQng3aV93X0dzRW9rX1VYZXd6RGtneHp6RjZj 4074 XzZ6S0s3UFktVnVmYUo0Z2dHZmlpOHEwMm9RZ1VEZTB2Vm1FWDc0c2VQX2RxakVpZVVOYm 4075 xBZE9sS2dBWlFGdEs4dy1xVUMzSzVGTjRoUG9yeDc2b3lPVUpOQTVFZVV2Qy1jR2tMcTNQ 4076 UG1GRmQyaUtOTElCTEJzVWl6c1h3RERvZVA5SmktWGt5ZEQtREN1SHdpcno0OEdNNWVLSj 4077 Q5WVdqRUtFQko2T01NNUNmZHZ4cDNmVG1uUTdfTXcwZ3FZVDRiOUJJSnBfWjA3TTctNUpE 4078 emg0czhyU3dsQzFXU3V2RmhRWlJCcXJtX2RaUlRIb0VaZldXc1VCSWVNWWdxNG1zb0JqTj 4079 NXSzhnRWYwZGI5a3Z6UG9LYmpJRy10UUE2R2l1X3pHaFVfLXFBV1lLemVKMDZ6djRIWlBO 4080 dHktQXRyTGF0WGhtUTdOQlVrX0hvbjdOUWxhU1g1ZHVNVmN4bGs1ZHVrWFZNMDgxa09wYV 4081 kzbDliQVFfYVhTM0FNaFFTTVVsT3dnTDZJazFPYVpaTGFMLUE3ejlITnlESmFEWTVhakZK 4082 TWFDV1lfOG94YlNoQUktNXA2MmNuT0xzV0dNWWNKTlBGVTZpcWlMR19oc3JfNlNKMURhbD 4083 VtQ0YycnBJLUItMlhuckxZR01ZS0NEZ2V2dGFnbi1DVUV6RURwR3ozQ2VLcWdQU0Vqd3BK 4084 N0M3NXduYTlCSmtTUkpOdDNla3hoWElrcnNEazRHVVpMSDdQYzFYZHdRTXhxdWpzNmxJSV 4085 EycjM1NWEtVkotWHdPcFpfY3RPdW96LTA4WHdYQ3RkTEliSFFVTG40RjlMRTRtanU0dUxS 4086 bjNSc043WWZ1S3dCVmVEZDJ6R3NBY0s5SVlDa3hOaDk3dDluYW1iMDZqSXVoWXF5QkhWRU 4087 9nTkhici1rMDY1bW9OVk5lVVUyMm5OdVNKS0ZxVnIxT0dKNGVfNXkzYkNwTmxTeEFPV1Bn 4088 RnJzU0Flc2JJOWw4eVJtVTAwenJYdGc4OWt5SjlCcXN2eXA1RE8wX2FtS1JyMXB1MVJVWF 4089 lFZzB2ampKS1FSdDVZbXRUNFJzaWpqdGRDWDg3UUxJaUdSY0hDdlJzUzZSdDJESmNYR1ht 4090 UGQyc0ZmNUZyNnJnMkFzX3BmUHN3cnF1WlAxbVFLc3RPMFVkTXpqMTlyb2N1NHVxVXlHUD 4091 lWWU54cHVnWVdNSjRYb1dRelJtWGNTUEJ4VEtnenFPS2s3UnRzWWVMNXl4LVM4NjV0cHVz 4092 dTA0bXpzYUJRZ21od1ZFVXBRdWNrcG1YWkNLNHlJUXktaHNFQUlJSmVxdFB3dVAySXF0X2 4093 I5dlk0bzExeXdzeXhzdmp2RnNKN0VVZU1MaGE2R2dSanBSbnU5RWIzRnlJZ0U5M0VVNEEw 4094 T0lUMWlOSGNRYWc0eWtOc3dPdkxQbjZIZ21zQ05ESlgwekc2RlFDMTZRdjBSQ25SVTdfV2 4095 VvblhSTUZwUzZRZ1JiSk45R1NMckN5bklJSWxUcDBxNHBaS05zM0tqQ2tMUzJrb3Bhd2Y0 4096 WF9BUllmTko3a0s5eW5BR0dCcktnUWJNRWVxUEFmMDBKMlYtVXpuU1JMZmQ4SGs3Y2JEdk 4097 5RQlhHQW9BR0ViaGRwVUc0RXFwMlVyQko3dEtyUUVSRlh4RTVsOFNHY2czQ1RmN2Zoazdx 4098 VEFBVjVsWEFnOUtOUDF1c1ZRZk1fUlBleHFNTG9WQVVKV2syQkF6WF9uSEhkVVhaSVBIOG 4099 hLeDctdEFRV0dTWUd0R2FmanZJZzI2c082TzloQWZVd3BpSV90MzF6SkZORDU0OTZURHBz 4100 QmNnd2dMLU1UcVhCRUJ2NEhvQld5SG1DVjVFMUwiLCJ0YWciOiJkbXlEeWZJVlNJUi1Ren 4101 ExOEgybFRIeEMxbl9HZEtrdnZNMDJUcHdsYzQwIn19fQ", 4102 "protected":"e-KAnGFsZ-KAnTrigJxSUzI1NuKAnX0", //RSAwithSHA256 4103 "header": { 4104 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4105 "signer":" 4106 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA 4107 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4108 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh 4109 cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p 4110 YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy 4111 BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4112 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4113 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3 4114 c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4115 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA 4116 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4117 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR 4118 MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq 4119 hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G 4120 SZ1MdyIZV8fwdEmD90IvtMHgtzK- 4121 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA 4122 UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4123 }, 4124 "signature":"nuQUsCTEBLeaRzuwd7q1iPIYEJ2eJfurO5sT5Y- 4125 N03zFRcv1jvrqMHtx_pw0Y9YWjmpoWfpfelhwGEko9SgeeBnznmkZbp7kjS6MmX4CKz 4126 9OApe3-VI7yL9Yp0WNdRh3425eYfuapCy3lcXFln5JBAUnU_OzUg3RWxcU_yGnFsw" 4127 } 4128 } 4130 A.1.2.2. Sample CreateSDResponse 4132 { 4133 "CreateSDTBSResponse": { 4134 "ver":"1.0", 4135 "status":"pass", 4136 "rid":"req-01", 4137 "tid":"tran-01", 4138 "content":{ 4139 "did":"zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM", 4140 "sdname":"sd.bank.com", 4141 "teespaik":"AQABjY9KiwH3hkMmSAAN6CLXot525U85WNlWKAQz5TOdfe_CM8h- 4142 X6_EHX1gOXoyRXaBiKMqWb0YZLCABTw1ytdXy2kWa525imRho8Vqn6HDGsJDZPDru9 4143 GnZR8pZX5ge_dWXB_uljMvDttc5iAWEJ8ZgcpLGtBTGLZnQoQbjtn1lIE", 4144 } 4145 } 4146 } 4148 Here is the response message after the content is encrypted and 4149 encoded. 4151 { 4152 "CreateSDResponse": { 4153 "payload":" 4154 eyJDcmVhdGVTRFRCU1Jlc3BvbnNlIjp7InZlciI6IjEuMCIsInN0YXR1cyI6InBhc3Mi 4155 LCJyaWQiOiJyZXEtMDEiLCJ0aWQiOiJ0cmFuLTAxIiwiY29udGVudCI6eyJwcm90ZWN0 4156 ZWQiOiJlLUtBbkdWdVktS0FuVHJpZ0p4Qk1USTRRMEpETFVoVE1qVTI0b0NkZlEiLCJy 4157 ZWNpcGllbnRzIjpbeyJoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0sImVuY3J5cHRlZF9r 4158 ZXkiOiJOX0I4R3pldUlfN2hwd0wwTFpHSTkxVWVBbmxJRkJfcndmZU1yZERrWnFGak1s 4159 VVhjdlI0XzhhOGhyeFI4SXR3aEtFZnVfRWVLRDBQb0dqQ2pCSHcxdG1ULUN6eWhsbW5v 4160 Slk3LXllWnZzRkRpc2VNTkd0eGE0OGZJYUs2VWx5NUZMYXBCZVc5T1I5bmktOU9GQV9j 4161 aFVuWWl3b2Q4ZTJFa0Vpd0JEZ1EzMk0ifV0sIml2IjoiQXhZOERDdERhR2xzYkdsamIz 4162 Um9aUSIsImNpcGhlcnRleHQiOiJsalh6Wk5JTmR1WjFaMXJHVElkTjBiVUp1RDRVV2xT 4163 QVptLWd6YnJINFVDYy1jMEFQenMtMWdWSFk4NTRUR3VMYkdyRmVHcDFqM2Fsb1lacWZp 4164 ZnE4aEt3Ty16RFlBN2tmVFhBZHp6czM4em9xeG4zbHoyM2w1RUlGUWhrOHBRWTRYTHRW 4165 M3ZBQWlNYnlrQ1Q3VS1CWDdWcjBacVNhYWZTQVZ4OFBLQ1RIU3hHN3hHVko0NkxxRzJS 4166 RE54WXQ4RC1SQ3lZUi1zRTM0MUFKZldEc2FLaGRRbzJXcjNVN1hTOWFqaXJtWjdqTlJ4 4167 cVRodHJBRWlIY1ctOEJMdVFHWEZ1YUhLMTZrenJKUGl4d0VXbzJ4cmw4cmkwc3ZRcHpl 4168 Z2M3MEt2Z0I0NUVaNHZiNXR0YlUya25hN185QU1Wcm4wLUJaQ1Bnb280MWlFblhuNVJn 4169 TXY2c2V2Y1JPQ2xHMnpWSjFoRkVLYjk2akEiLCJ0YWciOiIzOTZISTk4Uk1NQnR0eDlo 4170 ZUtsODROaVZLd0lJSzI0UEt2Z1RGYzFrbEJzIn19fQ", 4171 "protected": "e-KAnGFsZ-KAnTrigJxSUzI1NuKAnX0", 4172 "header": { 4173 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4174 "signer":" 4175 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJ 4176 BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp 4177 Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcN 4178 MTUwNzAyMDkwMTE4WhcNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzET 4179 MBEGA1UECAwKQ2FsaWZvcm5pYTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8G 4180 A1UECgwYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIGfMA0GCSqGSIb3DQEB 4181 AQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4182 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4183 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA 4184 6b_ZI3c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4185 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJ 4186 BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp 4187 Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX 4188 9nxZBNQWDjAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8E 4189 DDAKBggrBgEFBQcDAzANBgkqhkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4iv 4190 em4cIckfxzTBBiPHCjrrjB2X8Ktn8GSZ1MdyIZV8fwdEmD90IvtMHgtzK- 4191 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fV 4192 rJvnYAUBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4193 }, 4194 "signature":"jnJtaB0vFFwrE-qKOR3Pu9pf2gNoI1s67GgPCTq0U- 4195 qrz97svKpuh32WgCP2MWCoQPEswsEX-nxhIx_siTe4zIPO1nBYn- 4196 R7b25rQaF87O8uAOOnBN5Yl2Jk3laIbs- 4197 hGE32aRZDhrVoyEdSvIFrT6AQqD20bIAZGqTR-zA-900" 4198 } 4199 } 4201 A.1.3. Sample UpdateSD 4202 A.1.3.1. Sample UpdateSDRequest 4204 { 4205 "UpdateSDTBSRequest": { 4206 "ver": "1.0", 4207 "rid": "1222DA7D-8993-41A4-AC02-8A2807B31A3A", 4208 "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE", 4209 "tee": "Primary TEE ABC", 4210 "nextdsi": "false", 4211 "dsihash": 4212 " 4213 IsOvwpzDk8Onw4bCrsKTJsONwrbDrcKJYjVTw4vCu8OAw4JEw6zCgsK8w4JCacKxW8Kf 4214 w5o7", 4215 "content": { // NEEDS to BE ENCRYPTED 4216 "tsmid": "id1.tsmxyz.com", 4217 "spid": "com.acmebank.spid1", 4218 "sdname": "com.acmebank.sdname1", 4219 "changes": { 4220 "newsdname": "com.acmebank.sdname2", 4221 "newspid": "com.acquirer.spid1", 4222 "spcert": 4223 "MIIDFjCCAn- 4224 gAwIBAgIJAIk0Tat0tquDMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNVBAYTAktSMQ4 4225 wDAYDVQQIDAVTZW91bDESMBAGA1UEBwwJR3Vyby1kb25nMRAwDgYDVQQKDAdTb2x 4226 hY2lhMRAwDgYDVQQLDAdTb2xhY2lhMRUwEwYDVQQDDAxTb2xhLWNpYS5jb20wHhc 4227 NMTUwNzAyMDg1MTU3WhcNMjAwNjMwMDg1MTU3WjBsMQswCQYDVQQGEwJLUjEOMAw 4228 GA1UECAwFU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU29sYWN 4229 pYTEQMA4GA1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tMIGfMA0 4230 GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDYWLrFf2OFMEciwSYsyhaLY4kslaWcXA0 4231 hCWJRaFzt5mU- 4232 lpSJ4jeu92inBbsXcI8PfRbaItsgW1TD1Wg4gQH4MX_YtaBoOepE-- 4233 3JoZZyPyCWS3AaLYWrDmqFXdbzaO1i8GxB7zz0gWw55bZ9jyzcl5gQzWSqMRpx_d 4234 cad2SP2wIDAQABo4G_MIG8MIGGBgNVHSMEfzB9oXCkbjBsMQswCQYDVQQGEwJLUj 4235 EOMAwGA1UECAwFU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU2 4236 9sYWNpYTEQMA4GA1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tgg 4237 kAiTRNq3S2q4MwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0lAQH_BA 4238 wwCgYIKwYBBQUHAwMwDQYJKoZIhvcNAQEFBQADgYEAEFMhRwEQ- 4239 LDa9O7P1N0mcLORpo6fW3QuJfuXbRQRQGoXddXMKazI4VjbGaXhey7Bzvk6TZYDa 4240 - 4241 GRiZby1J47UPaDQR3UiDzVvXwCOU6S5yUhNJsW_BeMViYj4lssX28iPpNwLUCVm1 4242 QVTHILI6afLCRWXXclc1L5KGY290OwIdQ", 4243 "renewteespaik": "0" 4244 } 4245 } 4246 } 4247 } 4248 A.1.3.2. Sample UpdateSDResponse 4250 { 4251 "UpdateSDTBSResponse": { 4252 "ver": "1.0", 4253 "status": "pass", 4254 "rid": "1222DA7D-8993-41A4-AC02-8A2807B31A3A", 4255 "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE", 4256 "content": { 4257 "did": "MTZENTE5Qzc0Qzk0NkUxMzYxNzk0NjY4NTc3OTY4NTI=", 4258 "teespaik": 4259 "AQABjY9KiwH3hkMmSAAN6CLXot525U85WNlWKAQz5TOdfe_CM8h- 4260 X6_EHX1gOXoyRXaBiKMqWb0YZLCABTw1ytdXy2kWa525imRho8Vqn6HDGsJDZPDru9 4261 GnZR8pZX5ge_dWXB_uljMvDttc5iAWEJ8ZgcpLGtBTGLZnQoQbjtn1lIE", 4262 "teespaiktype": "RSA" 4263 } 4264 } 4265 } 4267 A.1.4. Sample DeleteSD 4269 A.1.4.1. Sample DeleteSDRequest 4271 TSM builds message - including data to be encrypted. 4273 { 4274 "DeleteSDTBSRequest": { 4275 "ver": "1.0", 4276 "rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}", 4277 "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}", 4278 "tee": "Primary TEE", 4279 "nextdsi": "false", 4280 "dsihash": "AAECAwQFBgcICQoLDA0ODwABAgMEBQYHCAkKCwwNDg8=", 4281 "content": ENCRYPTED { 4282 "tsmid": "tsm1.com", 4283 "sdname": "default.acmebank.com", 4284 "deleteta": "1" 4285 } 4286 } 4287 } 4289 TSM encrypts the "content". 4291 { 4292 "DeleteSDTBSRequest": { 4293 "ver": "1.0", 4294 "rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}", 4295 "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}", 4296 "tee": "Primary TEE", 4297 "nextdsi": "false", 4298 "dsihash": "AAECAwQFBgcICQoLDA0ODwABAgMEBQYHCAkKCwwNDg8=", 4299 "content": { 4300 "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0", 4301 "recipients": [ 4302 { 4303 "header": { 4304 "alg": "RSA1_5" 4305 }, 4306 "encrypted_key": 4307 " 4308 QUVTMTI4IChDRUspIGtleSwgZW5jcnlwdGVkIHdpdGggVFNNIFJTQSBwdWJsaWMga2 4309 V5LCB1c2luZyBSU0ExXzUgcGFkZGluZw" 4310 } 4311 ], 4312 "iv": "rWO5DVmQX9ogelMLBIogIA", 4313 "ciphertext": 4314 " 4315 c2FtcGxlIGRzaSBkYXRhIGVuY3J5cHRlZCB3aXRoIEFFUzEyOCBrZXkgZnJvbSByZWNp 4316 cGllbnRzLmVuY3J5cHRlZF9rZXk", 4317 "tag": "c2FtcGxlIGF1dGhlbnRpY2F0aW9uIHRhZw" 4318 } 4319 } 4320 } 4322 TSM signs "DeleteSDTBSRequest" to form "DeleteSDRequest" 4323 { 4324 "DeleteSDRequest": { 4325 "payload":" 4326 ewoJIkRlbGV0ZVNEVEJTUmVxdWVzdCI6IHsKCQkidmVyIjogIjEuMCIsCgkJInJp 4327 ZCI6ICJ7NzEyNTUxRjUtREZCMy00M2YwLTlBNjMtNjYzNDQwQjkxRDQ5fSIsCgkJ 4328 InRpZCI6ICJ7NEY0NTRBN0YtMDAyRC00MTU3LTg4NEUtQjBERDFBMDZBOEFFfSIs 4329 CgkJInRlZSI6ICJQcmltYXJ5IFRFRSIsCgkJIm5leHRkc2kiOiAiZmFsc2UiLAoJ 4330 CSJkc2loYXNoIjogIkFBRUNBd1FGQmdjSUNRb0xEQTBPRHdBQkFnTUVCUVlIQ0Fr 4331 S0N3d05EZzg9IiwKCQkiY29udGVudCI6IHsKCQkJInByb3RlY3RlZCI6ICJleUps 4332 Ym1NaU9pSkJNVEk0UTBKRExVaFRNalUySW4wIiwKCQkJInJlY2lwaWVudHMiOiBb 4333 ewoJCQkJImhlYWRlciI6IHsKCQkJCQkiYWxnIjogIlJTQTFfNSIKCQkJCX0sCgkJ 4334 CQkiZW5jcnlwdGVkX2tleSI6ICJRVVZUTVRJNElDaERSVXNwSUd0bGVTd2daVzVq 4335 Y25sd2RHVmtJSGRwZEdnZ1ZGTk5JRkpUUVNCd2RXSnNhV01nYTJWNUxDQjFjMmx1 4336 WnlCU1UwRXhYelVnY0dGa1pHbHVadyIKCQkJfV0sCgkJCSJpdiI6ICJyV081RFZt 4337 UVg5b2dlbE1MQklvZ0lBIiwKCQkJImNpcGhlcnRleHQiOiAiYzJGdGNHeGxJR1J6 4338 YVNCa1lYUmhJR1Z1WTNKNWNIUmxaQ0IzYVhSb0lFRkZVekV5T0NCclpYa2dabkp2 4339 YlNCeVpXTnBjR2xsYm5SekxtVnVZM0o1Y0hSbFpGOXJaWGsiLAoJCQkidGFnIjog 4340 ImMyRnRjR3hsSUdGMWRHaGxiblJwWTJGMGFXOXVJSFJoWnciCgkJfQoJfQp9", 4341 "protected":"eyJhbGciOiJSUzI1NiJ9", 4342 "header": { 4343 "x5c": ["ZXhhbXBsZSBBU04xIHNpZ25lciBjZXJ0aWZpY2F0ZQ==", 4344 "ZXhhbXBsZSBBU04xIENBIGNlcnRpZmljYXRl"] 4345 }, 4346 "signature":"c2FtcGxlIHNpZ25hdHVyZQ" 4347 } 4348 } 4350 A.1.4.2. Sample DeleteSDResponse 4352 TEE creates "DeleteSDTBSResponse" to respond to the "DeleteSDRequest" 4353 message from the TSM, including data to be encrypted. 4355 { 4356 "DeleteSDTBSResponse": { 4357 "ver": "1.0", 4358 "status": "pass", 4359 "rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}", 4360 "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}", 4361 "content": ENCRYPTED { 4362 "did": "MTZENTE5Qzc0Qzk0NkUxMzYxNzk0NjY4NTc3OTY4NTI=", 4363 } 4364 } 4365 } 4367 TEE encrypts the "content" for the TSM. 4369 { 4370 "DeleteSDTBSResponse": { 4371 "ver": "1.0", 4372 "status": "pass", 4373 "rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}", 4374 "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}", 4375 "content": { 4376 "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0K", 4377 "recipients": [ 4378 { 4379 "header": { 4380 "alg": "RSA1_5" 4381 }, 4382 "encrypted_key": 4383 " 4384 QUVTMTI4IChDRUspIGtleSwgZW5jcnlwdGVkIHdpdGggVFNNIFJTQSBwdWJsaWMg 4385 a2V5LCB1c2luZyBSU0ExXzUgcGFkZGluZw" 4386 } 4387 ], 4388 "iv": "ySGmfZ69YlcEilNr5_SGbA", 4389 "ciphertext": 4390 " 4391 c2FtcGxlIGRzaSBkYXRhIGVuY3J5cHRlZCB3aXRoIEFFUzEyOCBrZXkgZnJvbSByZW 4392 NpcGllbnRzLmVuY3J5cHRlZF9rZXk", 4393 "tag": "c2FtcGxlIGF1dGhlbnRpY2F0aW9uIHRhZw" 4394 } 4395 } 4396 } 4398 TEE signs "DeleteSDTBSResponse" to form "DeleteSDResponse" 4399 { 4400 "DeleteSDResponse": { 4401 "payload":" 4402 ewoJIkRlbGV0ZVNEVEJTUmVzcG9uc2UiOiB7CgkJInZlciI6ICIxLjAiLAoJCSJz 4403 dGF0dXMiOiAicGFzcyIsCgkJInJpZCI6ICJ7NzEyNTUxRjUtREZCMy00M2YwLTlB 4404 NjMtNjYzNDQwQjkxRDQ5fSIsCgkJInRpZCI6ICJ7NEY0NTRBN0YtMDAyRC00MTU3 4405 LTg4NEUtQjBERDFBMDZBOEFFfSIsCgkJImNvbnRlbnQiOiB7CgkJCSJwcm90ZWN0 4406 ZWQiOiAiZXlKbGJtTWlPaUpCTVRJNFEwSkRMVWhUTWpVMkluMEsiLAoJCQkicmVj 4407 aXBpZW50cyI6IFt7CgkJCQkiaGVhZGVyIjogewoJCQkJCSJhbGciOiAiUlNBMV81 4408 IgoJCQkJfSwKCQkJCSJlbmNyeXB0ZWRfa2V5IjogIlFVVlRNVEk0SUNoRFJVc3BJ 4409 R3RsZVN3Z1pXNWpjbmx3ZEdWa0lIZHBkR2dnVkZOTklGSlRRU0J3ZFdKc2FXTWdh 4410 MlY1TENCMWMybHVaeUJTVTBFeFh6VWdjR0ZrWkdsdVp3IgoJCQl9XSwKCQkJIml2 4411 IjogInlTR21mWjY5WWxjRWlsTnI1X1NHYkEiLAoJCQkiY2lwaGVydGV4dCI6ICJj 4412 MkZ0Y0d4bElHUnphU0JrWVhSaElHVnVZM0o1Y0hSbFpDQjNhWFJvSUVGRlV6RXlP 4413 Q0JyWlhrZ1puSnZiU0J5WldOcGNHbGxiblJ6TG1WdVkzSjVjSFJsWkY5clpYayIs 4414 CgkJCSJ0YWciOiAiYzJGdGNHeGxJR0YxZEdobGJuUnBZMkYwYVc5dUlIUmhadyIK 4415 CQl9Cgl9Cn0", 4416 "protected":"eyJhbGciOiJSUzI1NiJ9", 4417 "signature":"c2FtcGxlIHNpZ25hdHVyZQ" 4418 } 4419 } 4421 TEE returns "DeleteSDResponse" back to OTrP Agent, which returns 4422 message back to TSM. 4424 A.2. Sample TA Management Messages 4426 A.2.1. Sample InstallTA 4428 A.2.1.1. Sample InstallTARequest 4429 { 4430 "InstallTATBSRequest": { 4431 "ver": "1.0", 4432 "rid": "24BEB059-0AED-42A6-A381-817DFB7A1207", 4433 "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE", 4434 "tee": "Primary TEE ABC", 4435 "nextdsi": "true", 4436 "dsihash": 4437 " 4438 IsOvwpzDk8Onw4bCrsKTJsONwrbDrcKJYjVTw4vCu8OAw4JEw6zCgsK8w4JCacKxW8Kf 4439 w5o7", 4440 "content": { 4441 "tsmid": "id1.tsmxyz.com", 4442 "spid": "com.acmebank.spid1", 4443 "sdname": "com.acmebank.sdname1", 4444 "taid": "com.acmebank.taid.banking" 4445 }, 4446 "encrypted_ta": { 4447 "key": 4448 "mLBjodcE4j36y64nC/nEs694P3XrLAOokjisXIGfs0H7lOEmT5FtaNDYEMcg9RnE 4449 ftlJGHO7N0lgcNcjoXBmeuY9VI8xzrsZM9gzH6VBKtVONSx0aw5IAFkNcyPZwDdZ 4450 MLwhvrzPJ9Fg+bZtrCoJz18PUz+5aNl/dj8+NM85LCXXcBlZF74btJer1Mw6ffzT 4451 /grPiEQTeJ1nEm9F3tyRsvcTInsnPJ3dEXv7sJXMrhRKAeZsqKzGX4eiZ3rEY+FQ 4452 6nXULC8cAj5XTKpQ/EkZ/iGgS0zcXR7KUJv3wFEmtBtPD/+ze08NILLmxM8olQFj 4453 //Lq0gGtq8vPC8r0oOfmbQ==", 4454 "iv": "4F5472504973426F726E496E32303135", 4455 "alg": "AESCBC", 4456 "ciphertadata": 4457 "......0x/5KGCXWfg1Vrjm7zPVZqtYZ2EovBow+7EmfOJ1tbk......=", 4458 "cipherpdata": "0x/5KGCXWfg1Vrjm7zPVZqtYZ2EovBow+7EmfOJ1tbk=" 4459 } 4460 } 4461 } 4463 A.2.1.2. Sample InstallTAResponse 4465 A sample to-be-signed response of InstallTA looks as follows. 4467 { 4468 "InstallTATBSResponse": { 4469 "ver": "1.0", 4470 "status": "pass", 4471 "rid": "24BEB059-0AED-42A6-A381-817DFB7A1207", 4472 "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE", 4473 "content": { 4474 "did": "MTZENTE5Qzc0Qzk0NkUxMzYxNzk0NjY4NTc3OTY4NTI=", 4475 "dsi": { 4476 "tfwdata": { 4477 "tbs": "ezRGNDU0QTdGLTAwMkQtNDE1Ny04ODRFLUIwREQxQTA2QThBRX0=" 4478 "cert": "ZXhhbXBsZSBGVyBjZXJ0aWZpY2F0ZQ==", 4479 "sigalg": "UlMyNTY=", 4480 "sig": "c2FtcGxlIEZXIHNpZ25hdHVyZQ==" 4481 }, 4482 "tee": { 4483 "name": "Primary TEE", 4484 "ver": "1.0", 4485 "cert": "c2FtcGxlIFRFRSBjZXJ0aWZpY2F0ZQ==", 4486 "cacert": [ 4487 "c2FtcGxlIENBIGNlcnRpZmljYXRlIDE=", 4488 "c2FtcGxlIENBIGNlcnRpZmljYXRlIDI=" 4489 ], 4490 "sdlist": { 4491 "cnt": "1", 4492 "sd": [ 4493 { 4494 "name": "com.acmebank.sdname1", 4495 "spid": "com.acmebank.spid1", 4496 "talist": [ 4497 { 4498 "taid": "com.acmebank.taid.banking", 4499 "taname": "Acme secure banking app" 4500 }, 4501 { 4502 "taid": "acom.acmebank.taid.loyalty.rewards", 4503 "taname": "Acme loyalty rewards app" 4504 } 4505 ] 4506 } 4507 ] 4508 }, 4509 "teeaiklist": [ 4510 { 4511 "spaik": 4512 "c2FtcGxlIEFTTjEgZW5jb2RlZCBQS0NTMSBwdWJsaWNrZXk=", 4513 "spaiktype": "RSA" 4514 "spid": "acmebank.com" 4515 } 4516 ] 4517 } 4518 } 4519 } 4520 } 4521 } 4523 A.2.2. Sample UpdateTA 4525 A.2.2.1. Sample UpdateTARequest 4527 { 4528 "UpdateTATBSRequest": { 4529 "ver": "1.0", 4530 "rid": "req-2", 4531 "tid": "tran-01", 4532 "tee": "SecuriTEE", 4533 "nextdsi": " false", 4534 "dsihash": "gwjul_9MZks3pqUSN1-eL1aViwGXNAxk0AIKW79dn4U", 4535 "content": { 4536 "tsmid": "tsm1.acme.com", 4537 "spid": "bank.com", 4538 "sdname": "sd.bank.com", 4539 "taid": "sd.bank.com.ta" 4540 }, 4541 "encrypted_ta": { 4542 "key": 4543 " 4544 XzmAn_RDVk3IozMwNWhiB6fmZlIs1YUvMKlQAv_UDoZ1fvGGsRGo9bT0A440aYMgLt 4545 GilKypoJjCgijdaHgamaJgRSc4Je2otpnEEagsahvDNoarMCC5nGQdkRxW7Vo2NKgL 4546 A892HGeHkJVshYm1cUlFQ-BhiJ4NAykFwlqC_oc", 4547 "iv": "AxY8DCtDaGlsbGljb3RoZQ", 4548 "alg": "AESCBC", 4549 "ciphernewtadata": 4550 "KHqOxGn7ib1F_14PG4_UX9DBjOcWkiAZhVE-U- 4551 67NsKryHGokeWr2spRWfdU2KWaaNncHoYGwEtbCH7XyNbOFh28nzwUmstep4nHWbAl 4552 XZYTNkENcABPpuw_G3I3HADo" 4553 } 4554 } 4555 } 4557 { 4558 "UpdateTARequest": { 4559 "payload" : 4560 " 4561 eyJVcGRhdGVUQVRCU1JlcXVlc3QiOnsidmVyIjoiMS4wIiwicmlkIjoicmVxLTIiLCJ0 4562 aWQiOiJ0cmFuLTAxIiwidGVlIjoiU2VjdXJpVEVFIiwibmV4dGRzaSI6ImZhbHNlIiwi 4563 ZHNpaGFzaCI6Imd3anVsXzlNWmtzM3BxVVNOMS1lTDFhVml3R1hOQXhrMEFJS1c3OWRu 4564 NFUiLCJjb250ZW50Ijp7InByb3RlY3RlZCI6ImV5SmxibU1pT2lKQk1USTRRMEpETFVo 4565 VE1qVTJJbjAiLCJyZWNpcGllbnRzIjpbeyJoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0s 4566 ImVuY3J5cHRlZF9rZXkiOiJYem1Bbl9SRFZrM0lvek13TldoaUI2Zm1abElzMVlVdk1L 4567 bFFBdl9VRG9aMWZ2R0dzUkdvOWJUMEE0NDBhWU1nTHRHaWxLeXBvSmpDZ2lqZGFIZ2Ft 4568 YUpnUlNjNEplMm90cG5FRWFnc2FodkROb2FyTUNDNW5HUWRrUnhXN1ZvMk5LZ0xBODky 4569 SEdlSGtKVnNoWW0xY1VsRlEtQmhpSjROQXlrRndscUNfb2MifV0sIml2IjoiQXhZOERD 4570 dERhR2xzYkdsamIzUm9aUSIsImNpcGhlcnRleHQiOiJIYTcwVXRZVEtWQmtXRFJuMi0w 4571 SF9IdkZtazl5SGtoVV91bk1OLWc1T3BqLWF1NGFUb2lxWklMYzVzYTdENnZZSjF6eW04 4572 QW1JOEJIVXFqc2l5Z0tOcC1HdURJUjFzRXc0a2NhMVQ5ZENuU0RydHhSUFhESVdrZmt3 4573 azZlR1NQWiIsInRhZyI6Im9UN01UTE41eWtBTFBoTDR0aUh6T1pPTGVFeU9xZ0NWaEM5 4574 MXpkcldMU0UifSwiZW5jcnlwdGVkX3RhIjp7ImtleSI6Ilh6bUFuX1JEVmszSW96TXdO 4575 V2hpQjZmbVpsSXMxWVV2TUtsUUF2X1VEb1oxZnZHR3NSR285YlQwQTQ0MGFZTWdMdEdp 4576 bEt5cG9KakNnaWpkYUhnYW1hSmdSU2M0SmUyb3RwbkVFYWdzYWh2RE5vYXJNQ0M1bkdR 4577 ZGtSeFc3Vm8yTktnTEE4OTJIR2VIa0pWc2hZbTFjVWxGUS1CaGlKNE5BeWtGd2xxQ19v 4578 YyIsIml2IjoiQXhZOERDdERhR2xzYkdsamIzUm9aUSIsImFsZyI6IkFFU0NCQyIsImNp 4579 cGhlcm5ld3RhZGF0YSI6IktIcU94R243aWIxRl8xNFBHNF9VWDlEQmpPY1draUFaaFZF 4580 LVUtNjdOc0tyeUhHb2tlV3Iyc3BSV2ZkVTJLV2FhTm5jSG9ZR3dFdGJDSDdYeU5iT0Zo 4581 MjhuendVbXN0ZXA0bkhXYkFsWFpZVE5rRU5jQUJQcHV3X0czSTNIQURvIn19fQ", 4582 "protected": " eyJhbGciOiJSUzI1NiJ9", 4583 "header": { 4584 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4585 "signer":" 4586 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA 4587 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4588 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh 4589 cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p 4590 YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy 4591 BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4592 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4593 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3 4594 c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4595 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA 4596 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4597 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR 4598 MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq 4599 hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G 4600 SZ1MdyIZV8fwdEmD90IvtMHgtzK- 4601 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA 4602 UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4603 }, 4604 "signature":"inB1K6G3EAhF- 4605 FbID83UI25R5Ao8MI4qfrbrmf0UQhjM3O7_g3l6XxN_JkHrGQaZr- 4606 myOkGPVM8BzbUZW5GqxNZwFXwMeaoCjDKc4Apv4WZkD1qKJxkg1k5jaUCfJz1Jmw_XtX 4607 6MHhrLh9ov03S9PtuT1VAQ0FVUB3qFIvjSnNU" 4608 } 4609 } 4611 A.2.2.2. Sample UpdateTAResponse 4612 { 4613 "UpdateTATBSResponse": { 4614 "ver": "1.0", 4615 "status": "pass", 4616 "rid": "req-2", 4617 "tid": "tran-01", 4618 "content": { 4619 "did": "zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM" 4620 } 4621 } 4622 } 4624 { 4625 "UpdateTAResponse":{ 4626 "payload":" 4627 eyJVcGRhdGVUQVRCU1Jlc3BvbnNlIjp7InZlciI6IjEuMCIsInN0YXR1cyI6InBhc3Mi 4628 LCJyaWQiOiJyZXEtMiIsInRpZCI6InRyYW4tMDEiLCJjb250ZW50Ijp7InByb3RlY3Rl 4629 ZCI6ImV5SmxibU1pT2lKQk1USTRRMEpETFVoVE1qVTJJbjAiLCJyZWNpcGllbnRzIjpb 4630 eyJoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0sImVuY3J5cHRlZF9rZXkiOiJFaGUxLUJB 4631 UUdJLTNEMFNHdXFGY01MZDJtd0gxQm1uRndYQWx1M1FxUFVXZ1RRVm55SUowNFc2MnBK 4632 YWVSREFkeTU0R0FSVjBrVzQ0RGw0MkdUUlhqbE1EZ3BYdXdFLWloc1JVV0tNNldCZ2N3 4633 VXVGQTRUR3gwU0I1NTZCdl92dnBNaFdfMXh2c2FHdFBaQmwxTnZjbXNibzBhY3FobXlu 4634 bzBDTmF5SVAtX1UifV0sIml2IjoiQXhZOERDdERhR2xzYkdsamIzUm9aUSIsImNpcGhl 4635 cnRleHQiOiJwc2o2dGtyaGJXM0lmVElMeE9GMU5HdFUtcTFmeVBidV9KWk9jbklycWIw 4636 eTNPOHN6OTItaWpWR1ZyRW5WbG1sY1FYeWFNZTNyX1JGdEkwV3B4UmRodyIsInRhZyI6 4637 Ik0zb2dNNk11MVJYMUMybEZvaG5rTkN5b25qNjd2TDNqd2RrZXhFdUlpaTgifX19", 4638 "protected":"eyJhbGciOiJSUzI1NiJ9", 4639 "header": { 4640 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4641 "signer":" 4642 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA 4643 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4644 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh 4645 cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p 4646 YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy 4647 BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4648 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4649 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3 4650 c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4651 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA 4652 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4653 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR 4654 MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq 4655 hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G 4656 SZ1MdyIZV8fwdEmD90IvtMHgtzK- 4657 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA 4658 UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4659 }, 4660 "signature":" 4661 Twajmt_BBLIMcNrDsjqr8lI7O7lEQxXZNhlUOtFkOMMqf37wOPKtp_99LoS82CVmdpCo 4662 PLaws8zzh-SNIQ42- 4663 9GYO8_9BaEGCiCwyl8YgWP9fWNfNv2gR2fl2DK4uknkYu1EMBW4YfP81n_pGpb4Gm- 4664 nMk14grVZygwAPej3ZZk" 4665 } 4666 } 4667 A.2.3. Sample DeleteTA 4669 A.2.3.1. Sample DeleteTARequest 4671 { 4672 "DeleteTATBSRequest": { 4673 "ver": "1.0", 4674 "rid": "req-2", 4675 "tid": "tran-01", 4676 "tee": "SecuriTEE", 4677 "nextdsi": "false", 4678 "dsihash": "gwjul_9MZks3pqUSN1-eL1aViwGXNAxk0AIKW79dn4U", 4679 "content": { 4680 "tsmid": "tsm1.acme.com", 4681 "sdname": "sd.bank.com", 4682 "taid": "sd.bank.com.ta" 4683 } 4684 } 4685 } 4687 { 4688 "DeleteTARequest": { 4689 "payload": 4690 " 4691 eyJEZWxldGVUQVRCU1JlcXVlc3QiOnsidmVyIjoiMS4wIiwicmlkIjoicmVxLTIiLCJ0 4692 aWQiOiJ0cmFuLTAxIiwidGVlIjoiU2VjdXJpVEVFIiwibmV4dGRzaSI6ImZhbHNlIiwi 4693 ZHNpaGFzaCI6Imd3anVsXzlNWmtzM3BxVVNOMS1lTDFhVml3R1hOQXhrMEFJS1c3OWRu 4694 NFUiLCJjb250ZW50Ijp7InByb3RlY3RlZCI6eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0s 4695 InJlY2lwaWVudHMiOlt7ImhlYWRlciI6eyJhbGciOiJSU0ExXzUifSwiZW5jcnlwdGVk 4696 X2tleSI6ImtyaGs0d2dpY0RlX3d0VXQyTW4tSUJsdUtvX0JkeXpNY2p1cVlBenBPYnRS 4697 TG9MZzQ0QkFLN2tRVWE1YTg0TEVJRGEzaHNtWDIxdldNZFJLczN4MTJsOUh5VFdfLUNS 4698 WmZtcUx2bEh1LV9MSVdvc1ZyRTZVMlJqUnRndllVOWliUkVLczkzRDRHWm4xVHFuZG9n 4699 d0tXRF9jdG1nWG1sbzZZVXpCWDZhR1dZMCJ9XSwiaXYiOiJBeFk4REN0RGFHbHNiR2xq 4700 YjNSb1pRIiwiY2lwaGVydGV4dCI6IkhhNzBVdFlUS1ZCa1dEUm4yLTBIX1BGa19yQnpQ 4701 dGJHdzhSNktlMXotdklNeFBSY0Nxa1puZmwyTjRjUTZPSTZCSHZJUUFoM2Jic0l0dHlR 4702 bXhDTE5Nbm8wejBrYm9TdkIyVXlxWExpeGVZIiwidGFnIjoidEtUbFRLdlR2LTRtVVlG 4703 Y1dYWnZMMVlhQnRGNloxVlNxOTMzVmI2UEpmcyJ9fX0", 4704 "protected" : "eyJhbGciOiJSUzI1NiJ9", 4705 "header": { 4706 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4707 "signer":" 4708 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA 4709 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4710 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh 4711 cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p 4712 YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy 4713 BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4714 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4715 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3 4716 c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4717 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA 4718 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4719 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR 4720 MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq 4721 hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G 4722 SZ1MdyIZV8fwdEmD90IvtMHgtzK- 4723 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA 4724 UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4725 }, 4726 "signature" : 4727 " 4728 BZS0_Ab6pqvGNXe5lqT4Sc3jakyWQeiK9KlVSnimwWnjCCyMtyB9bwvlbILZba3IJiFe 4729 _3F9bIQpSytGS0f2TQrPTKC7pSjwDw-3kH7HkHcPPJd- 4730 PpMMfQvRx7AIV8vBqO9MijIC62iN0V2se5z2v8VFjGSoRGgq225w7FvrnWE" 4731 } 4732 } 4733 A.2.3.2. Sample DeleteTAResponse 4735 { 4736 "DeleteTATBSResponse": { 4737 "ver": "1.0", 4738 "status": "pass", 4739 "rid": "req-2", 4740 "tid": "tran-01", 4741 "content": { 4742 "did": "zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM" 4743 } 4744 } 4745 } 4747 { 4748 "DeleteTAResponse":{ 4749 "payload":" 4750 ew0KCSJEZWxldGVUQVRCU1Jlc3BvbnNlIjogew0KCQkidmVyIjogIjEuMCIsDQoJCSJz 4751 dGF0dXMiOiAicGFzcyIsDQoJCSJyaWQiOiAicmVxLTIiLA0KCQkidGlkIjogInRyYW4t 4752 MDEiLA0KCQkiY29udGVudCI6IHsNCgkJCSJwcm90ZWN0ZWQiOnsiZW5jIjoiQTEyOENC 4753 Qy1IUzI1NiJ9LA0KCQkJInJlY2lwaWVudHMiOlsNCgkJCQl7DQoJCQkJCSJoZWFkZXIi 4754 OnsiYWxnIjoiUlNBMV81In0sDQoJCQkJCSJlbmNyeXB0ZWRfa2V5IjoiTXdtU1ZHaWU2 4755 eHpfQmxTaFlmTFRKRHhKT3oyNWhvYy1HZ2NEM2o5OWFyM2E4X2lYY182ZE44bFRTb1dD 4756 X19wZEFhaEMyWk5SakdIcTBCZ2JDYTRKalk0eXRkMVBVWDB6M1psbXl1YnRXM291eEpY 4757 el9PMzg1WGM4S3hySndjbElyZGx2WUY2OVZmeERLQkVzUHJCdzlVenVIa1VmSU4xWlFU 4758 bWZ0QmVaSlJnIg0KCQkJCX0NCgkJCV0sDQoJCQkiaXYiOiJBeFk4REN0RGFHbHNiR2xq 4759 YjNSb1pRIiwNCgkJCSJjaXBoZXJ0ZXh0IjoiamhQTlV5ZkFTel9rVV9GbEM2LUtCME01 4760 WDBHNE5MbHc0LWt0bERyajZTWlUteUp6eUFUbC1oY0ZBWWMwLXJMVEF4cF93N1d1WER0 4761 Y3N3SzJSSzRjcWciLA0KCQkJInRhZyI6IlBBeGo5N25oT29qVTNIREhxSll4MGZMNWpt 4762 b0xkTlJkTHRtSmIzUTdrYXciDQoJCX0NCgl9DQp9", 4763 "protected": "eyJhbGciOiJSUzI1NiJ9", 4764 "header": { 4765 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4766 "signer":" 4767 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJ 4768 BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp 4769 Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcN 4770 MTUwNzAyMDkwMTE4WhcNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzET 4771 MBEGA1UECAwKQ2FsaWZvcm5pYTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8G 4772 A1UECgwYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIGfMA0GCSqGSIb3DQEB 4773 AQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4774 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4775 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA 4776 6b_ZI3c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4777 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJ 4778 BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp 4779 Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX 4780 9nxZBNQWDjAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8E 4781 DDAKBggrBgEFBQcDAzANBgkqhkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4iv 4782 em4cIckfxzTBBiPHCjrrjB2X8Ktn8GSZ1MdyIZV8fwdEmD90IvtMHgtzK- 4783 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fV 4784 rJvnYAUBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4785 }, 4786 "signature":" 4787 DfoBOetNelKsnAe_m4Z9K5UbihgWNYZsp5jVybiI05sOagDzv6R4do9npaAlAvpNK8HJ 4788 CxD6D22J8GDUExlIhSR1aDuDCQm6QzmjdkFdxAz5TRYl6zpPCZqgSToN_g1TZxqxEv6V 4789 Ob5fies4g6MHvCH-Il_-KbHq5YpwGxEEFdg" 4790 } 4791 } 4792 Authors' Addresses 4794 Mingliang Pei 4795 Symantec 4796 350 Ellis St 4797 Mountain View, CA 94043 4798 USA 4800 Email: mingliang_pei@symantec.com 4802 Nick Cook 4803 ARM Ltd. 4804 110 Fulbourn Rd 4805 Cambridge, CB1 9NJ 4806 Great Britain 4808 Email: nicholas.cook@arm.com 4810 Minho Yoo 4811 Solacia 4812 5F, Daerung Post Tower 2, 306 Digital-ro 4813 Seoul 152-790 4814 Korea 4816 Email: paromix@sola-cia.com 4818 Andrew Atyeo 4819 Intercede 4820 St. Mary's Road, Lutterworth 4821 Leicestershire, LE17 4PS 4822 Great Britain 4824 Email: andrew.atyeo@intercede.com 4826 Hannes Tschofenig 4827 ARM Ltd. 4828 110 Fulbourn Rd 4829 Cambridge, CB1 9NJ 4830 Great Britain 4832 Email: Hannes.tschofenig@arm.com