idnits 2.17.1 draft-ietf-teep-opentrustprotocol-00.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 935 has weird spacing: '...cluding the r...' -- The document date (May 1, 2018) is 2187 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CA' is mentioned on line 611, but not defined == Missing Reference: 'Soc' is mentioned on line 613, but not defined == Missing Reference: 'OEM' is mentioned on line 625, 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 A. Atyeo 5 Expires: November 2, 2018 Intercede 6 N. Cook 7 ARM Ltd. 8 M. Yoo 9 Solacia 10 H. Tschofenig 11 ARM Ltd. 12 May 1, 2018 14 The Open Trust Protocol (OTrP) 15 draft-ietf-teep-opentrustprotocol-00.txt 17 Abstract 19 This document specifies the Open Trust Protocol (OTrP), a protocol to 20 install, update, and delete applications in a Trusted Execution 21 Environment (TEE) and to manage their security configuration. 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 compartmentalization 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 November 2, 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 . . . . . . . . . . . . . . . . . . . . . . 8 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 TAM . . . . . . . . . . . . . . . . . 10 72 4.4. Keys and Certificate Types . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . 15 76 5.3. Security Domain Hierarchy and Ownership . . . . . . . . . 15 77 5.4. SD Owner Identification and TAM Certificate Requirements 16 78 5.5. Service Provider Container . . . . . . . . . . . . . . . 16 79 6. OTrP Agent . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 6.1. Role of OTrP Agent . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . 19 85 6.4. OTrP Agent Interfaces for Client Applications . . . . . . 19 86 6.4.1. ProcessOTrPMessage call . . . . . . . . . . . . . . . 19 87 6.4.2. GetTAInformation call . . . . . . . . . . . . . . . . 20 88 6.5. Sample End-to-End Client Application Flow . . . . . . . . 23 89 6.5.1. Case 1: A New Client Application Uses a TA . . . . . 23 90 6.5.2. Case 2: A Previously Installed Client Application 91 Calls a TA . . . . . . . . . . . . . . . . . . . . . 24 92 7. OTrP Messages . . . . . . . . . . . . . . . . . . . . . . . . 25 93 7.1. Message Format . . . . . . . . . . . . . . . . . . . . . 25 94 7.2. Message Naming Convention . . . . . . . . . . . . . . . . 25 95 7.3. Request and Response Message Template . . . . . . . . . . 26 96 7.4. Signed Request and Response Message Structure . . . . . . 26 97 7.4.1. Identifying Signing and Encryption Keys for JWS/JWE 98 Messaging . . . . . . . . . . . . . . . . . . . . . . 28 99 7.5. JSON Signing and Encryption Algorithms . . . . . . . . . 28 100 7.5.1. Supported JSON Signing Algorithms . . . . . . . . . . 30 101 7.5.2. Support JSON Encryption Algorithms . . . . . . . . . 30 102 7.5.3. Supported JSON Key Management Algorithms . . . . . . 30 103 7.6. Common Errors . . . . . . . . . . . . . . . . . . . . . . 31 104 7.7. OTrP Message List . . . . . . . . . . . . . . . . . . . . 31 105 7.8. OTrP Request Message Routing Rules . . . . . . . . . . . 32 106 7.8.1. SP Anonymous Attestation Key (SP AIK) . . . . . . . . 32 107 8. Transport Protocol Support . . . . . . . . . . . . . . . . . 32 108 9. Detailed Messages Specification . . . . . . . . . . . . . . . 33 109 9.1. GetDeviceState . . . . . . . . . . . . . . . . . . . . . 33 110 9.1.1. GetDeviceStateRequest message . . . . . . . . . . . . 33 111 9.1.2. Request processing requirements at a TEE . . . . . . 34 112 9.1.3. Firmware Signed Data . . . . . . . . . . . . . . . . 35 113 9.1.3.1. Supported Firmware Signature Methods . . . . . . 36 114 9.1.4. Post Conditions . . . . . . . . . . . . . . . . . . . 36 115 9.1.5. GetDeviceStateResponse Message . . . . . . . . . . . 36 116 9.1.6. Error Conditions . . . . . . . . . . . . . . . . . . 41 117 9.1.7. TAM Processing Requirements . . . . . . . . . . . . . 42 118 9.2. Security Domain Management . . . . . . . . . . . . . . . 43 119 9.2.1. CreateSD . . . . . . . . . . . . . . . . . . . . . . 43 120 9.2.1.1. CreateSDRequest Message . . . . . . . . . . . . . 43 121 9.2.1.2. Request Processing Requirements at a TEE . . . . 46 122 9.2.1.3. CreateSDResponse Message . . . . . . . . . . . . 47 123 9.2.1.4. Error Conditions . . . . . . . . . . . . . . . . 49 124 9.2.2. UpdateSD . . . . . . . . . . . . . . . . . . . . . . 49 125 9.2.2.1. UpdateSDRequest Message . . . . . . . . . . . . . 49 126 9.2.2.2. Request Processing Requirements at a TEE . . . . 52 127 9.2.2.3. UpdateSDResponse Message . . . . . . . . . . . . 54 128 9.2.2.4. Error Conditions . . . . . . . . . . . . . . . . 55 129 9.2.3. DeleteSD . . . . . . . . . . . . . . . . . . . . . . 56 130 9.2.3.1. DeleteSDRequest Message . . . . . . . . . . . . . 56 131 9.2.3.2. Request Processing Requirements at a TEE . . . . 58 132 9.2.3.3. DeleteSDResponse Message . . . . . . . . . . . . 59 133 9.2.3.4. Error Conditions . . . . . . . . . . . . . . . . 61 134 9.3. Trusted Application Management . . . . . . . . . . . . . 61 135 9.3.1. InstallTA . . . . . . . . . . . . . . . . . . . . . . 62 136 9.3.1.1. InstallTARequest Message . . . . . . . . . . . . 63 137 9.3.1.2. InstallTAResponse Message . . . . . . . . . . . . 65 138 9.3.1.3. Error Conditions . . . . . . . . . . . . . . . . 67 139 9.3.2. UpdateTA . . . . . . . . . . . . . . . . . . . . . . 67 140 9.3.2.1. UpdateTARequest Message . . . . . . . . . . . . . 68 141 9.3.2.2. UpdateTAResponse Message . . . . . . . . . . . . 70 142 9.3.2.3. Error Conditions . . . . . . . . . . . . . . . . 72 143 9.3.3. DeleteTA . . . . . . . . . . . . . . . . . . . . . . 72 144 9.3.3.1. DeleteTARequest Message . . . . . . . . . . . . . 72 145 9.3.3.2. Request Processing Requirements at a TEE . . . . 74 146 9.3.3.3. DeleteTAResponse Message . . . . . . . . . . . . 75 147 9.3.3.4. Error Conditions . . . . . . . . . . . . . . . . 76 148 10. Response Messages a TAM May Expect . . . . . . . . . . . . . 76 149 11. Basic Protocol Profile . . . . . . . . . . . . . . . . . . . 77 150 12. Attestation Implementation Consideration . . . . . . . . . . 78 151 12.1. OTrP Secure Boot Module . . . . . . . . . . . . . . . . 78 152 12.1.1. Attestation signer . . . . . . . . . . . . . . . . . 78 153 12.1.2. SBM Initial Requirements . . . . . . . . . . . . . . 78 154 12.2. TEE Loading . . . . . . . . . . . . . . . . . . . . . . 79 155 12.3. Attestation Hierarchy . . . . . . . . . . . . . . . . . 79 156 12.3.1. Attestation Hierarchy Establishment: Manufacture . . 80 157 12.3.2. Attestation Hierarchy Establishment: Device Boot . . 80 158 12.3.3. Attestation Hierarchy Establishment: TAM . . . . . . 80 159 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81 160 13.1. Error Code List . . . . . . . . . . . . . . . . . . . . 81 161 13.1.1. TEE Signed Error Code List . . . . . . . . . . . . . 81 162 13.1.2. OTrP Agent Error Code List . . . . . . . . . . . . . 82 163 14. Security Consideration . . . . . . . . . . . . . . . . . . . 82 164 14.1. Cryptographic Strength . . . . . . . . . . . . . . . . . 82 165 14.2. Message Security . . . . . . . . . . . . . . . . . . . . 83 166 14.3. TEE Attestation . . . . . . . . . . . . . . . . . . . . 83 167 14.4. TA Protection . . . . . . . . . . . . . . . . . . . . . 83 168 14.5. TA Personalization Data . . . . . . . . . . . . . . . . 84 169 14.6. TA Trust Check at TEE . . . . . . . . . . . . . . . . . 84 170 14.7. One TA Multiple SP Case . . . . . . . . . . . . . . . . 85 171 14.8. OTrP Agent Trust Model . . . . . . . . . . . . . . . . . 85 172 14.9. OCSP Stapling Data for TAM Signed Messages . . . . . . . 85 173 14.10. Data Protection at TAM and TEE . . . . . . . . . . . . . 85 174 14.11. Privacy Consideration . . . . . . . . . . . . . . . . . 85 175 14.12. Threat Mitigation . . . . . . . . . . . . . . . . . . . 86 176 14.13. Compromised CA . . . . . . . . . . . . . . . . . . . . . 86 177 14.14. Compromised TAM . . . . . . . . . . . . . . . . . . . . 87 178 14.15. Certificate Renewal . . . . . . . . . . . . . . . . . . 87 179 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 87 180 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 87 181 16.1. Normative References . . . . . . . . . . . . . . . . . . 87 182 16.2. Informative References . . . . . . . . . . . . . . . . . 88 183 Appendix A. Sample Messages . . . . . . . . . . . . . . . . . . 88 184 A.1. Sample Security Domain Management Messages . . . . . . . 88 185 A.1.1. Sample GetDeviceState . . . . . . . . . . . . . . . . 88 186 A.1.1.1. Sample GetDeviceStateRequest . . . . . . . . . . 88 187 A.1.1.2. Sample GetDeviceStateResponse . . . . . . . . . . 89 188 A.1.2. Sample CreateSD . . . . . . . . . . . . . . . . . . . 92 189 A.1.2.1. Sample CreateSDRequest . . . . . . . . . . . . . 92 190 A.1.2.2. Sample CreateSDResponse . . . . . . . . . . . . . 95 191 A.1.3. Sample UpdateSD . . . . . . . . . . . . . . . . . . . 96 192 A.1.3.1. Sample UpdateSDRequest . . . . . . . . . . . . . 97 193 A.1.3.2. Sample UpdateSDResponse . . . . . . . . . . . . . 98 194 A.1.4. Sample DeleteSD . . . . . . . . . . . . . . . . . . . 98 195 A.1.4.1. Sample DeleteSDRequest . . . . . . . . . . . . . 98 196 A.1.4.2. Sample DeleteSDResponse . . . . . . . . . . . . . 100 197 A.2. Sample TA Management Messages . . . . . . . . . . . . . . 102 198 A.2.1. Sample InstallTA . . . . . . . . . . . . . . . . . . 102 199 A.2.1.1. Sample InstallTARequest . . . . . . . . . . . . . 102 200 A.2.1.2. Sample InstallTAResponse . . . . . . . . . . . . 103 201 A.2.2. Sample UpdateTA . . . . . . . . . . . . . . . . . . . 105 202 A.2.2.1. Sample UpdateTARequest . . . . . . . . . . . . . 105 203 A.2.2.2. Sample UpdateTAResponse . . . . . . . . . . . . . 106 204 A.2.3. Sample DeleteTA . . . . . . . . . . . . . . . . . . . 109 205 A.2.3.1. Sample DeleteTARequest . . . . . . . . . . . . . 109 206 A.2.3.2. Sample DeleteTAResponse . . . . . . . . . . . . . 111 207 A.3. Example OTrP Agent Option . . . . . . . . . . . . . . . . 113 208 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 113 209 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 113 211 1. Introduction 213 The Trusted Execution Environment (TEE) concept has been designed and 214 used to increase security by separating a regular operating system, 215 also referred as a Rich Execution Environment (REE), from security- 216 sensitive applications. In an TEE ecosystem, a Trusted Application 217 Manager (TAM) is used to manage keys and the Trusted Applications 218 (TA) that run in a device. Different device vendors may use 219 different TEE implementations. Different application providers may 220 use different TAM providers. There arises a need of an open 221 interoperable protocol that establishes trust between different 222 devices and TAM providers, and management capability for a 223 trustworthy TAM to manage Security Domains and applications running 224 in different TEEs of various devices. 226 The Open Trust Protocol (OTrP) defines a mutual trust message 227 protocol between a TAM and a TEE and relies on IETF-defined end-to- 228 end security mechanisms, namely JSON Web Encryption (JWE), JSON Web 229 Signature (JWS), and JSON Web Key (JWK). Other message encoding 230 methods may be supported. 232 This specification assumes that an applicable device is equipped with 233 a TEE and is pre-provisioned with a device-unique public/private key 234 pair, which is securely stored. This key pair is referred as the 235 'root of trust'. An entity that uses such a device to run Trusted 236 Applications (TAs) is known as a Service Provider (SP). 238 A Security Domain is defined as the TEE representation of a Service 239 Provider, which is a logical space that contains the SP's TAs. Each 240 Security Domain requires the management operations of TAs in the form 241 of installation, update and deletion. 243 The protocol builds on the following properties of the system: 245 1. The SP needs to determine security-relevant information of a 246 device before provisioning information to a TEE. Examples 247 include the verification of the device 'root of trust', the type 248 of firmware installed, and the type of TEE included in a device. 250 2. A TEE in a device needs to determine whether an SP or a TAM is 251 trustworthy or authorized to manage applications in the TEE. 253 3. Secure Boot must be able to ensure a TEE is genuine. 255 This specification defines message payloads exchanged between devices 256 and a TAM. The messages are designed in anticipation of the use of 257 the most common transport methods such as HTTPS. 259 A TA binary and personalization data can be from two sources: 261 1. A TAM supplies the signed and encrypted TA binary 263 2. A Client Application supplies the TA binary 265 This specification considers the first case where TA binary and 266 personalization data are encrypted by recipient's public key that TAM 267 has to be involved. The second case will be addressed separately. 269 2. Requirements Language 271 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 272 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 273 document are to be interpreted as described in [RFC2119]. 275 3. Terminology 277 3.1. Definitions 279 The definitions provided below are defined as used in this document. 280 The same terms may be defined differently in other documents. 282 Client Application: An application running on a rich OS, such as an 283 Android, Windows, or iOS application, typically provided by an 284 SP. 286 Device: A physical piece of hardware that hosts a TEE along with a 287 rich OS. 289 OTrP Agent: An application running in the rich OS allowing 290 communication with the TAM and the TEE. 292 Rich Application: Alternative name of "Client Application". In this 293 document we may use these two terms interchangeably. 295 Rich Execution Environment (REE) An environment that is provided and 296 governed by a standard OS, potentially in conjunction with other 297 supporting operating systems and hypervisors; it is outside of 298 the TEE. This environment and applications running on it are 299 considered un-trusted. 301 Secure Boot Module (SBM): A firmware in a device that delivers 302 secure boot functionality. It is generally signed and can be 303 verified whether it can be trusted. We also call it a Trusted 304 Firmware (TFW). 306 Service Provider (SP): An entity that wishes to supply Trusted 307 Applications to remote devices. A Service Provider requires the 308 help of a TAM in order to provision the Trusted Applications to 309 the devices. 311 Trust Anchor: A root certificate that can be used to validate its 312 children certificates. It is usually embedded in a device or 313 configured by a TAM for validating the trust of a remote entity's 314 certificate. 316 Trusted Application (TA): An Application that runs in a TEE. 318 Trusted Execution Environment (TEE): An execution environment that 319 runs alongside of, but is isolated from, an REE. A TEE has 320 security capabilities and meets certain security-related 321 requirements. It protects TEE assets from general software 322 attacks, defines rigid safeguards as to data and functions that a 323 program can access, and resists a set of defined threats. It 324 should have at least the following three properties: (a) A unique 325 security identity that cannot be cloned; (b) Assurance that only 326 authorized code can run in the TEE; (c) Memory that cannot be 327 read by code outside of TEE. There are multiple technologies 328 that can be used to implement a TEE, and the level of security 329 achieved varies accordingly. 331 3.2. Abbreviations 333 CA Certificate Authority 335 OTrP Open Trust Protocol 337 REE Rich Execution Environment 339 SD Security Domain 341 SP Service Provider 343 SBM Secure Boot Module 345 TA Trusted Application 347 TEE Trusted Execution Environment 349 TFW Trusted Firmware 351 TAM Trusted Application Manager 353 4. OTrP Entities and Trust Model 355 4.1. System Components 357 The following are the main components in this OTrP system. 359 TAM: The TAM is responsible for originating and coordinating 360 lifecycle management activity on a particular TEE. 362 A TAM manages device trust check on behalf of Service Providers. 363 A TAM may be used by one SP or many SPs. A TAM also provides 364 Security Domain management and TA management in a device, in 365 particularly, over-the-air update to keep TAs up-to-date and 366 clean up when a version should be removed. 368 Certificate Authority (CA): Mutual trust between a device and a TAM 369 as well as an SP is based on certificates. A device embeds a 370 list of root certificates, called Trust Anchors, from trusted 371 Certificate Authorities that a TAM will be validated against. A 372 TAM will remotely attest a device by checking whether a device 373 comes with a certificate from a trusted CA. 375 TEE: The TEE in a device is responsible for protecting applications 376 from attack, enabling the application to perform secure 377 operations. 379 REE: The REE is responsible for enabling off device communications 380 to be established between the TEE and TAM. OTrP does not require 381 the device OS to be secure. 383 OTrP Agent: An application in the REE that can relay messages 384 between a Client Application and TEE. Its implementation can be 385 TEE specific as to how it can interact with a TEE in a device. 387 Secure Boot: Secure boot (for the purposes of OTrP) must enable 388 authenticity checking of TEEs by the TAM. 390 The OTrP establishes appropriate trust anchors to enable TEEs and 391 TAMs to communicate in a trusted way when performing lifecycle 392 management transactions. 394 4.2. Trusted Anchors in TEE 396 The TEE in each device comes with a trust store that contains a 397 whitelist of the TAM's root CA certificates, which are called Trust 398 Anchors. A TAM will be trusted to manage Security Domains and TAs in 399 a device only if the TAM's certificate is chained to one of the root 400 CA certificates in this trust store. 402 Such a list is typically embedded in the TEE of a device, and the 403 list update should be generally enabled. 405 Before a TAM can begin operation in the marketplace to support 406 devices of a given TEE, it must obtain a TAM certificate from a CA 407 that is registered in the trust store of the TEE. 409 4.3. Trusted Anchors in TAM 411 The Trust Anchor set in a TAM consists of a list of Certificate 412 Authority certificates that signs various device TEE certificates. A 413 TAM decides what TEE and optionally TFW it will trust. 415 4.4. Keys and Certificate Types 417 OTrP leverages the following list of trust anchors and identities in 418 generating signed and encrypted command messages that are exchanged 419 between a device's TEE and a TAM. With these security artifacts, 420 OTrP Messages are able to deliver end-to-end security without relying 421 on any transport security. 423 +-------------+----------+--------+-------------------+-------------+ 424 | Key Entity | Location | Issuer | Trust Implication | Cardinality | 425 | Name | | | | | 426 +-------------+----------+--------+-------------------+-------------+ 427 | 1. TFW key | Device | FW CA | A white list of | 1 per | 428 | pair and | secure | | FW root CA | device | 429 | certificate | storage | | trusted by TAMs | | 430 | | | | | | 431 | 2. TEE key | Device | TEE CA | A white list of | 1 per | 432 | pair and | TEE | under | TEE root CA | device | 433 | certificate | | a root | trusted by TAMs | | 434 | | | CA | | | 435 | | | | | | 436 | 3. TAM key | TAM | TAM CA | A white list of | 1 or | 437 | pair and | provider | under | TAM root CA | multiple | 438 | certificate | | a root | embedded in TEE | can be used | 439 | | | CA | | by a TAM | 440 | | | | | | 441 | 4. SP key | SP | SP | TAM manages SP. | 1 or | 442 | pair and | | signer | TA trust is | multiple | 443 | certificate | | CA | delegated to TAM. | can be used | 444 | | | | TEE trusts TAM to | by a TAM | 445 | | | | ensure that a TA | | 446 | | | | is trustworthy. | | 447 +-------------+----------+--------+-------------------+-------------+ 449 Table 1: Key and Certificate Types 451 1. TFW key pair and certificate: A key pair and certificate for 452 evidence of secure boot and trustworthy firmware in a device. 454 Location: Device secure storage 456 Supported Key Type: RSA and ECC 457 Issuer: OEM CA 459 Trust Implication: A white list of FW root CA trusted by TAMs 461 Cardinality: One per device 463 2. TEE key pair and certificate: It is used for device attestation 464 to a remote TAM and SP. 466 This key pair is burned into the device at device manufacturer. 467 The key pair and its certificate are valid for the expected 468 lifetime of the device. 470 Location: Device TEE 472 Supported Key Type: RSA and ECC 474 Issuer: A CA that chains to a TEE root CA 476 Trust Implication: A white list of TEE root CA trusted by TAMs 478 Cardinality: One per device 480 3. TAM key pair and certificate: A TAM provider acquires a 481 certificate from a CA that a TEE trusts. 483 Location: TAM provider 485 Supported Key Type: RSA and ECC. 487 Supported Key Size: RSA 2048-bit, ECC P-256 and P-384. Other 488 sizes should be anticipated in future. 490 Issuer: TAM CA that chains to a root CA 492 Trust Implication: A white list of TAM root CA embedded in TEE 494 Cardinality: One or multiple can be used by a TAM 496 4. SP key pair and certificate: an SP uses its own key pair and 497 certificate to sign a TA. 499 Location: SP 501 Supported Key Type: RSA and ECC 503 Supported Key Size: RSA 2048-bit, ECC P-256 and P-384. Other 504 sizes should be anticipated in future. 506 Issuer: an SP signer CA that chains to a root CA 508 Trust Implication: TAM manages SP. TA trusts an SP by 509 validating trust against a TAM that the SP uses. A TEE trusts 510 TAM to ensure that a TA from the TAM is trustworthy. 512 Cardinality: One or multiple can be used by an SP 514 5. Protocol Scope and Entity Relations 516 This document specifies messages and key properties that can 517 establish mutual trust between a TEE and a TAM. The protocol 518 provides specifications for the following three entities: 520 1. Key and certificate types required for device firmware, TEEs, 521 TAs, SPs, and TAMs 523 2. Data message formats that should be exchanged between a TEE in a 524 device and a TAM 526 3. An OTrP Agent application in the REE that can relay messages 527 between a Client Application and TEE 529 Figure 1: Protocol Scope and Entity Relationship 531 PKI CA -- CA CA -- 532 | | | 533 | | | 534 | | | 535 Device | | --- OTrP Agent / Client App --- | 536 SW | | | | | 537 | | | | | 538 | | | | | 539 OTrP | -- TEE TAM------- 540 | 541 | 542 FW 544 Figure 2: OTrP System Diagram 545 -------OTrP Message Protocol--- 546 | | 547 | | 548 -------------------- --------------- ---------- 549 | REE | TEE | | TAM | | SP | 550 | --- | --- | | --- | | -- | 551 | | | | | | | 552 | Client | SD (TAs)| | SD / TA | | TA | 553 | Apps | | | Mgmt | | | 554 | | | | | | | | 555 | | | | | | | | 556 | OTrP | Trusted | | Trusted | | | 557 | Agent | TAM/SP | | FW/TEE | | | 558 | | CAs | | CAs | | | 559 | | | | | | | 560 | |TEE Key/ | | TAM Key/ | |SP Key/ | 561 | | Cert | | Cert | | Cert | 562 | | FW Key/ | | | | | 563 | | Cert | | | | | 564 -------------------- --------------- ---------- 565 | | | 566 | | | 567 ------------- ---------- --------- 568 | TEE CA | | TAM CA | | SP CA | 569 ------------- ---------- --------- 571 In the previous diagram, different Certificate Authorities can be 572 used respectively for different types of certificates. OTrP Messages 573 are always signed, where the signer keys is the message creator's 574 private key such as a FW's private key, a TEE's private key, or a 575 TAM's private key. 577 The main OTrP component consists of a set of standard JSON messages 578 created by a TAM to deliver device SD and TA management commands to a 579 device, and device attestation and response messages created by a TEE 580 that responds to a TAM's OTrP message. 582 The communication method of OTrP Messages between a TAM and TEE in a 583 device may vary between TAM and TEE providers. A mandatory transport 584 protocol is specified for a compliant TAM and a device TEE. 586 It should be noted that network communication capability is generally 587 not available in today's TEE powered devices. The networking 588 functionality is handled by a rich Client Application with a remote 589 internet services; the Client Applications uses a local TEE interface 590 such as inter-process or a secure shared memory approach to interact 591 with TA inside a TEE for message exchanges. Consequently, a TAM 592 generally communicates with a Client Application about how it gets 593 OTrP Messages that originates from TEE inside a device. Similarly, a 594 TA or TEE generally gets OTrP messages from a TAM via some Client 595 Application, not direct to the internet. 597 It is imperative to have an interoperable interface to communicate 598 with different TEEs in different devices that a Client Application 599 needs to run and access a TA inside a TEE. This is the role of an 600 OTrP Agent, which is a software component to bridge communication 601 between a TAM and a TEE. The OTrP Agent doesn't need to know the 602 actual content of OTrP Messages except for the TEE routing 603 information. 605 5.1. A Sample Device Setup Flow 607 Step 1: Prepare Images for Devices 609 1. [TEE vendor] Deliver TEE Image (CODE Binary) to device OEM 611 2. [CA] Deliver root CA Whitelist 613 3. [Soc] Deliver TFW Image 615 Step 2: Inject Key Pairs and Images to Devices 617 1. [OEM] Generate Secure Boot Key Pair (May be shared among multiple 618 devices) 620 2. [OEM] Flash signed TFW Image and signed TEE Image onto devices 621 (signed by Secure Boot Key) 623 Step 3: Setup attestation key pairs in devices 625 1. [OEM] Flash Secure Boot Public Key and eFuse Key (eFuse key is 626 unique per device) 628 2. [TFW/TEE] Generate a unique attestation key pair and get a 629 certificate for the device. 631 Step 4: Setup trust anchors in devices 633 1. [TFW/TEE] Store the key and certificate encrypted with the eFuse 634 key 636 2. [TEE vendor or OEM] Store trusted CA certificate list into 637 devices 639 5.2. Derived Keys in The Protocol 641 The protocol generates one key pair in run time to assist message 642 communication and anonymous verification between a TAM and a TEE. 644 TEE SP Anonymous Key (AIK): one derived key pair per SP in a device 646 The purpose of the key pair is to sign data by a TEE without using 647 its TEE device key for anonymous attestation to a Client Application. 648 This key pair is generated in the first SD creation for an SP. It is 649 deleted when all SDs are removed for a SP in a device. The public 650 key of the key pair is given to the caller Client Application and TAM 651 for future TEE returned data validation. The public key of this AIK 652 is also used by a TAM to encrypt TA binary data and personalization 653 data when it sends a TA to a device for installation. 655 5.3. Security Domain Hierarchy and Ownership 657 The primary job of a TAM is to help an SP to manage its trusted 658 applications. A TA is typically installed in an SD. An SD is 659 commonly created for an SP. 661 When an SP delegates its SD and TA management to a TAM, an SD is 662 created on behalf of a TAM in a TEE and the owner of the SD is 663 assigned to the TAM. An SD may be associated with an SP but the TAM 664 has full privilege to manage the SD for the SP. 666 Each SD for an SP is associated with only one TAM. When an SP 667 changes TAM, a new SP SD must be created to associate with the new 668 TAM. The TEE will maintain a registry of TAM ID and SP SD ID 669 mapping. 671 From an SD ownership perspective, the SD tree is flat and there is 672 only one level. An SD is associated with its owner. It is up to TEE 673 implementation how it maintains SD binding information for a TAM and 674 different SPs under the same TAM. 676 It is an important decision in this protocol specification that a TEE 677 doesn't need to know whether a TAM is authorized to manage the SD for 678 an SP. This authorization is implicitly triggered by an SP Client 679 Application, which instructs what TAM it wants to use. An SD is 680 always associated with a TAM in addition to its SP ID. A rogue TAM 681 isn't able to do anything on an unauthorized SP's SD managed by 682 another TAM. 684 Since a TAM may support multiple SPs, sharing the same SD name for 685 different SPs creates a dependency in deleting an SD. An SD can be 686 deleted only after all TAs associated with this SD is deleted. An SP 687 cannot delete a Security Domain on its own with a TAM if a TAM 688 decides to introduce such sharing. There are cases where multiple 689 virtual SPs belong to the same organization, and a TAM chooses to use 690 the same SD name for those SPs. This is totally up to the TAM 691 implementation and out of scope of this specification. 693 5.4. SD Owner Identification and TAM Certificate Requirements 695 There is a need of cryptographically binding proof about the owner of 696 an SD in a device. When an SD is created on behalf of a TAM, a 697 future request from the TAM must present itself as a way that the TEE 698 can verify it is the true owner. The certificate itself cannot 699 reliably used as the owner because TAM may change its certificate. 701 To this end, each TAM will be associated with a trusted identifier 702 defined as an attribute in the TAM certificate. This field is kept 703 the same when the TAM renew its certificates. A TAM CA is 704 responsible to vet the requested TAM attribute value. 706 This identifier value must not collide among different TAM providers, 707 and one TAM shouldn't be able to claim the identifier used by another 708 TAM provider. 710 The certificate extension name to carry the identifier can initially 711 use SubjectAltName:registeredID. A dedicated new extension name may 712 be registered later. 714 One common choice of the identifier value is the TAM's service URL. 715 A CA can verify the domain ownership of the URL with the TAM in the 716 certificate enrollment process. 718 A TEE can assign this certificate attribute value as the TAM owner ID 719 for the SDs that are created for the TAM. 721 An alternative way to represent an SD ownership by a TAM is to have a 722 unique secret key upon SD creation such that only the creator TAM is 723 able to produce a Proof-of-Possession (POP) data with the secret. 725 5.5. Service Provider Container 727 A sample Security Domain hierarchy for the TEE is shown below. 729 ---------- 730 | TEE | 731 ---------- 732 | 733 | ---------- 734 |----------| SP1 SD1 | 735 | ---------- 736 | ---------- 737 |----------| SP1 SD2 | 738 | ---------- 739 | ---------- 740 |----------| SP2 SD1 | 741 ---------- 743 OTrP segregates SDs and TAs such that a TAM can only manage or 744 retrieve data for SDs and TAs that it previously created for the SPs 745 it represents. 747 6. OTrP Agent 749 A TEE and TAs that run inside the TEE don't generally have capability 750 to communicate to the outside of the hosting device, for example, the 751 TEE specified by Global Platform groups [GPTEE]. This calls for a 752 software module in the REE world to handle the network communication. 753 Each Client Application in REE may carry this communication 754 functionality but it must also interact with the TEE for the message 755 exchange. The TEE interaction will vary according to different TEEs. 756 In order for a Client Application to transparently support different 757 TEEs, it is imperative to have a common interface for a Client 758 Application to invoke for exchanging messages with TEEs. 760 A shared OTrP Agent comes to meed this need. An OTrP Agent is a Rich 761 Application or SDK that facilitates communication between a TAM and 762 TEE. It also provides interfaces for TAM SDK or Client Applications 763 to query and trigger TA installation that the application needs to 764 use. 766 This interface for Client Applications may be commonly an Android 767 service call for an Android powered device. A Client Application 768 interacts with a TAM, and turns around to pass messages received from 769 TAM to OTrP Agent. 771 In all cases, a Client Application needs to be able to identify an 772 OTrP Agent that it can use. 774 6.1. Role of OTrP Agent 776 An OTrP Agent abstracts the message exchanges with the TEE in a 777 device. The input data is originated from a TAM that a Client 778 Application connects. A Client Application may also directly call 779 OTrP Agent for some TA query functions. 781 OTrP Agent may internally process a request from TAM. At least, it 782 needs to know where to route a message, e.g. TEE instance. It 783 doesn't need to process or verify message content. 785 OTrP Agent returns TEE / TFW generated response messages to the 786 caller. OTrP Agent isn't expected to handle any network connection 787 with an application or TAM. 789 OTrP Agent only needs to return an OTrP Agent error message if the 790 TEE is not reachable for some reason. Other errors are represented 791 as response messages returned from the TEE which will then be passed 792 to the TAM. 794 6.2. OTrP Agent and Global Platform TEE Client API 796 A Client Application may use Global Platform (GP) TEE API for TA 797 communication. OTrP may use the GP TEE Client API but it is internal 798 to OTrP implementation that converts given messages from TAM. More 799 details can be found at [GPTEECLAPI]. 801 6.3. OTrP Agent Implementation Consideration 803 A Provider should consider methods of distribution, scope and 804 concurrency on device and runtime options when implementing an OTrP 805 Agent. Several non-exhaustive options are discussed below. 806 Providers are encouraged to take advantage of the latest 807 communication and platform capabilities to offer the best user 808 experience. 810 6.3.1. OTrP Agent Distribution 812 OTrP Agent installation is commonly carried out at OEM time. A user 813 can dynamically download and install an OTrP Agent on-demand. 815 It is important to ensure a legitimate OTrP Agent is installed and 816 used. If an OTrP Agent is compromised it may send rogue messages to 817 TAM and TEE and introduce additional risks. 819 6.3.2. Number of OTrP Agent 821 We anticipate only one shared OTrP Agent instance in a device. The 822 device's TEE vendor will most probably supply one OTrP Agent. 823 Potentially we expect some open source. 825 With one shared OTrP Agent, the OTrP Agent provider is responsible to 826 allow multiple TAMs and TEE providers to achieve interoperability. 827 With a standard OTrP Agent interface, TAM can implement its own SDK 828 for its SP Client Applications to work with this OTrP Agent. 830 Multiple independent OTrP Agent providers can be used as long as they 831 have standard interface to a Client Application or TAM SDK. Only one 832 OTrP Agent is expected in a device. 834 TAM providers are generally expected to provide SDK for SP 835 applications to interact with an OTrP Agent for the TAM and TEE 836 interaction. 838 6.4. OTrP Agent Interfaces for Client Applications 840 A Client Application shall be responsible for relaying messages 841 between the OTrP agent and the TAM. 843 If a failure occurs during calling OTrP Agent, an error message 844 described in "Common Errors" section (see Section 7.6) will be 845 returned. 847 6.4.1. ProcessOTrPMessage call 849 Description 851 A Client Application will use this method of the OTrP Agent in a 852 device to pass OTrP messages from a TAM. The method is 853 responsible for interacting with the TEE and for forwarding the 854 input message to the TEE. It also returns TEE generated response 855 message back to the Client Application. 857 Inputs: 859 TAMInMsg - OTrP message generated in a TAM that is passed to this 860 method from a Client Application. 862 Outputs: 864 A TEE-generated OTrP response message (which may be a successful 865 response or be a response message containing an error raised 866 within the TEE) for the client application to forward to the TAM. 868 In the event of the OTrP agent not being able to communicate with 869 the TEE, a OTrPAgentException shall be thrown. 871 6.4.2. GetTAInformation call 873 Description 875 A Client Application may quickly query local TEE about a 876 previously installed TA without requiring TAM each time if it has 877 had the TA's identifier and previously saved TEE SP AIK public key 878 for TA information integrity verification. 880 Inputs: 882 { 883 "TAQuery": { 884 "spid": "", 885 "taid": "" 886 } 887 } 889 Outputs: 891 The OTrP Agent is expected to return TA signer and TAM signer 892 certificate along with other metadata information about the TA 893 associated with the given identifier. It follows the underlying 894 TEE trust model for authoring the local TA query from a Client 895 Application. 897 The output is a JSON message that is generated by the TEE. It 898 contains the following information: 900 * tamid 902 * SP ID 904 * TA signer certificate 906 * TAM certificate 908 The message is signed with TEE SP AIK private key. 910 The Client Application is expected to consume the response as 911 follows. 913 The Client Application gets signed TA metadata, in particular, the 914 TA signer certificate. It is able to verify that the result is 915 from device by checking signer against TEE SP AIK public key it 916 gets in some earlier interaction with TAM. 918 If this is a new Client Application in the device that hasn't had 919 TEE SP AIK public key for the response verification, the 920 application can contact the TAM first to do GetDeviceState, and 921 TAM will return TEE SP AIK public key to the app for this 922 operation to proceed. 924 Output Message: 926 { 927 "TAInformationTBS": { 928 "taid": "", 929 "tamid": "", 931 "spid": "", 932 "signercert": "", 934 "signercacerts": [ // the full list of CA certificate chain 935 // including the root CA 936 ], 937 "cacert": "" 939 ], 940 "tamcert": "", 942 "tamcacerts": [ // the full list of CA certificate chain 943 // including the root CA 944 ], 945 "cacert":"" 947 ] 948 } 949 } 951 { 952 "TAInformation": { 953 "payload": "", 955 "protected": "", 956 "header": { 957 "signer": {""} 959 }, 960 "signature": "" 962 } 963 } 965 where the definitions of BASE64 and BASE64URL refer to [RFC4648]. 967 A sample JWK public key representation refers to an example in 968 [RFC7517]. 970 6.5. Sample End-to-End Client Application Flow 972 6.5.1. Case 1: A New Client Application Uses a TA 974 1. During the Client Application installation time, the Client 975 Application calls TAM to initialize the device preparation step. 977 A. The Client Application knows it wants to use a Trusted 978 Application TA1 but the application doesn't know whether TA1 979 has been installed or not. It can use GP TEE Client API 980 [GPTEECLAPI] to check the existence of TA1 first. If it 981 detects that TA1 doesn't exist, it will contact TAM to 982 initiate the installation of TA1. Note that TA1 could have 983 been previously installed by other Client Applications from 984 the same service provider in the device. 986 B. The Client Application sends the TAM the TA list that it 987 depends on. The TAM will query a device for the Security 988 Domains and TAs that have been installed, and instructs the 989 device to install any dependent TAs that have not been 990 installed. 992 C. In general, the TAM has the latest TA list and their status 993 in a device because all operations are instructed by TAM. 994 TAM has such visibility because all Security Domain deletion 995 and TA deletion are managed by the TAM; the TAM could have 996 stored the state when a TA is installed, updated and 997 deleted. There is also the possibility that an update 998 command is carried out inside TEE but a response is never 999 received in TAM. There is also possibility that some manual 1000 local reset is done in a device that the TAM isn't aware of 1001 the changes. 1003 2. The TAM generates message: GetDeviceStateRequest 1005 3. The Client Application passes the JSON message 1006 GetDeviceStateRequest to OTrP Agent call ProcessOTrPMessage. 1007 The communication between a Client Application and an OTrP Agent 1008 is up to the implementation of the OTrP Agent. 1010 4. The OTrP Agent routes the message to the active TEE. Multiple 1011 TEE case: it is up to OTrP Agent to figure this out. This 1012 specification limits the support to only one active TEE, which 1013 is the typical case today. 1015 5. The target active TEE processes the received OTrP message, and 1016 returns a JSON message GetDeviceStateResponse. 1018 6. The OTrP Agent passes the GetDeviceStateResponse to the Client 1019 Application. 1021 7. The Client Application sends GetDeviceStateResponse to the TAM. 1023 8. The TAM processes the GetDeviceStateResponse. 1025 A. Extract TEEspaik for the SP, signs TEEspaik with TAM signer 1026 key 1028 B. Examine SD list and TA list 1030 9. The TAM continues to carry out other actions based on the need. 1031 The next call could be instructing the device to install a 1032 dependent TA. 1034 A. Assume a dependent TA isn't in the device yet, the TAM may 1035 do the following: (1) create an SD in which to install the 1036 TA by sending a CreateSDRequest message. The message is 1037 sent back to the Client Application, and then the OTrP Agent 1038 and TEE to process; (2) install a TA with an 1039 InstallTARequest message. 1041 B. If a Client Application depends on multiple TAs, the Client 1042 Application should expect multiple round trips of the TA 1043 installation message exchanges. 1045 10. At the last TAM and TEE operation, the TAM returns the signed 1046 TEE SP AIK public key to the application. 1048 11. The Client Application stores the TEEspaik for future loaded TA 1049 trust check. 1051 12. If the TAM finds that this is a fresh device that does not have 1052 any SD for the SP yet, then the TAM may next create an SD for 1053 the SP. 1055 13. During Client Application installation, the application checks 1056 whether required Trusted Applications are already installed, 1057 which may have been provided by the TEE. If needed, it will 1058 contact its TAM service to determine whether the device is ready 1059 or install TA list that this application needs. 1061 6.5.2. Case 2: A Previously Installed Client Application Calls a TA 1063 1. The Client Application checks the device readiness: (a) whether 1064 it has a TEE; (b) whether it has TA that it depends. It may 1065 happen that TAM has removed the TA this application depends on. 1067 2. The Client Application calls the OTrP Agent to query the TA. 1069 3. The OTrP Agent queries the TEE to get TA information. If the 1070 given TA doesn't exist, an error is returned. 1072 4. The Client Application parses the TAInformation message. 1074 5. If the TA doesn't exist, the Client Application calls its TAM to 1075 install the TA. If the TA exists, the Client Application 1076 proceeds to call the TA. 1078 7. OTrP Messages 1080 The main OTrP component is the set of standard JSON messages created 1081 by a TAM to deliver device SD and TA management commands to a device, 1082 and device attestation and response messages created by TEE to 1083 respond to TAM OTrP Messages. 1085 An OTrP Message is designed to provide end-to-end security. It is 1086 always signed by its creator. In addition, an OTrP Message is 1087 typically encrypted such that only the targeted device TEE or TAM is 1088 able to decrypt and view the actual content. 1090 7.1. Message Format 1092 OTrP Messages use the JSON format for JSON's simple readability and 1093 moderate data size in comparison with alternative TLV and XML 1094 formats. More compact CBOR format may be used as an alternative 1095 choice. 1097 JSON Message security has developed JSON Web Signing and JSON Web 1098 Encryption standard in the IETF Workgroup JOSE, see JWS [RFC7515] and 1099 JWE [RFC7516]. The OTrP Messages in this protocol will leverage the 1100 basic JWS and JWE to handle JSON signing and encryption. 1102 7.2. Message Naming Convention 1104 For each TAM command "xyz"", OTrP use the following naming convention 1105 to represent its raw message content and complete request and 1106 response messages: 1108 +-----------------------+----------------+---------------------+ 1109 | Purpose | Message Name | Example | 1110 +-----------------------+----------------+---------------------+ 1111 | Request to be signed | xyzTBSRequest | CreateSDTBSRequest | 1112 | | | | 1113 | Request message | xyzRequest | CreateSDRequest | 1114 | | | | 1115 | Response to be signed | xyzTBSResponse | CreateSDTBSResponse | 1116 | | | | 1117 | Response message | xyzResponse | CreateSDResponse | 1118 +-----------------------+----------------+---------------------+ 1120 7.3. Request and Response Message Template 1122 An OTrP Request message uses the following format: 1124 { 1125 "TBSRequest": { 1126 1127 } 1128 } 1130 A corresponding OTrP Response message will be as follows. 1132 { 1133 "TBSResponse": { 1134 1135 } 1136 } 1138 7.4. Signed Request and Response Message Structure 1140 A signed request message will generally include only one signature, 1141 and uses the flattened JWS JSON Serialization Syntax, see 1142 Section 7.2.2 in [RFC7515]. 1144 A general JWS object looks like the following. 1146 { 1147 "payload": "", 1148 "protected": "", 1149 "header": { 1150 , 1151 }, 1152 "signature": "" 1153 } 1154 OTrP signed messages only require the signing algorithm as the 1155 mandate header in the property "protected". The "non-integrity- 1156 protected header contents" is optional. 1158 OTrP signed message will be given an explicit Request or Response 1159 property name. In other words, a signed Request or Response uses the 1160 following template. 1162 A general JWS object looks like the following. 1164 { 1165 "[Request | Response]": { 1166 TBS[Request | Response] 1167 } 1168 } 1170 With the standard JWS message format, a signed OTrP Message looks 1171 like the following. 1173 { 1174 "[Request | Response]": { 1175 "payload": "TBS[Request | Response]>", 1176 "protected": "", 1177 "header": , 1178 "signature": "" 1179 } 1180 } 1182 The top element " [Signed][Request | Response]" cannot be fully 1183 trusted to match the content because it doesn't participate in the 1184 signature generation. However, a recipient can always match it with 1185 the value associated with the property "payload". It purely serves 1186 to provide a quick reference for reading and method invocation. 1188 Furthermore, most properties in an unsigned OTrP messages are 1189 encrypted to provide end-to-end confidentiality. The only OTrP 1190 message that isn't encrypted is the initial device query message that 1191 asks for the device state information. 1193 Thus a typical OTrP Message consists of an encrypted and then signed 1194 JSON message. Some transaction data such as transaction ID and TEE 1195 information may need to be exposed to the OTrP Agent for routing 1196 purpose. Such information is excluded from JSON encryption. The 1197 device's signer certificate itself is encrypted. The overall final 1198 message is a standard signed JSON message. 1200 As required by JSW/JWE, those JWE and JWS related elements will be 1201 BASE64URL encoded. Other binary data elements specific to the OTrP 1202 specification are BASE64-encoded. This specification indicates 1203 elements that should be BASE64 and those elements that are to be 1204 BASE64URL encoded. 1206 7.4.1. Identifying Signing and Encryption Keys for JWS/JWE Messaging 1208 JWS and JWE messaging allow various options for identifying the 1209 signing and encryption keys, for example, it allows optional elements 1210 including "x5c", "x5t" and "kid" in the header to cover various 1211 possibilities. 1213 To protect privacy, it is important that the device's certificate is 1214 released only to a trusted TAM, and that it is encrypted. The TAM 1215 will need to know the device certificate, but untrusted parties must 1216 not be able to get the device certificate. All OTrP messaging 1217 conversations between a TAM and device begin with 1218 GetDeviceStateRequest / GetDeviceStateResponse. These messages have 1219 elements built into them to exchange signing certificates, described 1220 in the section Section 9. Any subsequent messages in the 1221 conversation that follow on from this implicitly use the same 1222 certificates for signing/encryption, and as a result the certificates 1223 or references may be omitted in those subsequent messages. 1225 In other words, the signing key identifier in the use of JWS and JWE 1226 here may be absent in the subsequent messages after the initial 1227 GetDeviceState query. 1229 This has an implication on the TEE and TAM implementation: they have 1230 to cache the signer certificates for the subsequent message signature 1231 validation in the session. It may be easier for a TAM service to 1232 cache transaction session information but not so for a TEE in a 1233 device. A TAM can get a device's capability by checking the response 1234 message from a TEE to decide whether it should include its TAM signer 1235 certificate and OCSP data in each subsequent request message. The 1236 device's caching capability is reported in GetDeviceStateResponse 1237 signerreq parameter. 1239 7.5. JSON Signing and Encryption Algorithms 1241 The OTrP JSON signing algorithm shall use SHA256 or a stronger hash 1242 method with respective key type. JSON Web Algorithm RS256 or ES256 1243 [RFC7518] SHALL be used for RSA with SHA256 and ECDSA with SHA256. 1244 If RSA with SHA256 is used, the JSON web algorithm representation is 1245 as follows. 1247 {"alg":"RS256"} 1249 The (BASE64URL encoded) "protected" header property in a signed 1250 message looks like the following: 1252 "protected":"eyJhbGciOiJSUzI1NiJ9" 1254 If ECSDA with P-256 curve and SHA256 are used for signing, the JSON 1255 signing algorithm representation is as follows. 1257 {"alg":"ES256"} 1259 The value for the "protected" field will be the following. 1261 eyJhbGciOiJFUzI1NiJ9 1263 Thus, a common OTrP signed message with ES256 looks like the 1264 following. 1266 { 1267 "payload": "", 1268 "protected": "eyJhbGciOiJFUzI1NiJ9", 1269 "signature": "" 1270 } 1272 The OTrP JSON message encryption algorithm SHOULD use one of the 1273 supported algorithms defined in the later chapter of this document. 1274 JSON encryption uses a symmetric key as its "Content Encryption Key 1275 (CEK)". This CEK is encrypted or wrapped by a recipient's key. The 1276 OTrP recipient typically has an asymmetric key pair. Therefore, the 1277 CEK will be encrypted by the recipient's public key. 1279 A compliant implementation shall support the following symmetric 1280 encryption algorithm and anticipate future new algorithms. 1282 {"enc":"A128CBC-HS256"} 1284 This algorithm represents encryption with AES 128 in CBC mode with 1285 HMAC SHA 256 for integrity. The value of the property "protected" in 1286 a JWE message will be 1288 eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0 1290 An encrypted JSON message looks like the following. 1292 { 1293 "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0", 1294 "recipients": [ 1295 { 1296 "header": { 1297 "alg": "" 1298 }, 1299 "encrypted_key": "" 1300 } 1301 ], 1302 "iv": "", 1303 "ciphertext": "", 1305 "tag": "" 1306 } 1308 OTrP doesn't use JWE AAD (Additional Authenticated Data) because each 1309 message is always signed after the message is encrypted. 1311 7.5.1. Supported JSON Signing Algorithms 1313 The following JSON signature algorithm is mandatory support in the 1314 TEE and TAM: 1316 o RS256 1318 ES256 is optional to support. 1320 7.5.2. Support JSON Encryption Algorithms 1322 The following JSON authenticated encryption algorithm is mandatory 1323 support in TEE and TAM. 1325 o A128CBC-HS256 1327 A256CBC-HS512 is optional to support. 1329 7.5.3. Supported JSON Key Management Algorithms 1331 The following JSON key management algorithm is mandatory support in 1332 TEE and TAM. 1334 o RSA1_5 1336 ECDH-ES+A128KW and ECDH-ES+A256KW are optional to support. 1338 7.6. Common Errors 1340 An OTrP Response message typically needs to report the operation 1341 status and error causes if an operation fails. The following JSON 1342 message elements should be used across all OTrP Messages. 1344 "status": "pass | fail" 1346 "reason": { 1347 "error-code": "", 1348 "error-message": "" 1349 } 1351 "ver": "" 1353 7.7. OTrP Message List 1355 The following table lists the OTrP commands and therefore 1356 corresponding Request and Response messages defined in this 1357 specification. Additional messages may be added in the future when 1358 new task messages are needed. 1360 GetDeviceState - 1361 A TAM queries a device's current state with a message 1362 GetDeviceStateRequest. A device TEE will report its version, its 1363 FW version, and list of all SDs and TAs in the device that is 1364 managed by the requesting TAM. TAM may determine whether the 1365 device is trustworthy and decide to carry out additional commands 1366 according to the response from this query. 1368 CreateSD - 1369 A TAM instructs a device TEE to create an SD for an SP. The 1370 recipient TEE will check whether the requesting TAM is 1371 trustworthy. 1373 UpdateSD - 1374 A TAM instructs a device TEE to update an existing SD. A typical 1375 update need comes from SP certificate change, TAM certificate 1376 change and so on. The recipient TEE will verify whether the TAM 1377 is trustworthy and owns the SD. 1379 DeleteSD - 1380 A TAM instructs a device TEE to delete an existing SD. A TEE 1381 conditionally deletes TAs loaded in the SD according to a request 1382 parameter. An SD cannot be deleted until all TAs in this SD are 1383 deleted. If this is the last SD for an SP, TEE MAY also delete 1384 TEE SP AIK key for this SP. 1386 InstallTA - 1387 A TAM instructs a device to install a TA into an SD for a SP. 1388 The TEE in a device will check whether the TAM and TA are 1389 trustworthy. 1391 UpdateTA - 1392 A TAM instructs a device to update a TA into an SD for an SP. 1393 The change may commonly be bug fix for a previously installed TA. 1395 DeleteTA - 1396 A TAM instructs a device to delete a TA. The TEE in a device 1397 will check whether the TAM and TA are trustworthy. 1399 7.8. OTrP Request Message Routing Rules 1401 For each command that a TAM wants to send to a device, the TAM 1402 generates a request message. This is typically triggered by a Client 1403 Application that uses the TAM. The Client Application initiates 1404 contact with the TAM and receives TAM OTrP Request messages according 1405 to the TAM's implementation. The Client Application forwards the 1406 OTrP message to an OTrP Agent in the device, which in turn sends the 1407 message to the active TEE in the device. 1409 The current version of this specification assumes that each device 1410 has only one active TEE, and the OTrP Agent is responsible to connect 1411 to the active TEE. This is the case today with devices in the 1412 market. 1414 When the TEE responds to a request, the OTrP Agent gets the OTrP 1415 response messages back to the Client Application that sent the 1416 request. In case the target TEE fails to respond to the request, the 1417 OTrP Agent will be responsible to generate an error message to reply 1418 the Client Application. The Client Application forwards any data it 1419 received to its TAM. 1421 7.8.1. SP Anonymous Attestation Key (SP AIK) 1423 When the first new Security Domain is created in a TEE for an SP, a 1424 new key pair is generated and associated with this SP. This key pair 1425 is used for future device attestation to the service provider instead 1426 of using the device's TEE key pair. 1428 8. Transport Protocol Support 1430 The OTrP message exchange between a TEE device and TAM generally 1431 takes place between a Client Application in REE and TAM. A device 1432 that is capable to run a TEE and PKI based cryptographic attestation 1433 isn't generally resource constraint to carry out standard HTTPS 1434 connections. A compliant device and TAM SHOULD support HTTPs. 1436 9. Detailed Messages Specification 1438 For each message in the following sections all JSON elements are 1439 mandatory if not explicitly indicated as optional. 1441 9.1. GetDeviceState 1443 This is the first command that a TAM will send to a device. This 1444 command is triggered when an SP's Client Application contacts its TAM 1445 to check whether the underlying device is ready for TA operations. 1447 This command queries a device's current TEE state. A device TEE will 1448 report its version, its FW version, and list of all SDs and TAs in 1449 the device that is managed by the requesting TAM. TAM may determine 1450 whether the device is trustworthy and decide to carry out additional 1451 commands according to the response from this query. 1453 The request message of this command is signed by the TAM. The 1454 response message from the TEE is encrypted. A random message 1455 encryption key (MK) is generated by TEE, and this encrypted key is 1456 encrypted by the TAM's public key such that only the TAM that sent 1457 the request is able to decrypt and view the response message. 1459 9.1.1. GetDeviceStateRequest message 1461 { 1462 "GetDeviceStateTBSRequest": { 1463 "ver": "1.0", 1464 "rid": "", 1465 "tid": "", 1466 "ocspdat": ["], 1467 "supportedsigalgs": [] 1468 } 1469 } 1471 The request message consists of the following data elements: 1473 ver - version of the message format 1475 rid - a unique request ID generated by the TAM 1477 tid - a unique transaction ID to trace request and response. This 1478 can be from a prior transaction's tid field, and can be used in 1479 subsequent message exchanges in this TAM session. The 1480 combination of rid and tid MUST be made unique. 1482 ocspdat - A list of OCSP stapling data respectively for the TAM 1483 certificate and each of the CA certificates up to the root 1484 certificate. The TAM provides OCSP data such that a recipient 1485 TEE can validate the TAM certificate chain revocation status 1486 without making its own external OCSP service call. A TEE MAY 1487 cache the CA OCSP data such that the array may contain only the 1488 OCSP stapling data for the TAM certificate in subsequent 1489 exchanges. This is a mandatory field. 1491 supportedsigalgs - an optional property to list the signing 1492 algorithms that the TAM is able to support. A recipient TEE MUST 1493 choose an algorithm in this list to sign its response message if 1494 this property is present in a request. If it is absent, the TEE 1495 may use any compliant signing algorithm that is listed as 1496 mandatory support in this specification. 1498 The final request message is JSON signed message of the above raw 1499 JSON data with TAM's certificate. 1501 { 1502 "GetDeviceStateRequest": { 1503 "payload": "", 1505 "protected": "", 1506 "header": { 1507 "x5c": "" 1509 }, 1510 "signature":"" 1511 } 1512 } 1514 The signing algorithm SHOULD use SHA256 with respective key type. 1515 The mandatory algorithm support is the RSA signing algorithm. The 1516 signer header "x5c" is used to include the TAM signer certificate up 1517 to the root CA certificate. 1519 9.1.2. Request processing requirements at a TEE 1521 Upon receiving a request message GetDeviceStateRequest at a TEE, the 1522 TEE MUST validate a request: 1524 1. Validate JSON message signing. If it doesn't pass, an error 1525 message is returned. 1527 2. Validate that the request TAM certificate is chained to a trusted 1528 CA that the TEE embeds as its trust anchor. 1530 * Cache the CA OCSP stapling data and certificate revocation 1531 check status for other subsequent requests. 1533 * A TEE can use its own clock time for the OCSP stapling data 1534 validation. 1536 3. Collect Firmware signed data 1538 * This is a capability in ARM architecture that allows a TEE to 1539 query Firmware to get FW signed data. 1541 4. Collect SD information for the SD owned by this TAM 1543 9.1.3. Firmware Signed Data 1545 Firmware isn't expected to process or produce JSON data. It is 1546 expected to just sign some raw bytes of data. 1548 The data to be signed by TFW key needs be some unique random data 1549 each time. The (UTF-8 encoded) "tid" value from the 1550 GetDeviceStateTBSRequest shall be signed by the firmware. TAM isn't 1551 expected to parse TFW data except the signature validation and signer 1552 trust path validation. 1554 It is possible that a TEE can get some valid TFW signed data from 1555 another device. The TEE is responsible to validate TFW integrity to 1556 ensure that the underlying device firmware is trustworthy. A TAM 1557 trusts the TEE and the TFW trust status check carried out by the TEE. 1559 TfwData: { 1560 "tbs": "", 1561 "cert": "", 1562 "sigalg": "Signing method", 1563 "sig": "" 1564 } 1566 It is expected that a FW uses standard signature methods for maximal 1567 interoperability with TAM providers. The mandatory support list of 1568 signing algorithm is RSA with SHA256. 1570 The JSON object above is constructed by a TEE with data returned from 1571 the FW. It isn't a standard JSON signed object. The signer 1572 information and data to be signed must be specially processed by a 1573 TAM according to the definition given here. The data to be signed is 1574 the raw data. 1576 9.1.3.1. Supported Firmware Signature Methods 1578 TAM providers shall support the following signature methods. A 1579 firmware provider can choose one of the methods in signature 1580 generation. 1582 o RSA with SHA256 1584 o ECDSA with SHA 256 1586 The value of "sigalg" in the TfwData JSON message SHOULD use one of 1587 the following: 1589 o RS256 1591 o ES256 1593 9.1.4. Post Conditions 1595 Upon successful request validation, the TEE information is collected. 1596 There is no change in the TEE in the device. 1598 The response message shall be encrypted where the encryption key 1599 shall be a symmetric key that is wrapped by TAM's public key. The 1600 JSON Content Encryption Key (CEK) is used for this purpose. 1602 9.1.5. GetDeviceStateResponse Message 1604 The message has the following structure. 1606 { 1607 "GetDeviceTEEStateTBSResponse": { 1608 "ver": "1.0", 1609 "status": "pass | fail", 1610 "rid": "", 1611 "tid": "", 1612 "signerreq": true | false // about whether TAM needs to send 1613 signer data again in subsequent messages, 1614 "edsi": "" 1615 } 1616 } 1618 where 1620 signerreq - true if the TAM should send its signer certificate and 1621 OCSP data again in the subsequent messages. The value may be 1622 "false" if the TEE caches the TAM's signer certificate and OCSP 1623 status. 1625 rid - the request ID from the request message 1627 tid - the tid from the request message 1629 edsi - the main data element whose value is JSON encrypted message 1630 over the following Device State Information (DSI). 1632 The Device State Information (DSI) message consists of the following. 1634 { 1635 "dsi": { 1636 "tfwdata": { 1637 "tbs": "" 1638 "cert": "", 1639 "sigalg": "Signing method", 1640 "sig": "" 1641 }, 1642 "tee": { 1643 "name": "", 1644 "ver": "", 1645 "cert": "", 1646 "cacert": "", 1648 "sdlist": { 1649 "cnt": "", 1650 "sd": [ 1651 { 1652 "name": "", 1653 "spid": "", 1654 "talist": [ 1655 { 1656 "taid": "", 1657 "taname": "" // optional 1659 } 1660 ] 1661 } 1662 ] 1663 }, 1664 "teeaiklist": [ 1665 { 1666 "spaik": "", 1667 "spaiktype": "", 1668 "spid": "" 1669 } 1670 ] 1671 } 1672 } 1673 } 1675 The encrypted JSON message looks like the following. 1677 { 1678 "protected": "", 1680 "recipients": [ 1681 { 1682 "header": { 1683 "alg": "RSA1_5" 1684 }, 1685 "encrypted_key": "" 1686 } 1687 ], 1688 "iv": "", 1689 "ciphertext": "", 1691 "tag": "" 1692 } 1694 Assume we encrypt plaintext with AES 128 in CBC mode with HMAC SHA 1695 256 for integrity, the encryption algorithm header is: 1697 {"enc":"A128CBC-HS256"} 1699 The value of the property "protected" in the above JWE message will 1700 be 1702 eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0 1704 In other words, the above message looks like the following: 1706 { 1707 "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0", 1708 "recipients": [ 1709 { 1710 "header": { 1711 "alg": "RSA1_5" 1712 }, 1713 "encrypted_key": "" 1714 } 1715 ], 1716 "iv": "", 1717 "ciphertext": "", 1719 "tag": "" 1720 } 1722 The full response message looks like the following: 1724 { 1725 "GetDeviceTEEStateTBSResponse": { 1726 "ver": "1.0", 1727 "status": "pass | fail", 1728 "rid": "", 1729 "tid": "", 1730 "signerreq": "true | false", 1731 "edsi": { 1732 "protected": "", 1734 "recipients": [ 1735 { 1736 "header": { 1737 "alg": "RSA1_5" 1738 }, 1739 "encrypted_key": "" 1740 } 1741 ], 1742 "iv": "", 1743 "ciphertext": "", 1745 "tag": "" 1746 } 1747 } 1748 } 1750 The CEK will be encrypted by the TAM public key in the device. The 1751 TEE signed message has the following structure. 1753 { 1754 "GetDeviceTEEStateResponse": { 1755 "payload": "", 1757 "protected": "", 1758 "signature": "" 1759 } 1760 } 1762 The signing algorithm shall use SHA256 with respective key type, see 1763 Section 7.5.1. 1765 The final GetDeviceStateResponse response message consists of an 1766 array of TEE responses. 1768 { 1769 "GetDeviceStateResponse": [ // JSON array 1770 {"GetDeviceTEEStateResponse": ...}, 1771 ... 1772 {"GetDeviceTEEStateResponse": ...} 1773 ] 1774 } 1776 9.1.6. Error Conditions 1778 An error may occur if a request isn't valid or the TEE runs into some 1779 error. The list of possible error conditions is the following. 1781 ERR_REQUEST_INVALID The TEE meets the following conditions with a 1782 request message: (1) The request from a TAM has an invalid message 1783 structure; mandatory information is absent in the message; or an 1784 undefined member or structure is included. (2) TEE fails to verify 1785 the signature of the message or fails to decrypt its contents. 1787 ERR_UNSUPPORTED_MSG_VERSION The TEE receives a version of message 1788 that the TEE can't deal with. 1790 ERR_UNSUPPORTED_CRYPTO_ALG The TEE receives a request message 1791 encoded with a cryptographic algorithm that the TEE doesn't 1792 support. 1794 ERR_TFW_NOT_TRUSTED The TEE considers the underlying device firmware 1795 be not trustworthy. 1797 ERR_TAM_NOT_TRUSTED The TEE needs to make sure whether the TAM is 1798 trustworthy by checking the validity of the TAM certificate and 1799 OCSP stapling data and so on. If the TEE finds the TAM is not 1800 reliable, it returns this error code. 1802 ERR_TEE_FAIL If the TEE fails to process a request because of its 1803 internal error but is able to sign an error response message, it 1804 will return this error code. 1806 ERR_AGENT_TEE_FAIL The TEE failed to respond to a TAM request. The 1807 OTrP Agent will construct an error message in responding to the 1808 TAM's request. The error message will not be signed. 1810 The response message will look like the following if the TEE signing 1811 can work to sign the error response message. 1813 { 1814 "GetDeviceTEEStateTBSResponse": { 1815 "ver": "1.0", 1816 "status": "fail", 1817 "rid": "", 1818 "tid": "", 1819 "reason": {"error-code":""} 1820 "supportedsigalgs": [] 1822 } 1823 } 1825 where 1827 supportedsigalgs - an optional property to list the JWS signing 1828 algorithms that the active TEE supports. When a TAM sends a 1829 signed message that the TEE isn't able to validate, it can 1830 include signature algorithms that it is able to consume in this 1831 status report. A TAM can generate a new request message to retry 1832 the management task with a TEE-supported signing algorithm. 1834 If the TEE isn't able to sign an error message due to an internal 1835 device error, a general error message should be returned by the OTrP 1836 Agent. 1838 9.1.7. TAM Processing Requirements 1840 Upon receiving a GetDeviceStateResponse message at a TAM, the TAM 1841 MUST validate the following. 1843 o Parse to get list of GetDeviceTEEStateResponse JSON objects 1845 o Parse the JSON "payload" property and decrypt the JSON element 1846 "edsi". The decrypted message contains the TEE signer 1847 certificate. 1849 o Validate the GetDeviceTEEStateResponse JSON signature. The signer 1850 certificate is extracted from the decrypted message in the last 1851 step. 1853 o Extract TEE information and check it against its TEE acceptance 1854 policy. 1856 o Extract the TFW signed element, and check the signer and data 1857 integration against its TFW policy. 1859 o Check the SD list and TA list and prepare for a subsequent command 1860 such as "CreateSD" if it needs to have a new SD for an SP. 1862 9.2. Security Domain Management 1864 9.2.1. CreateSD 1866 This command is typically preceded with a GetDeviceState command that 1867 has acquired the device information of the target device by the TAM. 1868 The TAM sends such a command to instruct a TEE to create a new 1869 Security Domain for an SP. 1871 A TAM sends an OTrP CreateSDRequest Request message to a device TEE 1872 to create a Security Domain for an SP. Such a request is signed by 1873 the TAM where the TAM signer may or may not be the same as the SP's 1874 TA signer certificate. The resulting SD is associated with two 1875 identifiers for future management: 1877 o TAM as the owner. The owner identifier is a registered unique TAM 1878 ID that is stored in the TAM certificate. 1880 o SP identified by its TA signer certificate as the authorization. 1881 A TAM can add more than one SP certificate to an SD. 1883 A Trusted Application that is signed by a matching SP signer 1884 certificate for an SD is eligible to be installed into that SD. The 1885 TA installation into an SD by a subsequent InstallTARequest message 1886 may be instructed from a TAM. 1888 9.2.1.1. CreateSDRequest Message 1889 The request message for CreateSD has the following JSON format. 1891 { 1892 "CreateSDTBSRequest": { 1893 "ver": "1.0", 1894 "rid": "", 1895 "tid": "", // this may be from prior message 1896 "tee": "", 1897 "nextdsi": true | false, 1898 "dsihash": "", 1899 "content": ENCRYPTED { // this piece of JSON data will be 1900 // encrypted 1901 "spid": "", 1902 "sdname": "", 1903 "spcert": "", 1904 "tamid": "", 1906 "did": "" 1907 } 1908 } 1909 } 1911 In the message, 1913 rid - A unique value to identify this request 1915 tid - A unique value to identify this transaction. It can have the 1916 same value for the tid in the preceding GetDeviceStateRequest. 1918 tee - TEE ID returned from the previous GetDeviceStateResponse. 1920 nextdsi - Indicates whether the up-to-date Device State Information 1921 (DSI) is expected in the response from the TEE to this request. 1923 dsihash - The BASE64-encoded SHA256 hash value of the DSI data 1924 returned in the prior TAM operation with this target TEE. This 1925 value is always included such that a receiving TEE can check 1926 whether the device state has changed since its last query. It 1927 helps enforce SD update order in the right sequence without 1928 accidentally overwriting an update that was done simultaneously. 1930 content - The "content" is a JSON encrypted message that includes 1931 actual input for the SD creation. The encryption key is TAMmk that 1932 is encrypted by the target TEE's public key. The entire message is 1933 signed by the TAM private key TAMpriv. A separate TAMmk isn't used 1934 in the latest specification because JSON encryption will use a 1935 content encryption key for exactly the same purpose. 1937 spid - A unique id assigned by the TAM for its SP. It should be 1938 unique within a TAM namespace. 1940 sdname - a name unique to the SP. TAM should ensure it is unique 1941 for each SP. 1943 spcert - The SP's TA signer certificate is included in the request. 1944 This certificate will be stored by the device TEE which uses it to 1945 check against TA installation. Only if a TA is signed by a 1946 matching spcert associated with an SD will the TA be installed into 1947 the SD. 1949 tamid - SD owner claim by TAM - an SD owned by a TAM will be 1950 associated with a trusted identifier defined as an attribute in the 1951 signer TAM certificate. TEE will be responsible to assign this ID 1952 to the SD. The TAM certificate attribute for this attribute tamid 1953 MUST be vetted by the TAM signer issuing CA. With this trusted 1954 identifier, the SD query at TEE can be fast upon TAM signer 1955 verification. 1957 did - The SHA256 hash of the binary-encoded device TEE certificate. 1958 The encryption key CEK will be encrypted the recipient TEE's public 1959 key. This hash value in the "did" property allows the recipient 1960 TEE to check whether it is the expected target to receive such a 1961 request. If this isn't given, an OTrP message for device 2 could 1962 be sent to device 1. It is optional for the TEE to check because 1963 the successful decryption of the request message with this device's 1964 TEE private key already proves it is the target. This explicit 1965 hash value makes the protocol not dependent on message encryption 1966 method in future. 1968 A CreateSDTBSRequest message is signed to generate a final 1969 CreateSDRequest message as follows. 1971 { 1972 "CreateSDRequest": { 1973 "payload": "", 1974 "protected": "", 1975 "header": "", 1976 "signature": "" 1977 } 1978 } 1980 The TAM signer certificate is included in the "header" property. 1982 9.2.1.2. Request Processing Requirements at a TEE 1984 Upon receiving a CreateSDRequest request message at a TEE, the TEE 1985 MUST do the following: 1987 1. Validate the JSON request message as follows 1989 * Validate JSON message signing. 1991 * Validate that the request TAM certificate is chained to a 1992 trusted CA that the TEE embeds as its trust anchor. 1994 * Compare dsihash with its current state to make sure nothing 1995 has changed since this request was sent. 1997 * Decrypt to get the plaintext of the content: (a) spid, (b) sd 1998 name, (c) did. 2000 * Check that an SPID is supplied. 2002 * spcert check: check it is a valid certificate (signature and 2003 format verification only). 2005 * Check "did" is the SHA256 hash of its TEEcert BER raw binary 2006 data. 2008 * Check whether the requested SD already exists for the SP. 2010 * Check that the tamid in the request matches the TAM 2011 certificate's TAM ID attribute. 2013 2. If the request was valid, create action 2015 * Create an SD for the SP with the given name. 2017 * Assign the tamid from the TAMCert to this SD. 2019 * Assign the SPID and SPCert to this SD. 2021 * Check whether a TEE SP AIK key pair already exists for the 2022 given SP ID. 2024 * Create TEE SP AIK key pair if it doesn't exist for the given 2025 SP ID. 2027 * Generate new DSI data if the request asks for updated DSI. 2029 3. Construct a CreateSDResponse message 2030 * Create raw content 2032 + Operation status 2034 + "did" or full signer certificate information, 2036 + TEE SP AIK public key if DSI isn't going to be included 2038 + Updated DSI data if requested 2040 * The response message is encrypted with the same JWE CEK of the 2041 request without recreating a new content encryption key. 2043 * The encrypted message is signed with TEEpriv. The signer 2044 information ("did" or TEEcert) is encrypted. 2046 4. Deliver the response message. (a) The OTrP Agent returns this to 2047 the Client Application; (b) The Client App passes this back to 2048 the TAM. 2050 5. TAM processing. (a) The TAM processes the response message; (b) 2051 the TAM can look up signer certificate from the device ID "did". 2053 If a request is illegitimate or signature doesn't pass, a "status" 2054 property in the response will indicate the error code and cause. 2056 9.2.1.3. CreateSDResponse Message 2058 The response message for a CreateSDRequest contains the following 2059 content. 2061 { 2062 "CreateSDTBSResponse": { 2063 "ver": "1.0", 2064 "status": "", 2065 "rid": "", 2066 "tid": "", 2067 "content": ENCRYPTED { 2068 "reason": "", // optional 2069 "did": "", 2070 "sdname": "", 2071 "teespaik": "", 2072 "dsi": "" 2074 } 2075 } 2076 } 2077 In the response message, the following fields MUST be supplied. 2079 did - The SHA256 hash of the device TEE certificate. This shows 2080 the device ID explicitly to the receiving TAM. 2082 teespaik - The newly generated SP AIK public key for the given SP. 2083 This is an optional value if the device has had another domain for 2084 the SP that has triggered TEE SP AIK key pair for this specific SP. 2086 There is a possible extreme error case where the TEE isn't reachable 2087 or the TEE final response generation itself fails. In this case, the 2088 TAM might still receive a response from the OTrP Agent if the OTrP 2089 Agent is able to detect such error from TEE. In this case, a general 2090 error response message should be returned by the OTrP Agent, assuming 2091 OTrP Agent even doesn't know any content and information about the 2092 request message. 2094 In other words, the TAM should expect to receive a TEE successfully 2095 signed JSON message, a general "status" message, or none when a 2096 client experiences a network error. 2098 { 2099 "CreateSDResponse": { 2100 "payload": "", 2101 "protected": { 2102 "" 2103 }, 2104 "signature": "" 2106 } 2107 } 2109 A response message type "status" will be returned when the TEE fails 2110 to respond. The OTrP Agent is responsible to create this message. 2112 { 2113 "status": { 2114 "result": "fail", 2115 "error-code": "ERR_AGENT_TEE_FAIL", 2116 "error-message": "TEE fails to respond" 2117 } 2118 } 2120 9.2.1.4. Error Conditions 2122 An error might occur if a request isn't valid or the TEE runs into 2123 some error. The list of possible errors are as follows. Refer to 2124 the Error Code List (Section 13.1) for detailed causes and actions. 2126 ERR_AGENT_TEE_BUSY 2128 ERR_AGENT_TEE_FAIL 2130 ERR_AGENT_TEE_UNKNOWN 2132 ERR_REQUEST_INVALID 2134 ERR_UNSUPPORTED_MSG_VERSION 2136 ERR_UNSUPPORTED_CRYPTO_ALG 2138 ERR_DEV_STATE_MISMATCH 2140 ERR_SD_ALREADY_EXIST 2142 ERR_SD_NOT_FOUND 2144 ERR_SPCERT_INVALID 2146 ERR_TEE_FAIL 2148 ERR_TAM_NOT_AUTHORIZED 2150 ERR_TAM_NOT_TRUSTED 2152 9.2.2. UpdateSD 2154 This TAM initiated command can update an SP's SD that it manages for 2155 any of the following needs: (a) Update an SP signer certificate; (b) 2156 Add an SP signer certificate when an SP uses multiple to sign TA 2157 binaries; (c) Update an SP ID. 2159 The TAM presents the proof of the SD ownership to the TEE, and 2160 includes related information in its signed message. The entire 2161 request is also encrypted for end-to-end confidentiality. 2163 9.2.2.1. UpdateSDRequest Message 2164 The UpdateSD request message has the following JSON format. 2166 { 2167 "UpdateSDTBSRequest": { 2168 "ver": "1.0", 2169 "rid": "", 2170 "tid": "", // this may be from prior message 2171 "tee": "", 2172 "nextdsi": true | false, 2173 "dsihash": "", 2174 "content": ENCRYPTED { // this piece of JSON will be encrypted 2175 "tamid": "", 2176 "spid": "", 2177 "sdname": "", 2178 "changes": { 2179 "newsdname": "", 2180 // Optional 2181 "newspid": "", 2182 // Optional 2183 "spcert": [""], 2184 // Optional 2185 "deloldspcert": [""], 2187 // Optional 2188 "renewteespaik": true | false 2189 } 2190 } 2191 } 2192 } 2194 In the message, 2196 rid - A unique value to identify this request 2198 tid - A unique value to identify this transaction. It can have the 2199 same value as the tid in the preceding GetDeviceStateRequest. 2201 tee - TEE ID returned from the previous GetDeviceStateResponse 2203 nextdsi - Indicates whether the up-to-date Device State Information 2204 (DSI) is expected to be returned in the response from the TEE to 2205 this request. 2207 dsihash - The BASE64-encoded SHA256 hash value of the DSI data 2208 returned in the prior TAM operation with this target TEE. This 2209 value is always included such that a receiving TEE can check 2210 whether the device state has changed since its last query. It 2211 helps enforce SD update order in the right sequence without 2212 accidentally overwriting an update that was done simultaneously. 2214 content - The "content" is a JSON encrypted message that includes 2215 actual input for the SD update. The standard JSON content 2216 encryption key (CEK) is used, and the CEK is encrypted by the 2217 target TEE's public key. 2219 tamid - SD owner claim by TAM - an SD owned by a TAM will be 2220 associated with a trusted identifier defined as an attribute in the 2221 signer TAM certificate. 2223 spid - the identifier of the SP whose SD will be updated. This 2224 value is still needed because the SD name is considered unique only 2225 within an SP. 2227 sdname - the name of the target SD to be updated. 2229 changes - its content consists of changes are to be updated in the 2230 given SD. 2232 newsdname - the new name of the target SD to be assigned if this 2233 value is present. 2235 newspid - the new SP ID of the target SD to be assigned if this 2236 value is present. 2238 spcert - a new TA signer certificate of this SP to be added to the 2239 SD if this is present. 2241 deloldspcert - an SP certificate assigned into the SD is to be 2242 deleted if this is present. The value is the SHA256 fingerprint of 2243 the old SP certificate. 2245 renewteespaik - the value should be true or false. If it is present 2246 and the value is true, the TEE MUST regenerate TEE SP AIK for this 2247 SD's owner SP. The newly generated TEE SP AIK for the SP must be 2248 returned in the response message of this request. If there is more 2249 than one SD for the SP, a new SPID for one of the domains will 2250 always trigger a new teespaik generation as if a new SP were 2251 introduced to the TEE. 2253 The UpdateSDTBSRequest message is signed to generate the final 2254 UpdateSDRequest message. 2256 { 2257 "UpdateSDRequest": { 2258 "payload": "", 2259 "protected": "", 2260 "header": "", 2261 "signature":"" 2262 } 2263 } 2265 TAM signer certificate is included in the "header" property. 2267 9.2.2.2. Request Processing Requirements at a TEE 2269 Upon receiving a request message UpdateSDRequest at a TEE, the TEE 2270 must validate a request: 2272 1. Validate the JSON request message 2274 * Validate JSON message signing 2276 * Validate that the request TAM certificate is chained to a 2277 trusted CA that the TEE embeds as its trust anchor.The TAM 2278 certificate status check is generally not needed anymore in 2279 this request. The prior request should have validated the TAM 2280 certificate's revocation status. 2282 * Compare dsihash with the TEE cached last response DSI data to 2283 this TAM. 2285 * Decrypt to get the plaintext of the content. 2287 * Check that the target SD name is supplied. 2289 * Check whether the requested SD exists. 2291 * Check that the TAM owns this TAM by verifying tamid in the SD 2292 matches TAM certificate's TAM ID attribute. 2294 * Now the TEE is ready to carry out update listed in the 2295 "content" message. 2297 2. If the request is valid, update action 2299 * If "newsdname" is given, replace the SD name for the SD to the 2300 new value 2302 * If "newspid" is given, replace the SP ID assigned to this SD 2303 with the given new value 2305 * If "spcert" is given, add this new SP certificate to the SD. 2307 * If "deloldspcert" is present in the content, check previously 2308 assigned SP certificates to this SD, and delete the one that 2309 matches the given certificate hash value. 2311 * If "renewteespaik" is given and has a value of 'true', 2312 generate a new TEE SP AIK key pair, and replace the old one 2313 with this. 2315 * Generate new DSI data if the request asks for updated DSI 2317 * Now the TEE is ready to construct the response message 2319 3. Construct UpdateSDResponse message 2321 * Create raw content 2323 + Operation status 2325 + "did" or full signer certificate information, 2327 + TEE SP AIK public key if DSI isn't going to be included 2329 + Updated DSI data if requested 2331 * The response message is encrypted with the same JWE CEK of the 2332 request without recreating a new content encryption key. 2334 * The encrypted message is signed with TEEpriv. The signer 2335 information ("did" or TEEcert) is encrypted. 2337 4. Deliver response message. (a) The OTrP Agent returns this to the 2338 app; (b) The app passes this back to the TAM. 2340 5. TAM processing. (a) The TAM processes the response message; (b) 2341 The TAM can look up the signer certificate from the device ID 2342 "did". 2344 If a request is illegitimate or the signature doesn't pass, a 2345 "status" property in the response will indicate the error code and 2346 cause. 2348 9.2.2.3. UpdateSDResponse Message 2350 The response message for a UpdateSDRequest contains the following 2351 content. 2353 { 2354 "UpdateSDTBSResponse": { 2355 "ver": "1.0", 2356 "status": "", 2357 "rid": "", 2358 "tid": "", 2359 "content": ENCRYPTED { 2360 "reason": "", // optional 2361 "did": "", 2362 "cert": "", // optional 2363 "teespaik": "", 2364 "teespaiktype": "", 2365 "dsi": "" 2367 } 2368 } 2369 } 2371 In the response message, the following fields MUST be supplied. 2373 did - The request should have known the signer certificate of this 2374 device from a prior request. This hash value of the device TEE 2375 certificate serves as a quick identifier only. A full device 2376 certificate isn't necessary. 2378 teespaik - the newly generated SP AIK public key for the given SP 2379 if the TEE SP AIK for the SP is asked to be renewed in the request. 2380 This is an optional value if "dsi" is included in the response, 2381 which will contain all up-to-date TEE SP AIK key pairs. 2383 Similar to the template for the creation of the encrypted and signed 2384 CreateSDResponse, the final UpdateSDResponse looks like the 2385 following. 2387 { 2388 "UpdateSDResponse": { 2389 "payload": "", 2390 "protected": { 2391 "" 2392 }, 2393 "signature": "" 2395 } 2396 } 2398 A response message type "status" will be returned when the TEE fails 2399 to respond. The OTrP Agent is responsible to create this message. 2401 { 2402 "status": { 2403 "result": "fail", 2404 "error-code": "ERR_AGENT_TEE_FAIL", 2405 "error-message": "" 2406 } 2407 } 2409 9.2.2.4. Error Conditions 2411 An error may occur if a request isn't valid or the TEE runs into some 2412 error. The list of possible errors are as follows. Refer to the 2413 Error Code List (Section 13.1) for detailed causes and actions. 2415 ERR_AGENT_TEE_BUSY 2417 ERR_AGENT_TEE_FAIL 2419 ERR_AGENT_TEE_UNKNOWN 2421 ERR_REQUEST_INVALID 2423 ERR_UNSUPPORTED_MSG_VERSION 2425 ERR_UNSUPPORTED_CRYPTO_ALG 2427 ERR_DEV_STATE_MISMATCH 2429 ERR_SD_NOT_FOUND 2431 ERR_SDNAME_ALREADY_USED 2433 ERR_SPCERT_INVALID 2434 ERR_TEE_FAIL 2436 ERR_TAM_NOT_AUTHORIZED 2438 ERR_TAM_NOT_TRUSTED 2440 9.2.3. DeleteSD 2442 A TAM sends a DeleteSDRequest message to a TEE to delete a specified 2443 SD that it owns. An SD can be deleted only if there is no TA 2444 associated with this SD in the device. The request message can 2445 contain a flag to instruct the TEE to delete all related TAs in an SD 2446 and then delete the SD. 2448 The target TEE will operate with the following logic. 2450 1. Look up the given SD specified in the request message 2452 2. Check that the TAM owns the SD 2454 3. Check that the device state hasn't changed since the last 2455 operation 2457 4. Check whether there are TAs in this SD 2459 5. If TA exists in an SD, check whether the request instructs 2460 whether the TA should be deleted. If the request instructs the 2461 TEE to delete TAs, delete all TAs in this SD. If the request 2462 doesn't instruct the TEE to delete TAs, return an error 2463 "ERR_SD_NOT_EMPTY". 2465 6. Delete the SD 2467 7. If this is the last SD of this SP, delete the TEE SP AIK key. 2469 9.2.3.1. DeleteSDRequest Message 2470 The request message for DeleteSD has the following JSON format. 2472 { 2473 "DeleteSDTBSRequest": { 2474 "ver": "1.0", 2475 "rid": "", 2476 "tid": "", // this may be from prior message 2477 "tee": "", 2478 "nextdsi": true | false, 2479 "dsihash": "", 2480 "content": ENCRYPTED { // this piece of JSON will be encrypted 2481 "tamid": "", 2482 "sdname": "", 2483 "deleteta": true | false 2484 } 2485 } 2486 } 2488 In the message, 2490 rid - A unique value to identify this request 2492 tid - A unique value to identify this transaction. It can have the 2493 same value for the tid in the preceding GetDeviceStateRequest. 2495 tee - TEE ID returned from the previous response 2496 GetDeviceStateResponse 2498 nextdsi - Indicates whether the up-to-date Device State Information 2499 (DSI) is to be returned in the response to this request. 2501 dsihash - The BASE64-encoded SHA256 hash value of the DSI data 2502 returned in the prior TAM operation with this target TEE. This 2503 value is always included such that a receiving TEE can check 2504 whether the device state has changed since its last query. It 2505 helps enforce SD update order in the right sequence without 2506 accidentally overwriting an update that was done simultaneously. 2508 content - The "content" is a JSON encrypted message that includes 2509 actual input for the SD update. The standard JSON content 2510 encryption key (CEK) is used, and the CEK is encrypted by the 2511 target TEE's public key. 2513 tamid - SD owner claim by TAM - an SD owned by a TAM will be 2514 associated with a trusted identifier defined as an attribute in the 2515 signer TAM certificate. 2517 sdname - the name of the target SD to be updated. 2519 deleteta - the value should be boolean 'true' or 'false'. If it is 2520 present and the value is 'true', the TEE should delete all TAs 2521 associated with the SD in the device. 2523 According to the OTrP message template, the full request 2524 DeleteSDRequest is a signed message over the DeleteSDTBSRequest as 2525 follows. 2527 { 2528 "DeleteSDRequest": { 2529 "payload": "", 2530 "protected": "", 2531 "header": "", 2532 "signature": "" 2533 } 2534 } 2536 TAM signer certificate is included in the "header" property. 2538 9.2.3.2. Request Processing Requirements at a TEE 2540 Upon receiving a request message DeleteSDRequest at a TEE, the TEE 2541 must validate a request: 2543 1. Validate the JSON request message 2545 * Validate JSON message signing 2547 * Validate that the request TAM certificate is chained to a 2548 trusted CA that the TEE embeds as its trust anchor. The TAM 2549 certificate status check is generally not needed anymore in 2550 this request. The prior request should have validated the TAM 2551 certificate's revocation status. 2553 * Compare dsihash with the TEE cached last response DSI data to 2554 this TAM 2556 * Decrypt to get the plaintext of the content 2558 * Check that the target SD name is supplied 2560 * Check whether the requested SD exists 2562 * Check that the TAM owns this TAM by verifying that the tamid 2563 in the SD matches the TAM certificate's TAM ID attribute 2565 * Now the TEE is ready to carry out the update listed in the 2566 "content" message 2568 2. If the request is valid, deletion action 2570 * Check TA existence in this SD 2572 * If "deleteta" is "true", delete all TAs in this SD. If the 2573 value of "deleteta" is false and some TA exists, return an 2574 error "ERR_SD_NOT_EMPTY" 2576 * Delete the SD 2578 * Delete the TEE SP AIK key pair if this SD is the last one for 2579 the SP 2581 * Now the TEE is ready to construct the response message 2583 3. Construct a DeleteSDResponse message 2585 * Create response content 2587 + Operation status 2589 + "did" or full signer certificate information, 2591 + Updated DSI data if requested 2593 * The response message is encrypted with the same JWE CEK of the 2594 request without recreating a new content encryption key. 2596 * The encrypted message is signed with TEEpriv. The signer 2597 information ("did" or TEEcert) is encrypted. 2599 4. Deliver response message. (a) The OTrP Agent returns this to the 2600 app; (b) The app passes this back to the TAM 2602 5. TAM processing. (a) The TAM processes the response message; (b) 2603 The TAM can look up signer certificate from the device ID "did". 2605 If a request is illegitimate or the signature doesn't pass, a 2606 "status" property in the response will indicate the error code and 2607 cause. 2609 9.2.3.3. DeleteSDResponse Message 2611 The response message for a DeleteSDRequest contains the following 2612 content. 2614 { 2615 "DeleteSDTBSResponse": { 2616 "ver": "1.0", 2617 "status": "", 2618 "rid": "", 2619 "tid": "", 2620 "content": ENCRYPTED { 2621 "reason": "", // optional 2622 "did": "", 2623 "dsi": "" 2625 } 2626 } 2627 } 2629 In the response message, the following fields MUST be supplied. 2631 did - The request should have known the signer certificate of this 2632 device from a prior request. This hash value of the device TEE 2633 certificate serves as a quick identifier only. A full device 2634 certificate isn't necessary. 2636 The final DeleteSDResponse looks like the following. 2638 { 2639 "DeleteSDResponse": { 2640 "payload": "", 2641 "protected": { 2642 "" 2643 }, 2644 "signature": "" 2646 } 2647 } 2649 A response message type "status" will be returned when the TEE fails 2650 to respond. The OTrP Agent is responsible to create this message. 2652 { 2653 "status": { 2654 "result": "fail", 2655 "error-code": "ERR_AGENT_TEE_FAIL", 2656 "error-message": "TEE fails to respond" 2657 } 2658 } 2660 9.2.3.4. Error Conditions 2662 An error may occur if a request isn't valid or the TEE runs into some 2663 error. The list of possible errors is as follows. Refer to the 2664 Error Code List (Section 13.1) for detailed causes and actions. 2666 ERR_AGENT_TEE_BUSY 2668 ERR_AGENT_TEE_FAIL 2670 ERR_AGENT_TEE_UNKNOWN 2672 ERR_REQUEST_INVALID 2674 ERR_UNSUPPORTED_MSG_VERSION 2676 ERR_UNSUPPORTED_CRYPTO_ALG 2678 ERR_DEV_STATE_MISMATCH 2680 ERR_SD_NOT_EMPTY 2682 ERR_SD_NOT_FOUND 2684 ERR_TEE_FAIL 2686 ERR_TAM_NOT_AUTHORIZED 2688 ERR_TAM_NOT_TRUSTED 2690 9.3. Trusted Application Management 2692 This protocol doesn't introduce a TA container concept. All TA 2693 authorization and management will be up to the TEE implementation. 2695 The following three TA management commands are supported. 2697 o InstallTA - provision a TA by TAM 2699 o UpdateTA - update a TA by TAM 2701 o DeleteTA - remove TA registration information with an SD, remove 2702 the TA binary and all TA-related data in a TEE 2704 9.3.1. InstallTA 2706 TA binary data and related personalization data if there is any can 2707 be from two sources: 2709 1. A TAM supplies the signed and encrypted TA binary 2711 2. A Client Application supplies the TA binary 2713 This specification primarily considers the first case where a TAM 2714 supplies a TA binary. This is to ensure that a TEE can properly 2715 validate whether a TA is trustworthy. Further, TA personalization 2716 data will be encrypted by the TEE device's SP public key for end-to- 2717 end protection. A Client Application bundled TA case will be 2718 addressed separately later. 2720 A TAM sends the following information in a InstallTARequest message 2721 to a target TEE: 2723 o The target SD information: SP ID and SD name 2725 o Encrypted TA binary data. TA data is encrypted with the TEE SP 2726 AIK. 2728 o TA metadata. It is optional to include the SP signer certificate 2729 for the SD to add if the SP has changed signer since the SD was 2730 created. 2732 The TEE processes the command given by the TAM to install a TA into 2733 an SP's SD. It does the following: 2735 o Validation 2737 * The TEE validates the TAM message authenticity 2739 * Decrypt to get request content 2741 * Look up the SD with the SD name 2743 * Checks that the TAM owns the SD 2745 * Checks that the DSI hash matches which shows that the device 2746 state hasn't changed 2748 o If the request is valid, continue to do the TA validation 2750 * Decrypt to get the TA binary data and any personalization data 2751 with the "TEE SP AIK private key" 2753 * Check that SP ID is the one that is registered with the SP SD 2755 * Check that the TA signer is either a newly given SP certificate 2756 or the one that is already trusted by the SD from the previous 2757 TA installation. The TA signing method is specific to a TEE. 2758 This specification doesn't define how a TA should be signed; a 2759 TAM should support TEE specific TA signing when it supports 2760 that TEE. 2762 * If a TA signer is given in the request, add this signer into 2763 the SD. 2765 o If the above validation passed, continue to do TA installation 2767 * The TEE re-encrypts the TA binary and its personalization data 2768 with its own method. 2770 * The TEE enrolls and stores the TA in a secure storage. 2772 o Construct a response message. This involves signing encrypted 2773 status information for the requesting TAM. 2775 9.3.1.1. InstallTARequest Message 2776 The request message for InstallTA has the following JSON format. 2778 { 2779 "InstallTATBSRequest": { 2780 "ver": "1.0", 2781 "rid": "", 2782 "tid": "", 2783 "tee": "", 2784 "nextdsi": true | false, 2785 "dsihash": "", 2786 "content": ENCRYPTED { 2787 "tamid": "", 2788 "spid": "", 2789 "sdname": "", 2790 "spcert": "", // optional 2791 "taid": "" 2792 }, 2793 "encrypted_ta": { 2794 "key": "", 2796 "iv": "", 2797 "alg": "", 2799 "cipherpdata": "" 2801 } 2802 } 2803 } 2805 In the message, 2807 rid - A unique value to identify this request 2809 tid - A unique value to identify this transaction. It can have the 2810 same value for the tid in the preceding GetDeviceStateRequest. 2812 tee - TEE ID returned from the previous GetDeviceStateResponse 2814 nextdsi - Indicates whether the up-to-date Device State Information 2815 (DSI) is to be returned in the response to this request. 2817 dsihash - The BASE64-encoded SHA256 hash value of the DSI data 2818 returned in the prior TAM operation with this target TEE. This 2819 value is always included such that a receiving TEE can check 2820 whether the device state has changed since its last query. It 2821 helps enforce SD update order in the right sequence without 2822 accidentally overwriting an update that was done simultaneously. 2824 content - The "content" is a JSON encrypted message that includes 2825 actual input for the SD update. The standard JSON content 2826 encryption key (CEK) is used, and the CEK is encrypted by the 2827 target TEE's public key. 2829 tamid - SD owner claim by TAM - An SD owned by a TAM will be 2830 associated with a trusted identifier defined as an attribute in the 2831 signer TAM certificate. 2833 spid - SP identifier of the TA owner SP 2835 sdname - the name of the target SD where the TA is to be installed 2837 spcert - an optional field to specify the SP certificate that signed 2838 the TA. This is sent if the SP has a new certificate that hasn't 2839 been previously registered with the target SD where the TA should 2840 be installed. 2842 taid - the identifier of the TA application to be installed 2844 encrypted_ta - the message portion contains encrypted TA binary data 2845 and personalization data. The TA data encryption key is placed in 2846 "key", which is encrypted by the recipient's public key, using JWE 2847 enveloped structure. The TA data encryption uses symmetric key 2848 based encryption such as AESCBC. 2850 According to the OTrP message template, the full request 2851 InstallTARequest is a signed message over the InstallTATBSRequest as 2852 follows. 2854 { 2855 "InstallTARequest": { 2856 "payload": "", 2857 "protected": "", 2858 "header": "", 2859 "signature": "" 2860 } 2861 } 2863 9.3.1.2. InstallTAResponse Message 2865 The response message for a InstallTARequest contains the following 2866 content. 2868 { 2869 "InstallTATBSResponse": { 2870 "ver": "1.0", 2871 "status": "", 2872 "rid": "", 2873 "tid": "", 2874 "content": ENCRYPTED { 2875 "reason":"", // optional 2876 "did": "", 2877 "dsi": "" 2879 } 2880 } 2881 } 2883 In the response message, the following fields MUST be supplied. 2885 did - the SHA256 hash of the device TEE certificate. This shows 2886 the device ID explicitly to the receiving TAM. 2888 The final message InstallTAResponse looks like the following. 2890 { 2891 "InstallTAResponse": { 2892 "payload":"", 2893 "protected": { 2894 "" 2895 }, 2896 "signature": "" 2898 } 2899 } 2901 A response message type "status" will be returned when the TEE fails 2902 to respond. The OTrP Agent is responsible to create this message. 2904 { 2905 "status": { 2906 "result": "fail", 2907 "error-code": "ERR_AGENT_TEE_FAIL", 2908 "error-message": "TEE fails to respond" 2909 } 2910 } 2912 9.3.1.3. Error Conditions 2914 An error may occur if a request isn't valid or the TEE runs into some 2915 error. The list of possible errors are as follows. Refer to the 2916 Error Code List (Section 13.1) for detailed causes and actions. 2918 ERR_AGENT_TEE_BUSY 2920 ERR_AGENT_TEE_FAIL 2922 ERR_AGENT_TEE_UNKNOWN 2924 ERR_REQUEST_INVALID 2926 ERR_UNSUPPORTED_MSG_VERSION 2928 ERR_UNSUPPORTED_CRYPTO_ALG 2930 ERR_DEV_STATE_MISMATCH 2932 ERR_SD_NOT_FOUND 2934 ERR_TA_INVALID 2936 ERR_TA_ALREADY_INSTALLED 2938 ERR_TEE_FAIL 2940 ERR_TEE_RESOURCE_FULL 2942 ERR_TAM_NOT_AUTHORIZED 2944 ERR_TAM_NOT_TRUSTED 2946 9.3.2. UpdateTA 2948 This TAM-initiated command can update a TA and its data in an SP's SD 2949 that it manages for the following purposes. 2951 1. Update TA binary 2953 2. Update TA's personalization data 2955 The TAM presents the proof of the SD ownership to a TEE, and includes 2956 related information in its signed message. The entire request is 2957 also encrypted for end-to-end confidentiality. 2959 The TEE processes the command from the TAM to update the TA of an SP 2960 SD. It does the following: 2962 o Validation 2964 * The TEE validates the TAM message authenticity 2966 * Decrypt to get request content 2968 * Look up the SD with the SD name 2970 * Checks that the TAM owns the SD 2972 * Checks DSI hash matches that the device state hasn't changed 2974 o TA validation 2976 * Both TA binary and personalization data are optional, but at 2977 least one of them shall be present in the message 2979 * Decrypt to get the TA binary and any personalization data with 2980 the "TEE SP AIK private key" 2982 * Check that SP ID is the one that is registered with the SP SD 2984 * Check that the TA signer is either a newly given SP certificate 2985 or the one in SD. 2987 * If a TA signer is given in the request, add this signer into 2988 the SD. 2990 o If the above validation passes, continue to do TA update 2992 * The TEE re-encrypts the TA binary and its personalization data 2993 with its own method 2995 * The TEE replaces the existing TA binary and its personalization 2996 data with the new binary and data. 2998 o Construct a response message. This involves signing a encrypted 2999 status information for the requesting TAM. 3001 9.3.2.1. UpdateTARequest Message 3002 The request message for UpdateTA has the following JSON format. 3004 { 3005 "UpdateTATBSRequest": { 3006 "ver": "1.0", 3007 "rid": "", 3008 "tid": "", 3009 "tee": "", 3010 "nextdsi": true | false, 3011 "dsihash": "", 3012 "content": ENCRYPTED { 3013 "tamid": "", 3014 "spid": "", 3015 "sdname": "", 3016 "spcert": "", // optional 3017 "taid": "" 3018 }, 3019 "encrypted_ta": { 3020 "key": "", 3022 "iv": "", 3023 "alg": "", 3026 "ciphernewpdata": "" 3028 // optional 3029 } 3030 } 3031 } 3033 In the message, 3035 rid - A unique value to identify this request 3037 tid - A unique value to identify this transaction. It can have the 3038 same value for the tid in the preceding GetDeviceStateRequest. 3040 tee - TEE ID returned from the previous GetDeviceStateResponse 3042 nextdsi - Indicates whether the up-to-date Device State Information 3043 (DSI) is to be returned in the response to this request. 3045 dsihash - The BASE64-encoded SHA256 hash value of the DSI data 3046 returned in the prior TAM operation with this target TEE. This 3047 value is always included such that a receiving TEE can check 3048 whether the device state has changed since its last query. It 3049 helps enforce SD update order in the right sequence without 3050 accidentally overwriting an update that was done simultaneously. 3052 content - The "content" is a JSON encrypted message that includes 3053 actual input for the SD update. The standard JSON content 3054 encryption key (CEK) is used, and the CEK is encrypted by the 3055 target TEE's public key. 3057 tamid - SD owner claim by TAM - an SD owned by a TAM will be 3058 associated with a trusted identifier defined as an attribute in the 3059 signer TAM certificate. 3061 spid - SP identifier of the TA owner SP 3063 spcert - an optional field to specify the SP certificate that signed 3064 the TA. This is sent if the SP has a new certificate that hasn't 3065 been previously registered with the target SD where the TA is to be 3066 installed. 3068 sdname - the name of the target SD where the TA should be updated 3070 taid - an identifier for the TA application to be updated 3072 encrypted_ta - the message portion contains newly encrypted TA 3073 binary data and personalization data. 3075 According to the OTrP message template, the full request 3076 UpdateTARequest is a signed message over the UpdateTATBSRequest as 3077 follows. 3079 { 3080 "UpdateTARequest": { 3081 "payload": "", 3082 "protected": "", 3083 "header": "", 3084 "signature": "" 3085 } 3086 } 3088 9.3.2.2. UpdateTAResponse Message 3090 The response message for a UpdateTARequest contains the following 3091 content. 3093 { 3094 "UpdateTATBSResponse": { 3095 "ver": "1.0", 3096 "status": "", 3097 "rid": "", 3098 "tid": "", 3099 "content": ENCRYPTED { 3100 "reason": "", // optional 3101 "did": "", 3102 "dsi": "" 3104 } 3105 } 3106 } 3108 In the response message, the following fields MUST be supplied. 3110 did - the SHA256 hash of the device TEE certificate. This shows 3111 the device ID explicitly to the receiving TAM. 3113 The final message UpdateTAResponse looks like the following. 3115 { 3116 "UpdateTAResponse": { 3117 "payload":"", 3118 "protected": { 3119 "" 3120 }, 3121 "signature": "" 3123 } 3124 } 3126 A response message type "status" will be returned when the TEE fails 3127 to respond. The OTrP Agent is responsible to create this message. 3129 { 3130 "status": { 3131 "result": "fail", 3132 "error-code": "ERR_AGENT_TEE_FAIL", 3133 "error-message": "TEE fails to respond" 3134 } 3135 } 3137 9.3.2.3. Error Conditions 3139 An error may occur if a request isn't valid or the TEE runs into some 3140 error. The list of possible errors are as follows. Refer to the 3141 Error Code List (Section 13.1) for detailed causes and actions. 3143 ERR_AGENT_TEE_BUSY 3145 ERR_AGENT_TEE_FAIL 3147 ERR_AGENT_TEE_UNKNOWN 3149 ERR_REQUEST_INVALID 3151 ERR_UNSUPPORTED_MSG_VERSION 3153 ERR_UNSUPPORTED_CRYPTO_ALG 3155 ERR_DEV_STATE_MISMATCH 3157 ERR_SD_NOT_FOUND 3159 ERR_TA_INVALID 3161 ERR_TA_NOT_FOUND 3163 ERR_TEE_FAIL 3165 ERR_TAM_NOT_AUTHORIZED 3167 ERR_TAM_NOT_TRUSTED 3169 9.3.3. DeleteTA 3171 This operation defines OTrP messages that allow a TAM to instruct a 3172 TEE to delete a TA for an SP in a given SD. A TEE will delete a TA 3173 from an SD and also TA data in the TEE. A Client Application cannot 3174 directly access TEE or OTrP Agent to delete a TA. 3176 9.3.3.1. DeleteTARequest Message 3177 The request message for DeleteTA has the following JSON format. 3179 { 3180 "DeleteTATBSRequest": { 3181 "ver": "1.0", 3182 "rid": "", 3183 "tid": "", 3184 "tee": "", 3185 "nextdsi": true | false, 3186 "dsihash": "", 3187 "content": ENCRYPTED { 3188 "tamid": "", 3189 "sdname": "", 3190 "taid": "" 3192 } 3193 } 3194 } 3196 In the message, 3198 rid - A unique value to identify this request 3200 tid - A unique value to identify this transaction. It can have the 3201 same value for the tid in the preceding GetDeviceStateRequest. 3203 tee - The TEE ID returned from the previous GetDeviceStateResponse 3205 nextdsi - Indicates whether the up-to-date Device State Information 3206 (DSI) is to be returned in the response to this request. 3208 dsihash - The BASE64-encoded SHA256 hash value of the DSI data 3209 returned in the prior TAM operation with this target TEE. This 3210 value is always included such that a receiving TEE can check 3211 whether the device state has changed since its last query. It 3212 helps enforce SD update order in the right sequence without 3213 accidentally overwriting an update that was done simultaneously. 3215 content - The "content" is a JSON encrypted message that includes 3216 actual input for the SD update. The standard JSON content 3217 encryption key (CEK) is used, and the CEK is encrypted by the 3218 target TEE's public key. 3220 tamid - SD owner claim by TAM - an SD owned by a TAM will be 3221 associated with a trusted identifier defined as an attribute in the 3222 signer TAM certificate. 3224 sdname - the name of the target SD where the TA is installed 3225 taid - an identifier for the TA application to be deleted 3227 According to the OTrP message template, the full request 3228 DeleteTARequest is a signed message over the DeleteTATBSRequest as 3229 follows. 3231 { 3232 "DeleteTARequest": { 3233 "payload": "", 3234 "protected": "", 3235 "header": "", 3236 "signature": "" 3238 } 3239 } 3241 9.3.3.2. Request Processing Requirements at a TEE 3243 A TEE processes a command from a TAM to delete a TA of an SP SD. It 3244 does the following: 3246 1. Validate the JSON request message 3248 * The TEE validates TAM message authenticity 3250 * Decrypt to get request content 3252 * Look up the SD and the TA with the given SD name and TA ID 3254 * Checks that the TAM owns the SD, and TA is installed in the SD 3256 * Checks that the DSI hash matches and the the device state 3257 hasn't changed 3259 2. Deletion action 3261 * If all the above validation points pass, the TEE deletes the 3262 TA from the SD 3264 * The TEE SHOULD also delete all personalization data for the TA 3266 3. Construct DeleteTAResponse message. 3268 If a request is illegitimate or the signature doesn't pass, a 3269 "status" property in the response will indicate the error code and 3270 cause. 3272 9.3.3.3. DeleteTAResponse Message 3274 The response message for a DeleteTARequest contains the following 3275 content. 3277 { 3278 "DeleteTATBSResponse": { 3279 "ver": "1.0", 3280 "status": "", 3281 "rid": "", 3282 "tid": "", 3283 "content": ENCRYPTED { 3284 "reason": "", // optional 3285 "did": "", 3286 "dsi": "" 3288 } 3289 } 3290 } 3292 In the response message, the following fields MUST be supplied. 3294 did - the SHA256 hash of the device TEE certificate. This shows 3295 the device ID explicitly to the receiving TAM. 3297 The final message DeleteTAResponse looks like the following. 3299 { 3300 "DeleteTAResponse": { 3301 "payload": "", 3302 "protected": { 3303 "" 3304 }, 3305 "signature": "" 3307 } 3308 } 3310 A response message type "status" will be returned when the TEE fails 3311 to respond. The OTrP Agent is responsible to create this message. 3313 { 3314 "status": { 3315 "result": "fail", 3316 "error-code": "ERR_AGENT_TEE_FAIL", 3317 "error-message": "TEE fails to respond" 3318 } 3319 } 3321 9.3.3.4. Error Conditions 3323 An error may occur if a request isn't valid or the TEE runs into some 3324 error. The list of possible errors are as follows. Refer to the 3325 Error Code List (Section 13.1) for detailed causes and actions. 3327 ERR_AGENT_TEE_BUSY 3329 ERR_AGENT_TEE_FAIL 3331 ERR_AGENT_TEE_UNKNOWN 3333 ERR_REQUEST_INVALID 3335 ERR_UNSUPPORTED_MSG_VERSION 3337 ERR_UNSUPPORTED_CRYPTO_ALG 3339 ERR_DEV_STATE_MISMATCH 3341 ERR_SD_NOT_FOUND 3343 ERR_TA_NOT_FOUND 3345 ERR_TEE_FAIL 3347 ERR_TAM_NOT_AUTHORIZED 3349 ERR_TAM_NOT_TRUSTED 3351 10. Response Messages a TAM May Expect 3353 A TAM expects some feedback from a remote device when a request 3354 message is delivered to a device. The following three types of 3355 responses SHOULD be supplied. 3357 Type 1: Expect a valid TEE-generated response message 3359 A valid TEE signed response may contain errors detected by a TEE, 3360 e.g. a TAM is trusted but some TAM-supplied data is missing, for 3361 example, SP ID doesn't exist. TEE MUST be able to sign and 3362 encrypt. 3364 If a TEE isn't able to sign a response, the TEE returns an error 3365 to the OTrP Agent without giving any other internal information. 3366 The OTrP Agent will be generating the response. 3368 Type 2: The OTrP Agent generated error message when TEE fails. 3369 OTrP Agent errors will be defined in this document. 3371 A Type 2 message has the following format. 3373 { 3374 "OTrPAgentError": { 3375 "ver": "1.0", 3376 "rid": "", 3377 "tid": "", 3378 "errcode": "ERR_AGENT_TEE_UNKNOWN | ERR_AGENT_TEE_BUSY" 3379 } 3380 } 3382 Type 3: OTrP Agent itself isn't reachable or fails. A Client 3383 Application is responsible to handle error and respond the TAM in 3384 its own way. This is out of scope for this specification. 3386 11. Basic Protocol Profile 3388 This section describes a baseline for interoperability among the 3389 protocol entities, mainly, the TAM and TEE. 3391 A TEE MUST support RSA algorithms. It is optional to support ECC 3392 algorithms. A TAM SHOULD use a RSA certificate for TAM message 3393 signing. It may use an ECC certificate if it detects that the TEE 3394 supports ECC according to the field "supportedsigalgs" in a TEE 3395 response. 3397 A TAM MUST support both RSA 2048-bit algorithm and ECC P-256 3398 algorithms. With this, a TEE and TFW certificate can be either RSA 3399 or ECC type. 3401 JSON signing algorithms 3403 o RSA PKCS#1 with SHA256 signing : "RS256" 3405 o ECDSA with SHA256 signing : "ES256" 3407 JSON asymmetric encryption algorithms (describes key-exchange or key- 3408 agreement algorithm for sharing symmetric key with TEE): 3410 o RSA PKCS#1 : "RSA1_5" 3412 o ECDH using TEE ECC P-256 key and ephemeral ECC key generated by 3413 TAM : "ECDH-ES+A128W" 3415 JSON symmetric encryption algorithms (describes symmetric algorithm 3416 for encrypting body of data, using symmetric key transferred to TEE 3417 using asymmetric encryption): 3419 o Authenticated encryption AES 128 CBC with SHA256 : 3420 {"enc":"A128CBC-HS256"} 3422 12. Attestation Implementation Consideration 3424 It is important to know that the state of a device is appropriate 3425 before trusting that a device is what it says it is. The attestation 3426 scheme for OTrP must also be able to cope with different TEEs, 3427 including those that are OTrP compliant and those that use another 3428 mechanism. In the initial version, only one active TEE is assumed. 3430 It is out of scope how the TAM and the device implement the trust 3431 hierarchy verification. However, it is helpful to understand what 3432 each system provider should do in order to properly implement an OTrP 3433 trust hierarchy. 3435 In this section, we provide some implementation reference 3436 consideration. 3438 12.1. OTrP Secure Boot Module 3440 12.1.1. Attestation signer 3442 It is proposed that attestation for OTrP is based on the SBM secure 3443 boot layer, and that further attestation is not performed within the 3444 TEE itself during Security Domain operations. The rationale is that 3445 the device boot process will be defined to start with a secure boot 3446 approach that, using eFuse, only releases attestation signing 3447 capabilities into the SBM once a secure boot has been established. 3448 In this way the release of the attestation signer can be considered 3449 the first "platform configuration metric", using Trust Computing 3450 Group (TCG) terminology. 3452 12.1.2. SBM Initial Requirements 3454 R1 The SBM must be possible to load securely into the secure boot 3455 flow 3457 R2 The SBM must allow a public / private key pair to be generated 3458 during device manufacture 3460 R3 The public key and certificate must be possible to store securely 3462 R4 The private key must be possible to store encrypted at rest 3464 R5 The private key must only be visible to the SBM when it is 3465 decrypted 3467 R6 The SBM must be able to read a list of root and intermediate 3468 certificates that it can use to check certificate chains with. 3469 The list must be stored such that it cannot be tampered with 3471 R7 Need to allow a TEE to access its unique TEE specific private key 3473 12.2. TEE Loading 3475 During boot, the SBM is required to start all of the root TEEs. 3476 Before loading them, the SBM must first determine whether the code 3477 sign signature of the TEE is valid. If TEE integrity is confirmed, 3478 the TEE may be started. The SBM must then be able to receive the 3479 identity certificate from the TEE (if that TEE is OTrP compliant). 3480 The identity certificate and keys will need to be baked into the TEE 3481 image, and therefore also covered by the code signer hash during the 3482 manufacturing process. The private key for the identity certificate 3483 must be securely protected. The private key for a TEE identity must 3484 never be released no matter how the public key and certificate are 3485 released to the SBM. 3487 Once the SBM has successfully booted a TEE and retrieved the identity 3488 certificate, the SBM will commit this to the platform configuration 3489 register (PCR) set, for later use during attestation. At minimum, 3490 the following data must be committed to the PCR for each TEE: 3492 1. Public key and certificate for the TEE 3494 2. TEE identifier that can be used later by a TAM to identify this 3495 TEE 3497 12.3. Attestation Hierarchy 3499 The attestation hierarchy and seed required for TAM protocol 3500 operation must be built into the device at manufacture. Additional 3501 TEEs can be added post-manufacture using the scheme proposed, but it 3502 is outside of the current scope of this document to detail that. 3504 It should be noted that the attestation scheme described is based on 3505 signatures. The only encryption that takes place is with eFuse to 3506 release the SBM signing key and later during the protocol lifecycle 3507 management interchange with the TAM. 3509 12.3.1. Attestation Hierarchy Establishment: Manufacture 3511 During manufacture the following steps are required: 3513 1. A device-specific TFW key pair and certificate are burnt into the 3514 device, encrypted by eFuse. This key pair will be used for 3515 signing operations performed by the SBM. 3517 2. TEE images are loaded and include a TEE instance-specific key 3518 pair and certificate. The key pair and certificate are included 3519 in the image and covered by the code signing hash. 3521 3. The process for TEE images is repeated for any subordinate TEEs, 3522 which are additional TEEs after the root TEE that some devices 3523 have. 3525 12.3.2. Attestation Hierarchy Establishment: Device Boot 3527 During device boot the following steps are required: 3529 1. Secure boot releases the TFW private key by decrypting it with 3530 eFuse 3532 2. The SBM verifies the code-signing signature of the active TEE and 3533 places its TEE public key into a signing buffer, along with its 3534 identifier for later access. For a non-OTrP TEE, the SBM leaves 3535 the TEE public key field blank. 3537 3. The SBM signs the signing buffer with the TFW private key. 3539 4. Each active TEE performs the same operation as the SBM, building 3540 up their own signed buffer containing subordinate TEE 3541 information. 3543 12.3.3. Attestation Hierarchy Establishment: TAM 3545 Before a TAM can begin operation in the marketplace to support 3546 devices of a given TEE, it must obtain a TAM certificate from a CA 3547 that is registered in the trust store of devices with that TEE. In 3548 this way, the TEE can check the intermediate and root CA and verify 3549 that it trusts this TAM to perform operations on the TEE. 3551 13. IANA Considerations 3553 The error code listed in the next section will be registered. 3555 13.1. Error Code List 3557 This section lists error codes that could be reported by a TA or TEE 3558 in a device in responding to a TAM request, and a separate list that 3559 OTrP Agent may return when the TEE fails to respond. 3561 13.1.1. TEE Signed Error Code List 3563 ERR_DEV_STATE_MISMATCH - A TEE will return this error code if the 3564 DSI hash value from TAM doesn't match the has value of the device's 3565 current DSI. 3567 ERR_SD_ALREADY_EXISTS - This error will occur if an SD to be created 3568 already exists in the TEE. 3570 ERR_SD_NOT_EMPTY - This is reported if a target SD isn't empty. 3572 ERR_SDNAME_ALREADY_USED A TEE will return this error code if the new 3573 SD name already exists in the TEE. 3575 ERR_REQUEST_INVALID - This error will occur if the TEE meets any of 3576 the following conditions with a request message: (1) The request 3577 from a TAM has an invalid message structure; mandatory information 3578 is absent in the message. undefined member or structure is 3579 included. (2) TEE fails to verify signature of the message or 3580 fails to decrypt its contents. 3582 ERR_SPCERT_INVALID - If a new SP certificate for the SD to be 3583 updated is not valid, then the TEE will return this error code. 3585 ERR_TA_ALREADY_INSTALLED - While installing a TA, a TEE will return 3586 this error if the TA has already been installed in the SD. 3588 ERR_TA_INVALID - This error will occur when a TEE meets any of 3589 following conditions while checking validity of TA: (1) The TA 3590 binary has a format that the TEE can't recognize. (2) The TEE fails 3591 to decrypt the encoding of the TA binary and personalization data. 3592 (3) If an SP isn't registered with the SP SD where the TA will be 3593 installed. 3595 ERR_TA_NOT_FOUND - This error will occur when the target TA doesn't 3596 exist in the SD. 3598 ERR_TEE_FAIL - If the TEE fails to process a request because of an 3599 internal error, it will return this error code. 3601 ERR_TEE_RESOURCE_FULL - This error is reported when a device 3602 resource isn't available anymore such as storage space is full. 3604 ERR_TFW_NOT_TRUSTED - A TEE is responsible for determining that the 3605 underlying device firmware is trustworthy. If the TEE determines 3606 the TFW is not trustworthy, then this error will occur. 3608 ERR_TAM_NOT_TRUSTED - Before processing a request, a TEE needs to 3609 make sure whether the sender TAM is trustworthy by checking the 3610 validity of the TAM certificate, etc. If the TEE finds that the 3611 TAM is not trustworthy, then it will return this error code. 3613 ERR_UNSUPPORTED_CRYPTO_ALG - This error will occur if a TEE receives 3614 a request message encoded with cryptographic algorithms that the 3615 TEE doesn't support. 3617 ERR_UNSUPPORTED_MSG_VERSION - This error will occur if a TEE 3618 receives a message version that the TEE can't deal with. 3620 13.1.2. OTrP Agent Error Code List 3622 ERR_AGENT_TEE_UNKNOWN - This error will occur if the receiver TEE is 3623 not supposed to receive the request. That will be determined by 3624 checking the TEE name or device id in the request message. 3626 ERR_AGENT_TEE_BUSY - The device TEE is busy. The request can be 3627 generally sent again to retry. 3629 ERR_AGENT_TEE_FAIL - The TEE fails to respond to a TAM request. The 3630 OTrP Agent will construct an error message in responding to the 3631 TAM's request. 3633 14. Security Consideration 3635 14.1. Cryptographic Strength 3637 The strength of the cryptographic algorithms, using the measure of 3638 'bits of security' defined in NIST SP800-57 allowed for OTrP is: 3640 o At a minimum, 112 bits of security. The limiting factor for this 3641 is the RSA-2048 algorithm, which is indicated as providing 112 3642 bits of symmetric key strength in SP800-57. It is important that 3643 RSA is supported in order to enhance the interoperability of the 3644 protocol. 3646 o The option exists to choose algorithms providing 128 bits of 3647 security. This requires using TEE devices that support ECC P256. 3649 The available algorithms and key sizes specified in this document are 3650 based on industry standards. Over time the recommended or allowed 3651 cryptographic algorithms may change. It is important that the OTrP 3652 allows for crypto-agility. In this specification, TAM and TEE can 3653 negotiate an agreed upon algorithm where both include their supported 3654 algorithm in OTrP message. 3656 14.2. Message Security 3658 OTrP messages between the TAM and TEE are protected by message 3659 security using JWS and JWE. The 'Basic protocol profile' section of 3660 this document describes the algorithms used for this. All OTrP TEE 3661 devices and OTrP TAMs must meet the requirements of the basic 3662 profile. In the future additional 'profiles' can be added. 3664 PKI is used to ensure that the TEE will only communicate with a 3665 trusted TAM, and to ensure that the TAM will only communicate with a 3666 trusted TEE. 3668 14.3. TEE Attestation 3670 It is important that the TAM can trust that it is talking to a 3671 trusted TEE. This is achieved through attestation. The TEE has a 3672 private key and certificate built into it at manufacture, which is 3673 used to sign data supplied by the TAM. This allows the TAM to verify 3674 that the TEE is trusted. 3676 It is also important that the TFW (trusted firmware) can be checked. 3677 The TFW has a private key and certificate built into it at 3678 manufacture, which allows the TEE to check that that the TFW is 3679 trusted. 3681 The GetDeviceState message therefore allows the TAM to check that it 3682 trusts the TEE, and the TEE at this point will check whether it 3683 trusts the TFW. 3685 14.4. TA Protection 3687 A TA will be delivered in an encrypted form. This encryption is an 3688 additional layer within the message encryption described in the 3689 Section 11 of this document. The TA binary is encrypted for each 3690 target device with the device's TEE SP AIK public key. A TAM can 3691 either do this encryption itself or provide the TEE SP AIK public key 3692 to an SP such that the SP encrypts the encrypted TA for distribution 3693 to the TEE. 3695 The encryption algorithm can use a random AES 256 key "taek" with a 3696 16 byte random IV, and the "taek" is encrypted by the "TEE SP AIK 3697 public key". The following encrypted TA data structure is expected 3698 by a TEE: 3700 "encrypted_ta_bin": { 3701 "key": "", 3703 "iv": ", 3704 "alg": "AESCBC", 3705 "cipherdata": "" 3706 } 3708 14.5. TA Personalization Data 3710 An SP or TAM can supply personalization data for a TA to initialize 3711 for a device. Such data is passed through an InstallTA command from 3712 a TAM. The personalization data itself is (or can be) opaque to the 3713 TAM. The data can be from the SP without being revealed to the TAM. 3714 The data is sent in an encrypted manner in a request to a device such 3715 that only the device can decrypt. A device's TEE SP AIK public key 3716 for an SP is used to encrypt the data. Here JWE enveloping is used 3717 to carry all encryption key parameters along with encrypted data. 3719 "encrypted_ta_data": { // "TA personalization data" 3720 "key": "", 3722 "iv": "", 3723 "alg": "AESCBC", 3724 "cipherdata": "" 3726 } 3728 14.6. TA Trust Check at TEE 3730 A TA binary is signed by a TA signer certificate. This TA signing 3731 certificate/private key belongs to the SP, and may be self-signed 3732 (i.e., it need not participate in a trust hierarchy). It is the 3733 responsibility of the TAM to only allow verified TAs from trusted SPs 3734 into the system. Delivery of that TA to the TEE is then the 3735 responsibility of the TEE, using the security mechanisms provided by 3736 the OTrP. 3738 We allow a way for an (untrusted) application to check the 3739 trustworthiness of a TA. OTrP Agent has a function to allow an 3740 application to query the information about a TA. 3742 An application in the Rich O/S may perform verification of the TA by 3743 verifying the signature of the TA. The GetTAInformation function is 3744 available to return the TEE supplied TA signer and TAM signer 3745 information to the application. An application can do additional 3746 trust checks on the certificate returned for this TA. It might trust 3747 the TAM, or require additional SP signer trust chaining. 3749 14.7. One TA Multiple SP Case 3751 A TA for multiple SPs must have a different identifier per SP. A TA 3752 will be installed in a different SD for each respective SP. 3754 14.8. OTrP Agent Trust Model 3756 An OTrP Agent could be malware in the vulnerable Rich OS. A Client 3757 Application will connect its TAM provider for required TA 3758 installation. It gets command messages from the TAM, and passes the 3759 message to the OTrP Agent. 3761 The OTrP is a conduit for enabling the TAM to communicate with the 3762 device's TEE to manage SDs and TAs. All TAM messages are signed and 3763 sensitive data is encrypted such that the OTrP Agent cannot modify or 3764 capture sensitive data. 3766 14.9. OCSP Stapling Data for TAM Signed Messages 3768 The GetDeviceStateRequest message from a TAM to a TEE shall include 3769 OCSP stapling data for the TAM's signer certificate and for 3770 intermediate CA certificates up to the root certificate so that the 3771 TEE can verify the signer certificate's revocation status. 3773 A certificate revocation status check on a TA signer certificate is 3774 OPTIONAL by a TEE. A TAM is responsible for vetting a TA and the SP 3775 before it distributes them to devices. A TEE will trust a TA signer 3776 certificate's validation status done by a TAM when it trusts the TAM. 3778 14.10. Data Protection at TAM and TEE 3780 The TEE implementation provides protection of data on the device. It 3781 is the responsibility of the TAM to protect data on its servers. 3783 14.11. Privacy Consideration 3785 Devices are issued with a unique TEE certificate to attest the 3786 device's validity. This uniqueness also creates a privacy and 3787 tracking risk that must be mitigated. 3789 The TEE will only release the TEE certificate to a trusted TAM (it 3790 must verify the TAM certificate before proceeding). OTrP is designed 3791 such that only a TAM can obtain the TEE device certificate and 3792 firmware certificate - the GetDeviceState message requires signature 3793 checks to validate the TAM is trusted, and OTrP delivers the device's 3794 certificate(s) encrypted such that only that TAM can decrypt the 3795 response. A Client Application will never see the device 3796 certificate. 3798 An SP-specific TEE SP AIK (TEE SP Anonymous Key) is generated by the 3799 protocol for Client Applications. This provides a way for the Client 3800 Application to validate some data that the TEE may send without 3801 requiring the TEE device certificate to be released to the client 3802 device rich O/S , and to optionally allow an SP to encrypt a TA for a 3803 target device without the SP needing to be supplied with the TEE 3804 device certificate. 3806 14.12. Threat Mitigation 3808 A rogue application may perform excessive TA loading. An OTrP Agent 3809 implementation should protect against excessive calls. 3811 Rogue applications might request excessive SD creation. The TAM is 3812 responsible to ensure this is properly guarded against. 3814 Rogue OTrP Agent could replay or send TAM messages out of sequence: 3815 e.g., a TAM sends update1 and update2. The OTrP Agent replays 3816 update2 and update1 again, creating an unexpected result that a 3817 client wants. "dsihash" is used to mitigate this. The TEE MUST store 3818 DSI state and check that the DSI state matches before it does another 3819 update. 3821 Concurrent calls from a TAM to a TEE MUST be handled properly by a 3822 TEE. If multiple concurrent TAM operations take place, these could 3823 fail due to the "dsihash" being modified by another concurrent 3824 operation. The TEE is responsible for resolve any locking such that 3825 one application cannot lock other applications from using the TEE, 3826 except for a short term duration of the TAM operation taking place. 3827 For example, an OTrP operation that starts but never completes (e.g. 3828 loss of connectivity) must not prevent subsequent OTrP messages from 3829 being executed. 3831 14.13. Compromised CA 3833 A root CA for TAM certificates might get compromised. Some TEE trust 3834 anchor update mechanism is expected from device OEM. A compromised 3835 intermediate CA is covered by OCSP stapling and OCSP validation check 3836 in the protocol. A TEE should validate certificate revocation about 3837 a TAM certificate chain. 3839 If the root CA of some TEE device certificates is compromised, these 3840 devices might be rejected by a TAM, which is a decision of the TAM 3841 implementation and policy choice. Any intermediate CA for TEE device 3842 certificates SHOULD be validated by TAM with a Certificate Revocation 3843 List (CRL) or Online Certificate Status Protocol (OCSP) method. 3845 14.14. Compromised TAM 3847 The TEE SHOULD use validation of the supplied TAM certificates and 3848 OCSP stapled data to validate that the TAM is trustworthy. 3850 Since PKI is used, the integrity of the clock within the TEE 3851 determines the ability of the TEE to reject an expired TAM 3852 certificate, or revoked TAM certificate. Since OCSP stapling 3853 includes signature generation time, certificate validity dates are 3854 compared to the current time. 3856 14.15. Certificate Renewal 3858 TFW and TEE device certificates are expected to be long lived, longer 3859 than the lifetime of a device. A TAM certificate usually has a 3860 moderate lifetime of 2 to 5 years. A TAM should get renewed or 3861 rekeyed certificates. The root CA certificates for a TAM, which are 3862 embedded into the trust anchor store in a device, should have long 3863 lifetimes that don't require device trust anchor update. On the 3864 other hand, it is imperative that OEMs or device providers plan for 3865 support of trust anchor update in their shipped devices. 3867 15. Acknowledgements 3869 We thank Alin Mutu for his contribution to many discussion that 3870 helped to design the trust flow mechanisms, and the creation of the 3871 flow diagrams. We also thank the following people (in alphabetical 3872 order) for their input and review: Sangsu Baek, Rob Coombs, Dapeng 3873 Liu, Dave Thaler, and Pengfei Zhao. 3875 16. References 3877 16.1. Normative References 3879 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3880 Requirement Levels", BCP 14, RFC 2119, 3881 DOI 10.17487/RFC2119, March 1997, . 3884 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 3885 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 3886 . 3888 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 3889 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 3890 2015, . 3892 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 3893 RFC 7516, DOI 10.17487/RFC7516, May 2015, 3894 . 3896 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 3897 DOI 10.17487/RFC7517, May 2015, . 3900 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 3901 DOI 10.17487/RFC7518, May 2015, . 3904 16.2. Informative References 3906 [GPTEE] Global Platform, "Global Platform, GlobalPlatform Device 3907 Technology: TEE System Architecture, v1.0", 2013. 3909 [GPTEECLAPI] 3910 Global Platform, "Global Platform, GlobalPlatform Device 3911 Technology: TEE Client API Specification, v1.0", 2013. 3913 Appendix A. Sample Messages 3915 A.1. Sample Security Domain Management Messages 3917 A.1.1. Sample GetDeviceState 3919 A.1.1.1. Sample GetDeviceStateRequest 3921 The TAM builds a "GetDeviceStateTBSRequest" message. 3923 { 3924 "GetDeviceStateTBSRequest": { 3925 "ver": "1.0", 3926 "rid": "8C6F9DBB-FC39-435c-BC89-4D3614DA2F0B", 3927 "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE", 3928 "ocspdat": "c2FtcGxlIG9jc3BkYXQgQjY0IGVuY29kZWQgQVNOMQ==", 3929 "icaocspdat": "c2FtcGxlIGljYW9jc3BkYXQgQjY0IGVuY29kZWQgQVNOMQ==", 3930 "supportedsigalgs": "RS256" 3931 } 3932 } 3934 The TAM signs "GetDeviceStateTBSRequest", creating 3935 "GetDeviceStateRequest" 3937 { 3938 "GetDeviceStateRequest": { 3939 "payload":" 3940 ewoJIkdldERldmljZVN0YXRlVEJTUmVxdWVzdCI6IHsKCQkidmVyIjogIjEuMCIsCgkJ 3941 InJpZCI6IHs4QzZGOURCQi1GQzM5LTQzNWMtQkM4OS00RDM2MTREQTJGMEJ9LAoJCSJ0 3942 aWQiOiAiezRGNDU0QTdGLTAwMkQtNDE1Ny04ODRFLUIwREQxQTA2QThBRX0iLAoJCSJv 3943 Y3NwZGF0IjogImMyRnRjR3hsSUc5amMzQmtZWFFnUWpZMElHVnVZMjlrWldRZ1FWTk9N 3944 UT09IiwKCQkiaWNhb2NzcGRhdCI6ICJjMkZ0Y0d4bElHbGpZVzlqYzNCa1lYUWdRalkw 3945 SUdWdVkyOWtaV1FnUVZOT01RPT0iLAoJCSJzdXBwb3J0ZWRzaWdhbGdzIjogIlJTMjU2 3946 IgoJfQp9", 3947 "protected": "eyJhbGciOiJSUzI1NiJ9", 3948 "header": { 3949 "x5c": ["ZXhhbXBsZSBBU04xIHNpZ25lciBjZXJ0aWZpY2F0ZQ==", 3950 "ZXhhbXBsZSBBU04xIENBIGNlcnRpZmljYXRl"] 3951 }, 3952 "signature":"c2FtcGxlIHNpZ25hdHVyZQ" 3953 } 3954 } 3956 A.1.1.2. Sample GetDeviceStateResponse 3958 The TAM sends "GetDeviceStateRequest" to the OTrP Agent 3960 The OTrP Agent obtains "dsi" from each TEE. (In this example there 3961 is a single TEE.) 3963 The TEE obtains signed "fwdata" from firmware. 3965 The TEE builds "dsi" - summarizing device state of the TEE. 3967 { 3968 "dsi": { 3969 "tfwdata": { 3970 "tbs": "ezRGNDU0QTdGLTAwMkQtNDE1Ny04ODRFLUIwREQxQTA2QThBRX0=", 3971 "cert": "ZXhhbXBsZSBGVyBjZXJ0aWZpY2F0ZQ==", 3972 "sigalg": "RS256", 3973 "sig": "c2FtcGxlIEZXIHNpZ25hdHVyZQ==" 3974 }, 3975 "tee": { 3976 "name": "Primary TEE", 3977 "ver": "1.0", 3978 "cert": "c2FtcGxlIFRFRSBjZXJ0aWZpY2F0ZQ==", 3979 "cacert": [ 3980 "c2FtcGxlIENBIGNlcnRpZmljYXRlIDE=", 3981 "c2FtcGxlIENBIGNlcnRpZmljYXRlIDI=" 3982 ], 3983 "sdlist": { 3984 "cnt": "1", 3985 "sd": [ 3986 { 3987 "name": "default.acmebank.com", 3988 "spid": "acmebank.com", 3989 "talist": [ 3990 { 3991 "taid": "acmebank.secure.banking", 3992 "taname": "Acme secure banking app" 3993 }, 3994 { 3995 "taid": "acmebank.loyalty.rewards", 3996 "taname": "Acme loyalty rewards app" 3997 } 3998 ] 3999 } 4000 ] 4001 }, 4002 "teeaiklist": [ 4003 { 4004 "spaik": "c2FtcGxlIEFTTjEgZW5jb2RlZCBQS0NTMSBwdWJsaWNrZXk=", 4005 "spaiktype": "RSA", 4006 "spid": "acmebank.com" 4007 } 4008 ] 4009 } 4010 } 4011 } 4013 The TEE encrypts "dsi", and embeds it into a 4014 "GetDeviceTEEStateTBSResponse" message. 4016 { 4017 "GetDeviceTEEStateTBSResponse": { 4018 "ver": "1.0", 4019 "status": "pass", 4020 "rid": "{8C6F9DBB-FC39-435c-BC89-4D3614DA2F0B}", 4021 "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}", 4022 "signerreq":"false", 4023 "edsi": { 4024 "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0K", 4025 "recipients": [ 4026 { 4027 "header": { 4028 "alg": "RSA1_5" 4029 }, 4030 "encrypted_key": 4031 " 4032 QUVTMTI4IChDRUspIGtleSwgZW5jcnlwdGVkIHdpdGggVFNNIFJTQSBwdWJsaWMg 4033 a2V5LCB1c2luZyBSU0ExXzUgcGFkZGluZw" 4034 } 4035 ], 4036 "iv": "ySGmfZ69YlcEilNr5_SGbA", 4037 "ciphertext": 4038 " 4039 c2FtcGxlIGRzaSBkYXRhIGVuY3J5cHRlZCB3aXRoIEFFUzEyOCBrZXkgZnJvbSByZW 4040 NpcGllbnRzLmVuY3J5cHRlZF9rZXk", 4041 "tag": "c2FtcGxlIGF1dGhlbnRpY2F0aW9uIHRhZw" 4042 } 4043 } 4044 } 4046 The TEE signs "GetDeviceTEEStateTBSResponse" and returns it to the 4047 OTrP Agent. The OTrP Agent encodes "GetDeviceTEEStateResponse" into 4048 an array to form "GetDeviceStateResponse". 4050 { 4051 "GetDeviceStateResponse": [ 4052 { 4053 "GetDeviceTEEStateResponse": { 4054 "payload": 4055 " 4056 ewogICJHZXREZXZpY2VURUVTdGF0ZVRCU1Jlc3BvbnNlIjogewogICAgInZlciI6 4057 ICIxLjAiLAogICAgInN0YXR1cyI6ICJwYXNzIiwKICAgICJyaWQiOiAiezhDNkY5 4058 REJCLUZDMzktNDM1Yy1CQzg5LTREMzYxNERBMkYwQn0iLAogICAgInRpZCI6ICJ7 4059 NEY0NTRBN0YtMDAyRC00MTU3LTg4NEUtQjBERDFBMDZBOEFFfSIsCgkic2lnbmVy 4060 cmVxIjoiZmFsc2UiLAogICAgImVkc2kiOiB7CiAgICAgICJwcm90ZWN0ZWQiOiAi 4061 ZXlKbGJtTWlPaUpCTVRJNFEwSkRMVWhUTWpVMkluMEsiLAogICAgICAicmVjaXBp 4062 ZW50cyI6IFsKICAgICAgICB7CiAgICAgICAgICAiaGVhZGVyIjogewogICAgICAg 4063 ICAgImFsZyI6ICJSU0ExXzUiCiAgICAgICAgfSwKICAgICAgICAiZW5jcnlwdGVk 4064 X2tleSI6CiAgICAgICAgIgogICAgICAgIFFVVlRNVEk0SUNoRFJVc3BJR3RsZVN3 4065 Z1pXNWpjbmx3ZEdWa0lIZHBkR2dnVkZOTklGSlRRU0J3ZFdKc2FXTWcKICAgICAg 4066 ICBhMlY1TENCMWMybHVaeUJTVTBFeFh6VWdjR0ZrWkdsdVp3IgogICAgICAgIH0K 4067 ICAgICAgXSwKICAgICAgIml2IjogInlTR21mWjY5WWxjRWlsTnI1X1NHYkEiLAog 4068 ICAgICAiY2lwaGVydGV4dCI6CiAgICAgICIKICAgICAgYzJGdGNHeGxJR1J6YVNC 4069 a1lYUmhJR1Z1WTNKNWNIUmxaQ0IzYVhSb0lFRkZVekV5T0NCclpYa2dabkp2YlNC 4070 eVpXCiAgICAgIE5wY0dsbGJuUnpMbVZ1WTNKNWNIUmxaRjlyWlhrIiwKICAgICAg 4071 InRhZyI6ICJjMkZ0Y0d4bElHRjFkR2hsYm5ScFkyRjBhVzl1SUhSaFp3IgogICAg 4072 fQogIH0KfQ", 4073 "protected": "eyJhbGciOiJSUzI1NiJ9", 4074 "signature": "c2FtcGxlIHNpZ25hdHVyZQ" 4075 } 4076 } 4077 ] 4078 } 4080 The TEE returns "GetDeviceStateResponse" back to the OTrP Agent, 4081 which returns message back to the TAM. 4083 A.1.2. Sample CreateSD 4085 A.1.2.1. Sample CreateSDRequest 4086 { 4087 "CreateSDTBSRequest": { 4088 "ver":"1.0", 4089 "rid":"req-01", 4090 "tid":"tran-01", 4091 "tee":"SecuriTEE", 4092 "nextdsi":"false", 4093 "dsihash":"Iu-c0-fGrpMmzbbtiWI1U8u7wMJE7IK8wkJpsVuf2js", 4094 "content":{ 4095 "spid":"bank.com", 4096 "sdname":"sd.bank.com", 4097 "spcert":"MIIDFjCCAn- 4098 gAwIBAgIJAIk0Tat0tquDMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNVBAYTAkTAMQ4wD 4099 AYDVQQIDAVTZW91bDESMBAGA1UEBwwJR3Vyby1kb25nMRAwDgYDVQQKDAdTb2xhY2l 4100 hMRAwDgYDVQQLDAdTb2xhY2lhMRUwEwYDVQQDDAxTb2xhLWNpYS5jb20wHhcNMTUwN 4101 zAyMDg1MTU3WhcNMjAwNjMwMDg1MTU3WjBsMQswCQYDVQQGEwJLUjEOMAwGA1UECAw 4102 FU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU29sYWNpYTEQMA4GA 4103 1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tMIGfMA0GCSqGSIb3DQE 4104 BAQUAA4GNADCBiQKBgQDYWLrFf2OFMEciwSYsyhaLY4kslaWcXA0hCWJRaFzt5mU- 4105 lpSJ4jeu92inBbsXcI8PfRbaItsgW1TD1Wg4gQH4MX_YtaBoOepE-- 4106 3JoZZyPyCWS3AaLYWrDmqFXdbzaO1i8GxB7zz0gWw55bZ9jyzcl5gQzWSqMRpx_dca 4107 d2SP2wIDAQABo4G_MIG8MIGGBgNVHSMEfzB9oXCkbjBsMQswCQYDVQQGEwJLUjEOMA 4108 wGA1UECAwFU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU29sYWNp 4109 YTEQMA4GA1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tggkAiTRNq3 4110 S2q4MwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0lAQH_BAwwCgYIKwYB 4111 BQUHAwMwDQYJKoZIhvcNAQEFBQADgYEAEFMhRwEQ- 4112 LDa9O7P1N0mcLORpo6fW3QuJfuXbRQRQGoXddXMKazI4VjbGaXhey7Bzvk6TZYDa- 4113 GRiZby1J47UPaDQR3UiDzVvXwCOU6S5yUhNJsW_BeMViYj4lssX28iPpNwLUCVm1QV 4114 THILI6afLCRWXXclc1L5KGY290OwIdQ", 4115 "tamid":"TAM_x.acme.com", 4116 "did":"zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM" 4117 } 4118 } 4119 } 4121 Below is a sample message after the content is encrypted and encoded 4123 { 4124 "CreateSDRequest": { 4125 "payload":" 4126 eyJDcmVhdGVTRFRCU1JlcXVlc3QiOnsidmVyIjoiMS4wIiwicmlkIjoicmVxLTAxIiwidG 4127 lkIjoidHJhbi0wMSIsInRlZSI6IlNlY3VyaVRFRSIsIm5leHRkc2kiOiJmYWxzZSIsImRz 4128 aWhhc2giOiIyMmVmOWNkM2U3YzZhZTkzMjZjZGI2ZWQ4OTYyMzU1M2NiYmJjMGMyNDRlYz 4129 gyYmNjMjQyNjliMTViOWZkYTNiIiwiY29udGVudCI6eyJwcm90ZWN0ZWQiOiJlLUtBbkdW 4130 dVktS0FuVHJpZ0p4Qk1USTRRMEpETFVoVE1qVTI0b0NkZlEiLCJyZWNpcGllbnRzIjpbey 4131 JoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0sImVuY3J5cHRlZF9rZXkiOiJTUzE2NTl4Q2FJ 4132 c1dUeUlsVTZPLUVsZzU4UUhvT1pCekxVRGptVG9vanBaWE54TVpBakRMcWtaSTdEUzhOVG 4133 FIWHcxczFvZjgydVhsM0d6NlVWMkRoZDJ3R2l6Y2VEdGtXc1RwZDg4QVYwaWpEYTNXa3lk 4134 dEpSVmlPOGdkSlEtV29NSUVJRUxzVGthblZCb25wQkF4ZHE0ckVMbl9TZlliaFg4Zm9ub2 4135 gxUVUifV0sIml2IjoiQXhZOERDdERhR2xzYkdsamIzUm9aUSIsImNpcGhlcnRleHQiOiI1 4136 bmVWZXdndm55UXprR3hZeWw5QlFrZTJVNjVaOHp4NDdlb3NzM3FETy0xY2FfNEpFY3NLcj 4137 ZhNjF5QzBUb0doYnJOQWJXbVRSemMwSXB5bTF0ZjdGemp4UlhBaTZBYnVSM2gzSUpRS1Bj 4138 UUVvRUlkZ2tWX0NaZTM2eTBkVDBpRFBMclg0QzFkb0dmMEdvaWViRC1yVUg1VUtEY3BsTW 4139 9lTjZvUnFyd0dnNUhxLTJXM3B4MUlzY0h4SktRZm11dkYxMTJ4ajBmZFNZX0N2WFE1NTJr 4140 TVRDUW1ZbzRPaGF2R0ZvaG9TZVVnaGZSVG1LYWp3OThkTzdhREdrUEpRUlBtYVVHWllEMW 4141 JXd01nMXFRV3RPd19EZlIyZDNzTzVUN0pQMDJDUFprVXBiQ3dZYVcybW9HN1c2Zlc2U3V5 4142 Q2lpd2pQWmZSQmIzSktTVTFTd1kxYXZvdW02OWctaDB6by12TGZvbHRrWFV2LVdPTXZTY0 4143 JzR25NRzZYZnMzbXlTWnJ1WTNRR09wVVRzdjFCQ0JqSTJpdjkwb2U2aXFCcVpxQVBxbzdi 4144 ajYwVlJGQzZPTlNLZExGQTIyU3pqRHo1dmtnTXNEaHkwSzlDeVhYN1Z6MkNLTXJvQjNiUE 4145 xFZF9abTZuVWlkTFN5cVJ5cXJxTmVnN1lmQng3aV93X0dzRW9rX1VYZXd6RGtneHp6RjZj 4146 XzZ6S0s3UFktVnVmYUo0Z2dHZmlpOHEwMm9RZ1VEZTB2Vm1FWDc0c2VQX2RxakVpZVVOYm 4147 xBZE9sS2dBWlFGdEs4dy1xVUMzSzVGTjRoUG9yeDc2b3lPVUpOQTVFZVV2Qy1jR2tMcTNQ 4148 UG1GRmQyaUtOTElCTEJzVWl6c1h3RERvZVA5SmktWGt5ZEQtREN1SHdpcno0OEdNNWVLSj 4149 Q5WVdqRUtFQko2T01NNUNmZHZ4cDNmVG1uUTdfTXcwZ3FZVDRiOUJJSnBfWjA3TTctNUpE 4150 emg0czhyU3dsQzFXU3V2RmhRWlJCcXJtX2RaUlRIb0VaZldXc1VCSWVNWWdxNG1zb0JqTj 4151 NXSzhnRWYwZGI5a3Z6UG9LYmpJRy10UUE2R2l1X3pHaFVfLXFBV1lLemVKMDZ6djRIWlBO 4152 dHktQXRyTGF0WGhtUTdOQlVrX0hvbjdOUWxhU1g1ZHVNVmN4bGs1ZHVrWFZNMDgxa09wYV 4153 kzbDliQVFfYVhTM0FNaFFTTVVsT3dnTDZJazFPYVpaTGFMLUE3ejlITnlESmFEWTVhakZK 4154 TWFDV1lfOG94YlNoQUktNXA2MmNuT0xzV0dNWWNKTlBGVTZpcWlMR19oc3JfNlNKMURhbD 4155 VtQ0YycnBJLUItMlhuckxZR01ZS0NEZ2V2dGFnbi1DVUV6RURwR3ozQ2VLcWdQU0Vqd3BK 4156 N0M3NXduYTlCSmtTUkpOdDNla3hoWElrcnNEazRHVVpMSDdQYzFYZHdRTXhxdWpzNmxJSV 4157 EycjM1NWEtVkotWHdPcFpfY3RPdW96LTA4WHdYQ3RkTEliSFFVTG40RjlMRTRtanU0dUxS 4158 bjNSc043WWZ1S3dCVmVEZDJ6R3NBY0s5SVlDa3hOaDk3dDluYW1iMDZqSXVoWXF5QkhWRU 4159 9nTkhici1rMDY1bW9OVk5lVVUyMm5OdVNKS0ZxVnIxT0dKNGVfNXkzYkNwTmxTeEFPV1Bn 4160 RnJzU0Flc2JJOWw4eVJtVTAwenJYdGc4OWt5SjlCcXN2eXA1RE8wX2FtS1JyMXB1MVJVWF 4161 lFZzB2ampKS1FSdDVZbXRUNFJzaWpqdGRDWDg3UUxJaUdSY0hDdlJzUzZSdDJESmNYR1ht 4162 UGQyc0ZmNUZyNnJnMkFzX3BmUHN3cnF1WlAxbVFLc3RPMFVkTXpqMTlyb2N1NHVxVXlHUD 4163 lWWU54cHVnWVdNSjRYb1dRelJtWGNTUEJ4VEtnenFPS2s3UnRzWWVMNXl4LVM4NjV0cHVz 4164 dTA0bXpzYUJRZ21od1ZFVXBRdWNrcG1YWkNLNHlJUXktaHNFQUlJSmVxdFB3dVAySXF0X2 4165 I5dlk0bzExeXdzeXhzdmp2RnNKN0VVZU1MaGE2R2dSanBSbnU5RWIzRnlJZ0U5M0VVNEEw 4166 T0lUMWlOSGNRYWc0eWtOc3dPdkxQbjZIZ21zQ05ESlgwekc2RlFDMTZRdjBSQ25SVTdfV2 4167 VvblhSTUZwUzZRZ1JiSk45R1NMckN5bklJSWxUcDBxNHBaS05zM0tqQ2tMUzJrb3Bhd2Y0 4168 WF9BUllmTko3a0s5eW5BR0dCcktnUWJNRWVxUEFmMDBKMlYtVXpuU1JMZmQ4SGs3Y2JEdk 4169 5RQlhHQW9BR0ViaGRwVUc0RXFwMlVyQko3dEtyUUVSRlh4RTVsOFNHY2czQ1RmN2Zoazdx 4170 VEFBVjVsWEFnOUtOUDF1c1ZRZk1fUlBleHFNTG9WQVVKV2syQkF6WF9uSEhkVVhaSVBIOG 4171 hLeDctdEFRV0dTWUd0R2FmanZJZzI2c082TzloQWZVd3BpSV90MzF6SkZORDU0OTZURHBz 4172 QmNnd2dMLU1UcVhCRUJ2NEhvQld5SG1DVjVFMUwiLCJ0YWciOiJkbXlEeWZJVlNJUi1Ren 4173 ExOEgybFRIeEMxbl9HZEtrdnZNMDJUcHdsYzQwIn19fQ", 4174 "protected":"e-KAnGFsZ-KAnTrigJxSUzI1NuKAnX0", //RSAwithSHA256 4175 "header": { 4176 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4177 "signer":" 4178 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA 4179 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4180 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh 4181 cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p 4182 YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy 4183 BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4184 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4185 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3 4186 c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4187 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA 4188 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4189 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR 4190 MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq 4191 hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G 4192 SZ1MdyIZV8fwdEmD90IvtMHgtzK- 4193 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA 4194 UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4195 }, 4196 "signature":"nuQUsCTEBLeaRzuwd7q1iPIYEJ2eJfurO5sT5Y- 4197 N03zFRcv1jvrqMHtx_pw0Y9YWjmpoWfpfelhwGEko9SgeeBnznmkZbp7kjS6MmX4CKz 4198 9OApe3-VI7yL9Yp0WNdRh3425eYfuapCy3lcXFln5JBAUnU_OzUg3RWxcU_yGnFsw" 4199 } 4200 } 4202 A.1.2.2. Sample CreateSDResponse 4204 { 4205 "CreateSDTBSResponse": { 4206 "ver":"1.0", 4207 "status":"pass", 4208 "rid":"req-01", 4209 "tid":"tran-01", 4210 "content":{ 4211 "did":"zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM", 4212 "sdname":"sd.bank.com", 4213 "teespaik":"AQABjY9KiwH3hkMmSAAN6CLXot525U85WNlWKAQz5TOdfe_CM8h- 4214 X6_EHX1gOXoyRXaBiKMqWb0YZLCABTw1ytdXy2kWa525imRho8Vqn6HDGsJDZPDru9 4215 GnZR8pZX5ge_dWXB_uljMvDttc5iAWEJ8ZgcpLGtBTGLZnQoQbjtn1lIE", 4216 } 4217 } 4218 } 4220 Below is the response message after the content is encrypted and 4221 encoded. 4223 { 4224 "CreateSDResponse": { 4225 "payload":" 4226 eyJDcmVhdGVTRFRCU1Jlc3BvbnNlIjp7InZlciI6IjEuMCIsInN0YXR1cyI6InBhc3Mi 4227 LCJyaWQiOiJyZXEtMDEiLCJ0aWQiOiJ0cmFuLTAxIiwiY29udGVudCI6eyJwcm90ZWN0 4228 ZWQiOiJlLUtBbkdWdVktS0FuVHJpZ0p4Qk1USTRRMEpETFVoVE1qVTI0b0NkZlEiLCJy 4229 ZWNpcGllbnRzIjpbeyJoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0sImVuY3J5cHRlZF9r 4230 ZXkiOiJOX0I4R3pldUlfN2hwd0wwTFpHSTkxVWVBbmxJRkJfcndmZU1yZERrWnFGak1s 4231 VVhjdlI0XzhhOGhyeFI4SXR3aEtFZnVfRWVLRDBQb0dqQ2pCSHcxdG1ULUN6eWhsbW5v 4232 Slk3LXllWnZzRkRpc2VNTkd0eGE0OGZJYUs2VWx5NUZMYXBCZVc5T1I5bmktOU9GQV9j 4233 aFVuWWl3b2Q4ZTJFa0Vpd0JEZ1EzMk0ifV0sIml2IjoiQXhZOERDdERhR2xzYkdsamIz 4234 Um9aUSIsImNpcGhlcnRleHQiOiJsalh6Wk5JTmR1WjFaMXJHVElkTjBiVUp1RDRVV2xT 4235 QVptLWd6YnJINFVDYy1jMEFQenMtMWdWSFk4NTRUR3VMYkdyRmVHcDFqM2Fsb1lacWZp 4236 ZnE4aEt3Ty16RFlBN2tmVFhBZHp6czM4em9xeG4zbHoyM2w1RUlGUWhrOHBRWTRYTHRW 4237 M3ZBQWlNYnlrQ1Q3VS1CWDdWcjBacVNhYWZTQVZ4OFBLQ1RIU3hHN3hHVko0NkxxRzJS 4238 RE54WXQ4RC1SQ3lZUi1zRTM0MUFKZldEc2FLaGRRbzJXcjNVN1hTOWFqaXJtWjdqTlJ4 4239 cVRodHJBRWlIY1ctOEJMdVFHWEZ1YUhLMTZrenJKUGl4d0VXbzJ4cmw4cmkwc3ZRcHpl 4240 Z2M3MEt2Z0I0NUVaNHZiNXR0YlUya25hN185QU1Wcm4wLUJaQ1Bnb280MWlFblhuNVJn 4241 TXY2c2V2Y1JPQ2xHMnpWSjFoRkVLYjk2akEiLCJ0YWciOiIzOTZISTk4Uk1NQnR0eDlo 4242 ZUtsODROaVZLd0lJSzI0UEt2Z1RGYzFrbEJzIn19fQ", 4243 "protected": "e-KAnGFsZ-KAnTrigJxSUzI1NuKAnX0", 4244 "header": { 4245 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4246 "signer":" 4247 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJ 4248 BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp 4249 Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcN 4250 MTUwNzAyMDkwMTE4WhcNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzET 4251 MBEGA1UECAwKQ2FsaWZvcm5pYTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8G 4252 A1UECgwYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIGfMA0GCSqGSIb3DQEB 4253 AQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4254 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4255 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA 4256 6b_ZI3c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4257 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJ 4258 BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp 4259 Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX 4260 9nxZBNQWDjAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8E 4261 DDAKBggrBgEFBQcDAzANBgkqhkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4iv 4262 em4cIckfxzTBBiPHCjrrjB2X8Ktn8GSZ1MdyIZV8fwdEmD90IvtMHgtzK- 4263 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fV 4264 rJvnYAUBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4265 }, 4266 "signature":"jnJtaB0vFFwrE-qKOR3Pu9pf2gNoI1s67GgPCTq0U- 4267 qrz97svKpuh32WgCP2MWCoQPEswsEX-nxhIx_siTe4zIPO1nBYn- 4268 R7b25rQaF87O8uAOOnBN5Yl2Jk3laIbs- 4269 hGE32aRZDhrVoyEdSvIFrT6AQqD20bIAZGqTR-zA-900" 4270 } 4271 } 4273 A.1.3. Sample UpdateSD 4274 A.1.3.1. Sample UpdateSDRequest 4276 { 4277 "UpdateSDTBSRequest": { 4278 "ver": "1.0", 4279 "rid": "1222DA7D-8993-41A4-AC02-8A2807B31A3A", 4280 "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE", 4281 "tee": "Primary TEE ABC", 4282 "nextdsi": "false", 4283 "dsihash": 4284 " 4285 IsOvwpzDk8Onw4bCrsKTJsONwrbDrcKJYjVTw4vCu8OAw4JEw6zCgsK8w4JCacKxW8Kf 4286 w5o7", 4287 "content": { // NEEDS to BE ENCRYPTED 4288 "tamid": "id1.TAMxyz.com", 4289 "spid": "com.acmebank.spid1", 4290 "sdname": "com.acmebank.sdname1", 4291 "changes": { 4292 "newsdname": "com.acmebank.sdname2", 4293 "newspid": "com.acquirer.spid1", 4294 "spcert": 4295 "MIIDFjCCAn- 4296 gAwIBAgIJAIk0Tat0tquDMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNVBAYTAkTAMQ4 4297 wDAYDVQQIDAVTZW91bDESMBAGA1UEBwwJR3Vyby1kb25nMRAwDgYDVQQKDAdTb2x 4298 hY2lhMRAwDgYDVQQLDAdTb2xhY2lhMRUwEwYDVQQDDAxTb2xhLWNpYS5jb20wHhc 4299 NMTUwNzAyMDg1MTU3WhcNMjAwNjMwMDg1MTU3WjBsMQswCQYDVQQGEwJLUjEOMAw 4300 GA1UECAwFU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU29sYWN 4301 pYTEQMA4GA1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tMIGfMA0 4302 GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDYWLrFf2OFMEciwSYsyhaLY4kslaWcXA0 4303 hCWJRaFzt5mU- 4304 lpSJ4jeu92inBbsXcI8PfRbaItsgW1TD1Wg4gQH4MX_YtaBoOepE-- 4305 3JoZZyPyCWS3AaLYWrDmqFXdbzaO1i8GxB7zz0gWw55bZ9jyzcl5gQzWSqMRpx_d 4306 cad2SP2wIDAQABo4G_MIG8MIGGBgNVHSMEfzB9oXCkbjBsMQswCQYDVQQGEwJLUj 4307 EOMAwGA1UECAwFU2VvdWwxEjAQBgNVBAcMCUd1cm8tZG9uZzEQMA4GA1UECgwHU2 4308 9sYWNpYTEQMA4GA1UECwwHU29sYWNpYTEVMBMGA1UEAwwMU29sYS1jaWEuY29tgg 4309 kAiTRNq3S2q4MwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0lAQH_BA 4310 wwCgYIKwYBBQUHAwMwDQYJKoZIhvcNAQEFBQADgYEAEFMhRwEQ- 4311 LDa9O7P1N0mcLORpo6fW3QuJfuXbRQRQGoXddXMKazI4VjbGaXhey7Bzvk6TZYDa 4312 - 4313 GRiZby1J47UPaDQR3UiDzVvXwCOU6S5yUhNJsW_BeMViYj4lssX28iPpNwLUCVm1 4314 QVTHILI6afLCRWXXclc1L5KGY290OwIdQ", 4315 "renewteespaik": "0" 4316 } 4317 } 4318 } 4319 } 4320 A.1.3.2. Sample UpdateSDResponse 4322 { 4323 "UpdateSDTBSResponse": { 4324 "ver": "1.0", 4325 "status": "pass", 4326 "rid": "1222DA7D-8993-41A4-AC02-8A2807B31A3A", 4327 "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE", 4328 "content": { 4329 "did": "MTZENTE5Qzc0Qzk0NkUxMzYxNzk0NjY4NTc3OTY4NTI=", 4330 "teespaik": 4331 "AQABjY9KiwH3hkMmSAAN6CLXot525U85WNlWKAQz5TOdfe_CM8h- 4332 X6_EHX1gOXoyRXaBiKMqWb0YZLCABTw1ytdXy2kWa525imRho8Vqn6HDGsJDZPDru9 4333 GnZR8pZX5ge_dWXB_uljMvDttc5iAWEJ8ZgcpLGtBTGLZnQoQbjtn1lIE", 4334 "teespaiktype": "RSA" 4335 } 4336 } 4337 } 4339 A.1.4. Sample DeleteSD 4341 A.1.4.1. Sample DeleteSDRequest 4343 The TAM builds message - including data to be encrypted. 4345 { 4346 "DeleteSDTBSRequest": { 4347 "ver": "1.0", 4348 "rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}", 4349 "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}", 4350 "tee": "Primary TEE", 4351 "nextdsi": "false", 4352 "dsihash": "AAECAwQFBgcICQoLDA0ODwABAgMEBQYHCAkKCwwNDg8=", 4353 "content": ENCRYPTED { 4354 "tamid": "TAM1.com", 4355 "sdname": "default.acmebank.com", 4356 "deleteta": "1" 4357 } 4358 } 4359 } 4361 The TAM encrypts the "content". 4363 { 4364 "DeleteSDTBSRequest": { 4365 "ver": "1.0", 4366 "rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}", 4367 "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}", 4368 "tee": "Primary TEE", 4369 "nextdsi": "false", 4370 "dsihash": "AAECAwQFBgcICQoLDA0ODwABAgMEBQYHCAkKCwwNDg8=", 4371 "content": { 4372 "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0", 4373 "recipients": [ 4374 { 4375 "header": { 4376 "alg": "RSA1_5" 4377 }, 4378 "encrypted_key": 4379 " 4380 QUVTMTI4IChDRUspIGtleSwgZW5jcnlwdGVkIHdpdGggVFNNIFJTQSBwdWJsaWMga2 4381 V5LCB1c2luZyBSU0ExXzUgcGFkZGluZw" 4382 } 4383 ], 4384 "iv": "rWO5DVmQX9ogelMLBIogIA", 4385 "ciphertext": 4386 " 4387 c2FtcGxlIGRzaSBkYXRhIGVuY3J5cHRlZCB3aXRoIEFFUzEyOCBrZXkgZnJvbSByZWNp 4388 cGllbnRzLmVuY3J5cHRlZF9rZXk", 4389 "tag": "c2FtcGxlIGF1dGhlbnRpY2F0aW9uIHRhZw" 4390 } 4391 } 4392 } 4394 The TAM signs the "DeleteSDTBSRequest" to form a "DeleteSDRequest" 4395 { 4396 "DeleteSDRequest": { 4397 "payload":" 4398 ewoJIkRlbGV0ZVNEVEJTUmVxdWVzdCI6IHsKCQkidmVyIjogIjEuMCIsCgkJInJp 4399 ZCI6ICJ7NzEyNTUxRjUtREZCMy00M2YwLTlBNjMtNjYzNDQwQjkxRDQ5fSIsCgkJ 4400 InRpZCI6ICJ7NEY0NTRBN0YtMDAyRC00MTU3LTg4NEUtQjBERDFBMDZBOEFFfSIs 4401 CgkJInRlZSI6ICJQcmltYXJ5IFRFRSIsCgkJIm5leHRkc2kiOiAiZmFsc2UiLAoJ 4402 CSJkc2loYXNoIjogIkFBRUNBd1FGQmdjSUNRb0xEQTBPRHdBQkFnTUVCUVlIQ0Fr 4403 S0N3d05EZzg9IiwKCQkiY29udGVudCI6IHsKCQkJInByb3RlY3RlZCI6ICJleUps 4404 Ym1NaU9pSkJNVEk0UTBKRExVaFRNalUySW4wIiwKCQkJInJlY2lwaWVudHMiOiBb 4405 ewoJCQkJImhlYWRlciI6IHsKCQkJCQkiYWxnIjogIlJTQTFfNSIKCQkJCX0sCgkJ 4406 CQkiZW5jcnlwdGVkX2tleSI6ICJRVVZUTVRJNElDaERSVXNwSUd0bGVTd2daVzVq 4407 Y25sd2RHVmtJSGRwZEdnZ1ZGTk5JRkpUUVNCd2RXSnNhV01nYTJWNUxDQjFjMmx1 4408 WnlCU1UwRXhYelVnY0dGa1pHbHVadyIKCQkJfV0sCgkJCSJpdiI6ICJyV081RFZt 4409 UVg5b2dlbE1MQklvZ0lBIiwKCQkJImNpcGhlcnRleHQiOiAiYzJGdGNHeGxJR1J6 4410 YVNCa1lYUmhJR1Z1WTNKNWNIUmxaQ0IzYVhSb0lFRkZVekV5T0NCclpYa2dabkp2 4411 YlNCeVpXTnBjR2xsYm5SekxtVnVZM0o1Y0hSbFpGOXJaWGsiLAoJCQkidGFnIjog 4412 ImMyRnRjR3hsSUdGMWRHaGxiblJwWTJGMGFXOXVJSFJoWnciCgkJfQoJfQp9", 4413 "protected":"eyJhbGciOiJSUzI1NiJ9", 4414 "header": { 4415 "x5c": ["ZXhhbXBsZSBBU04xIHNpZ25lciBjZXJ0aWZpY2F0ZQ==", 4416 "ZXhhbXBsZSBBU04xIENBIGNlcnRpZmljYXRl"] 4417 }, 4418 "signature":"c2FtcGxlIHNpZ25hdHVyZQ" 4419 } 4420 } 4422 A.1.4.2. Sample DeleteSDResponse 4424 The TEE creates a "DeleteSDTBSResponse" to respond to the 4425 "DeleteSDRequest" message from the TAM, including data to be 4426 encrypted. 4428 { 4429 "DeleteSDTBSResponse": { 4430 "ver": "1.0", 4431 "status": "pass", 4432 "rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}", 4433 "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}", 4434 "content": ENCRYPTED { 4435 "did": "MTZENTE5Qzc0Qzk0NkUxMzYxNzk0NjY4NTc3OTY4NTI=", 4436 } 4437 } 4438 } 4440 The TEE encrypts the "content" for the TAM. 4442 { 4443 "DeleteSDTBSResponse": { 4444 "ver": "1.0", 4445 "status": "pass", 4446 "rid": "{712551F5-DFB3-43f0-9A63-663440B91D49}", 4447 "tid": "{4F454A7F-002D-4157-884E-B0DD1A06A8AE}", 4448 "content": { 4449 "protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0K", 4450 "recipients": [ 4451 { 4452 "header": { 4453 "alg": "RSA1_5" 4454 }, 4455 "encrypted_key": 4456 " 4457 QUVTMTI4IChDRUspIGtleSwgZW5jcnlwdGVkIHdpdGggVFNNIFJTQSBwdWJsaWMg 4458 a2V5LCB1c2luZyBSU0ExXzUgcGFkZGluZw" 4459 } 4460 ], 4461 "iv": "ySGmfZ69YlcEilNr5_SGbA", 4462 "ciphertext": 4463 " 4464 c2FtcGxlIGRzaSBkYXRhIGVuY3J5cHRlZCB3aXRoIEFFUzEyOCBrZXkgZnJvbSByZW 4465 NpcGllbnRzLmVuY3J5cHRlZF9rZXk", 4466 "tag": "c2FtcGxlIGF1dGhlbnRpY2F0aW9uIHRhZw" 4467 } 4468 } 4469 } 4471 The TEE signs "DeleteSDTBSResponse" to form a "DeleteSDResponse" 4472 { 4473 "DeleteSDResponse": { 4474 "payload":" 4475 ewoJIkRlbGV0ZVNEVEJTUmVzcG9uc2UiOiB7CgkJInZlciI6ICIxLjAiLAoJCSJz 4476 dGF0dXMiOiAicGFzcyIsCgkJInJpZCI6ICJ7NzEyNTUxRjUtREZCMy00M2YwLTlB 4477 NjMtNjYzNDQwQjkxRDQ5fSIsCgkJInRpZCI6ICJ7NEY0NTRBN0YtMDAyRC00MTU3 4478 LTg4NEUtQjBERDFBMDZBOEFFfSIsCgkJImNvbnRlbnQiOiB7CgkJCSJwcm90ZWN0 4479 ZWQiOiAiZXlKbGJtTWlPaUpCTVRJNFEwSkRMVWhUTWpVMkluMEsiLAoJCQkicmVj 4480 aXBpZW50cyI6IFt7CgkJCQkiaGVhZGVyIjogewoJCQkJCSJhbGciOiAiUlNBMV81 4481 IgoJCQkJfSwKCQkJCSJlbmNyeXB0ZWRfa2V5IjogIlFVVlRNVEk0SUNoRFJVc3BJ 4482 R3RsZVN3Z1pXNWpjbmx3ZEdWa0lIZHBkR2dnVkZOTklGSlRRU0J3ZFdKc2FXTWdh 4483 MlY1TENCMWMybHVaeUJTVTBFeFh6VWdjR0ZrWkdsdVp3IgoJCQl9XSwKCQkJIml2 4484 IjogInlTR21mWjY5WWxjRWlsTnI1X1NHYkEiLAoJCQkiY2lwaGVydGV4dCI6ICJj 4485 MkZ0Y0d4bElHUnphU0JrWVhSaElHVnVZM0o1Y0hSbFpDQjNhWFJvSUVGRlV6RXlP 4486 Q0JyWlhrZ1puSnZiU0J5WldOcGNHbGxiblJ6TG1WdVkzSjVjSFJsWkY5clpYayIs 4487 CgkJCSJ0YWciOiAiYzJGdGNHeGxJR0YxZEdobGJuUnBZMkYwYVc5dUlIUmhadyIK 4488 CQl9Cgl9Cn0", 4489 "protected":"eyJhbGciOiJSUzI1NiJ9", 4490 "signature":"c2FtcGxlIHNpZ25hdHVyZQ" 4491 } 4492 } 4494 The TEE returns "DeleteSDResponse" back to the OTrP Agent, which 4495 returns the message back to the TAM. 4497 A.2. Sample TA Management Messages 4499 A.2.1. Sample InstallTA 4501 A.2.1.1. Sample InstallTARequest 4502 { 4503 "InstallTATBSRequest": { 4504 "ver": "1.0", 4505 "rid": "24BEB059-0AED-42A6-A381-817DFB7A1207", 4506 "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE", 4507 "tee": "Primary TEE ABC", 4508 "nextdsi": "true", 4509 "dsihash": 4510 " 4511 IsOvwpzDk8Onw4bCrsKTJsONwrbDrcKJYjVTw4vCu8OAw4JEw6zCgsK8w4JCacKxW8Kf 4512 w5o7", 4513 "content": { 4514 "tamid": "id1.TAMxyz.com", 4515 "spid": "com.acmebank.spid1", 4516 "sdname": "com.acmebank.sdname1", 4517 "taid": "com.acmebank.taid.banking" 4518 }, 4519 "encrypted_ta": { 4520 "key": 4521 "mLBjodcE4j36y64nC/nEs694P3XrLAOokjisXIGfs0H7lOEmT5FtaNDYEMcg9RnE 4522 ftlJGHO7N0lgcNcjoXBmeuY9VI8xzrsZM9gzH6VBKtVONSx0aw5IAFkNcyPZwDdZ 4523 MLwhvrzPJ9Fg+bZtrCoJz18PUz+5aNl/dj8+NM85LCXXcBlZF74btJer1Mw6ffzT 4524 /grPiEQTeJ1nEm9F3tyRsvcTInsnPJ3dEXv7sJXMrhRKAeZsqKzGX4eiZ3rEY+FQ 4525 6nXULC8cAj5XTKpQ/EkZ/iGgS0zcXR7KUJv3wFEmtBtPD/+ze08NILLmxM8olQFj 4526 //Lq0gGtq8vPC8r0oOfmbQ==", 4527 "iv": "4F5472504973426F726E496E32303135", 4528 "alg": "AESCBC", 4529 "ciphertadata": 4530 "......0x/5KGCXWfg1Vrjm7zPVZqtYZ2EovBow+7EmfOJ1tbk......=", 4531 "cipherpdata": "0x/5KGCXWfg1Vrjm7zPVZqtYZ2EovBow+7EmfOJ1tbk=" 4532 } 4533 } 4534 } 4536 A.2.1.2. Sample InstallTAResponse 4538 A sample to-be-signed response of InstallTA looks as follows. 4540 { 4541 "InstallTATBSResponse": { 4542 "ver": "1.0", 4543 "status": "pass", 4544 "rid": "24BEB059-0AED-42A6-A381-817DFB7A1207", 4545 "tid": "4F454A7F-002D-4157-884E-B0DD1A06A8AE", 4546 "content": { 4547 "did": "MTZENTE5Qzc0Qzk0NkUxMzYxNzk0NjY4NTc3OTY4NTI=", 4548 "dsi": { 4549 "tfwdata": { 4550 "tbs": "ezRGNDU0QTdGLTAwMkQtNDE1Ny04ODRFLUIwREQxQTA2QThBRX0=" 4551 "cert": "ZXhhbXBsZSBGVyBjZXJ0aWZpY2F0ZQ==", 4552 "sigalg": "UlMyNTY=", 4553 "sig": "c2FtcGxlIEZXIHNpZ25hdHVyZQ==" 4554 }, 4555 "tee": { 4556 "name": "Primary TEE", 4557 "ver": "1.0", 4558 "cert": "c2FtcGxlIFRFRSBjZXJ0aWZpY2F0ZQ==", 4559 "cacert": [ 4560 "c2FtcGxlIENBIGNlcnRpZmljYXRlIDE=", 4561 "c2FtcGxlIENBIGNlcnRpZmljYXRlIDI=" 4562 ], 4563 "sdlist": { 4564 "cnt": "1", 4565 "sd": [ 4566 { 4567 "name": "com.acmebank.sdname1", 4568 "spid": "com.acmebank.spid1", 4569 "talist": [ 4570 { 4571 "taid": "com.acmebank.taid.banking", 4572 "taname": "Acme secure banking app" 4573 }, 4574 { 4575 "taid": "acom.acmebank.taid.loyalty.rewards", 4576 "taname": "Acme loyalty rewards app" 4577 } 4578 ] 4579 } 4580 ] 4581 }, 4582 "teeaiklist": [ 4583 { 4584 "spaik": 4585 "c2FtcGxlIEFTTjEgZW5jb2RlZCBQS0NTMSBwdWJsaWNrZXk=", 4586 "spaiktype": "RSA" 4587 "spid": "acmebank.com" 4588 } 4589 ] 4590 } 4591 } 4592 } 4593 } 4594 } 4596 A.2.2. Sample UpdateTA 4598 A.2.2.1. Sample UpdateTARequest 4600 { 4601 "UpdateTATBSRequest": { 4602 "ver": "1.0", 4603 "rid": "req-2", 4604 "tid": "tran-01", 4605 "tee": "SecuriTEE", 4606 "nextdsi": " false", 4607 "dsihash": "gwjul_9MZks3pqUSN1-eL1aViwGXNAxk0AIKW79dn4U", 4608 "content": { 4609 "tamid": "TAM1.acme.com", 4610 "spid": "bank.com", 4611 "sdname": "sd.bank.com", 4612 "taid": "sd.bank.com.ta" 4613 }, 4614 "encrypted_ta": { 4615 "key": 4616 " 4617 XzmAn_RDVk3IozMwNWhiB6fmZlIs1YUvMKlQAv_UDoZ1fvGGsRGo9bT0A440aYMgLt 4618 GilKypoJjCgijdaHgamaJgRSc4Je2otpnEEagsahvDNoarMCC5nGQdkRxW7Vo2NKgL 4619 A892HGeHkJVshYm1cUlFQ-BhiJ4NAykFwlqC_oc", 4620 "iv": "AxY8DCtDaGlsbGljb3RoZQ", 4621 "alg": "AESCBC", 4622 "ciphernewtadata": 4623 "KHqOxGn7ib1F_14PG4_UX9DBjOcWkiAZhVE-U- 4624 67NsKryHGokeWr2spRWfdU2KWaaNncHoYGwEtbCH7XyNbOFh28nzwUmstep4nHWbAl 4625 XZYTNkENcABPpuw_G3I3HADo" 4626 } 4627 } 4628 } 4630 { 4631 "UpdateTARequest": { 4632 "payload" : 4633 " 4634 eyJVcGRhdGVUQVRCU1JlcXVlc3QiOnsidmVyIjoiMS4wIiwicmlkIjoicmVxLTIiLCJ0 4635 aWQiOiJ0cmFuLTAxIiwidGVlIjoiU2VjdXJpVEVFIiwibmV4dGRzaSI6ImZhbHNlIiwi 4636 ZHNpaGFzaCI6Imd3anVsXzlNWmtzM3BxVVNOMS1lTDFhVml3R1hOQXhrMEFJS1c3OWRu 4637 NFUiLCJjb250ZW50Ijp7InByb3RlY3RlZCI6ImV5SmxibU1pT2lKQk1USTRRMEpETFVo 4638 VE1qVTJJbjAiLCJyZWNpcGllbnRzIjpbeyJoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0s 4639 ImVuY3J5cHRlZF9rZXkiOiJYem1Bbl9SRFZrM0lvek13TldoaUI2Zm1abElzMVlVdk1L 4640 bFFBdl9VRG9aMWZ2R0dzUkdvOWJUMEE0NDBhWU1nTHRHaWxLeXBvSmpDZ2lqZGFIZ2Ft 4641 YUpnUlNjNEplMm90cG5FRWFnc2FodkROb2FyTUNDNW5HUWRrUnhXN1ZvMk5LZ0xBODky 4642 SEdlSGtKVnNoWW0xY1VsRlEtQmhpSjROQXlrRndscUNfb2MifV0sIml2IjoiQXhZOERD 4643 dERhR2xzYkdsamIzUm9aUSIsImNpcGhlcnRleHQiOiJIYTcwVXRZVEtWQmtXRFJuMi0w 4644 SF9IdkZtazl5SGtoVV91bk1OLWc1T3BqLWF1NGFUb2lxWklMYzVzYTdENnZZSjF6eW04 4645 QW1JOEJIVXFqc2l5Z0tOcC1HdURJUjFzRXc0a2NhMVQ5ZENuU0RydHhSUFhESVdrZmt3 4646 azZlR1NQWiIsInRhZyI6Im9UN01UTE41eWtBTFBoTDR0aUh6T1pPTGVFeU9xZ0NWaEM5 4647 MXpkcldMU0UifSwiZW5jcnlwdGVkX3RhIjp7ImtleSI6Ilh6bUFuX1JEVmszSW96TXdO 4648 V2hpQjZmbVpsSXMxWVV2TUtsUUF2X1VEb1oxZnZHR3NSR285YlQwQTQ0MGFZTWdMdEdp 4649 bEt5cG9KakNnaWpkYUhnYW1hSmdSU2M0SmUyb3RwbkVFYWdzYWh2RE5vYXJNQ0M1bkdR 4650 ZGtSeFc3Vm8yTktnTEE4OTJIR2VIa0pWc2hZbTFjVWxGUS1CaGlKNE5BeWtGd2xxQ19v 4651 YyIsIml2IjoiQXhZOERDdERhR2xzYkdsamIzUm9aUSIsImFsZyI6IkFFU0NCQyIsImNp 4652 cGhlcm5ld3RhZGF0YSI6IktIcU94R243aWIxRl8xNFBHNF9VWDlEQmpPY1draUFaaFZF 4653 LVUtNjdOc0tyeUhHb2tlV3Iyc3BSV2ZkVTJLV2FhTm5jSG9ZR3dFdGJDSDdYeU5iT0Zo 4654 MjhuendVbXN0ZXA0bkhXYkFsWFpZVE5rRU5jQUJQcHV3X0czSTNIQURvIn19fQ", 4655 "protected": " eyJhbGciOiJSUzI1NiJ9", 4656 "header": { 4657 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4658 "signer":" 4659 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA 4660 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4661 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh 4662 cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p 4663 YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy 4664 BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4665 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4666 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3 4667 c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4668 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA 4669 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4670 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR 4671 MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq 4672 hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G 4673 SZ1MdyIZV8fwdEmD90IvtMHgtzK- 4674 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA 4675 UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4676 }, 4677 "signature":"inB1K6G3EAhF- 4678 FbID83UI25R5Ao8MI4qfrbrmf0UQhjM3O7_g3l6XxN_JkHrGQaZr- 4679 myOkGPVM8BzbUZW5GqxNZwFXwMeaoCjDKc4Apv4WZkD1qKJxkg1k5jaUCfJz1Jmw_XtX 4680 6MHhrLh9ov03S9PtuT1VAQ0FVUB3qFIvjSnNU" 4681 } 4682 } 4684 A.2.2.2. Sample UpdateTAResponse 4685 { 4686 "UpdateTATBSResponse": { 4687 "ver": "1.0", 4688 "status": "pass", 4689 "rid": "req-2", 4690 "tid": "tran-01", 4691 "content": { 4692 "did": "zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM" 4693 } 4694 } 4695 } 4697 { 4698 "UpdateTAResponse":{ 4699 "payload":" 4700 eyJVcGRhdGVUQVRCU1Jlc3BvbnNlIjp7InZlciI6IjEuMCIsInN0YXR1cyI6InBhc3Mi 4701 LCJyaWQiOiJyZXEtMiIsInRpZCI6InRyYW4tMDEiLCJjb250ZW50Ijp7InByb3RlY3Rl 4702 ZCI6ImV5SmxibU1pT2lKQk1USTRRMEpETFVoVE1qVTJJbjAiLCJyZWNpcGllbnRzIjpb 4703 eyJoZWFkZXIiOnsiYWxnIjoiUlNBMV81In0sImVuY3J5cHRlZF9rZXkiOiJFaGUxLUJB 4704 UUdJLTNEMFNHdXFGY01MZDJtd0gxQm1uRndYQWx1M1FxUFVXZ1RRVm55SUowNFc2MnBK 4705 YWVSREFkeTU0R0FSVjBrVzQ0RGw0MkdUUlhqbE1EZ3BYdXdFLWloc1JVV0tNNldCZ2N3 4706 VXVGQTRUR3gwU0I1NTZCdl92dnBNaFdfMXh2c2FHdFBaQmwxTnZjbXNibzBhY3FobXlu 4707 bzBDTmF5SVAtX1UifV0sIml2IjoiQXhZOERDdERhR2xzYkdsamIzUm9aUSIsImNpcGhl 4708 cnRleHQiOiJwc2o2dGtyaGJXM0lmVElMeE9GMU5HdFUtcTFmeVBidV9KWk9jbklycWIw 4709 eTNPOHN6OTItaWpWR1ZyRW5WbG1sY1FYeWFNZTNyX1JGdEkwV3B4UmRodyIsInRhZyI6 4710 Ik0zb2dNNk11MVJYMUMybEZvaG5rTkN5b25qNjd2TDNqd2RrZXhFdUlpaTgifX19", 4711 "protected":"eyJhbGciOiJSUzI1NiJ9", 4712 "header": { 4713 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4714 "signer":" 4715 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA 4716 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4717 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh 4718 cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p 4719 YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy 4720 BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4721 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4722 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3 4723 c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4724 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA 4725 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4726 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR 4727 MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq 4728 hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G 4729 SZ1MdyIZV8fwdEmD90IvtMHgtzK- 4730 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA 4731 UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4732 }, 4733 "signature":" 4734 Twajmt_BBLIMcNrDsjqr8lI7O7lEQxXZNhlUOtFkOMMqf37wOPKtp_99LoS82CVmdpCo 4735 PLaws8zzh-SNIQ42- 4736 9GYO8_9BaEGCiCwyl8YgWP9fWNfNv2gR2fl2DK4uknkYu1EMBW4YfP81n_pGpb4Gm- 4737 nMk14grVZygwAPej3ZZk" 4738 } 4739 } 4740 A.2.3. Sample DeleteTA 4742 A.2.3.1. Sample DeleteTARequest 4744 { 4745 "DeleteTATBSRequest": { 4746 "ver": "1.0", 4747 "rid": "req-2", 4748 "tid": "tran-01", 4749 "tee": "SecuriTEE", 4750 "nextdsi": "false", 4751 "dsihash": "gwjul_9MZks3pqUSN1-eL1aViwGXNAxk0AIKW79dn4U", 4752 "content": { 4753 "tamid": "TAM1.acme.com", 4754 "sdname": "sd.bank.com", 4755 "taid": "sd.bank.com.ta" 4756 } 4757 } 4758 } 4760 { 4761 "DeleteTARequest": { 4762 "payload": 4763 " 4764 eyJEZWxldGVUQVRCU1JlcXVlc3QiOnsidmVyIjoiMS4wIiwicmlkIjoicmVxLTIiLCJ0 4765 aWQiOiJ0cmFuLTAxIiwidGVlIjoiU2VjdXJpVEVFIiwibmV4dGRzaSI6ImZhbHNlIiwi 4766 ZHNpaGFzaCI6Imd3anVsXzlNWmtzM3BxVVNOMS1lTDFhVml3R1hOQXhrMEFJS1c3OWRu 4767 NFUiLCJjb250ZW50Ijp7InByb3RlY3RlZCI6eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0s 4768 InJlY2lwaWVudHMiOlt7ImhlYWRlciI6eyJhbGciOiJSU0ExXzUifSwiZW5jcnlwdGVk 4769 X2tleSI6ImtyaGs0d2dpY0RlX3d0VXQyTW4tSUJsdUtvX0JkeXpNY2p1cVlBenBPYnRS 4770 TG9MZzQ0QkFLN2tRVWE1YTg0TEVJRGEzaHNtWDIxdldNZFJLczN4MTJsOUh5VFdfLUNS 4771 WmZtcUx2bEh1LV9MSVdvc1ZyRTZVMlJqUnRndllVOWliUkVLczkzRDRHWm4xVHFuZG9n 4772 d0tXRF9jdG1nWG1sbzZZVXpCWDZhR1dZMCJ9XSwiaXYiOiJBeFk4REN0RGFHbHNiR2xq 4773 YjNSb1pRIiwiY2lwaGVydGV4dCI6IkhhNzBVdFlUS1ZCa1dEUm4yLTBIX1BGa19yQnpQ 4774 dGJHdzhSNktlMXotdklNeFBSY0Nxa1puZmwyTjRjUTZPSTZCSHZJUUFoM2Jic0l0dHlR 4775 bXhDTE5Nbm8wejBrYm9TdkIyVXlxWExpeGVZIiwidGFnIjoidEtUbFRLdlR2LTRtVVlG 4776 Y1dYWnZMMVlhQnRGNloxVlNxOTMzVmI2UEpmcyJ9fX0", 4777 "protected" : "eyJhbGciOiJSUzI1NiJ9", 4778 "header": { 4779 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4780 "signer":" 4781 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBA 4782 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4783 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMTUwNzAyMDkwMTE4Wh 4784 cNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5p 4785 YTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0cy 4786 BQdHkgTHRkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4787 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4788 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA6b_ZI3 4789 c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4790 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJBgNVBA 4791 YTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxpZm9ybmlhMSEw 4792 HwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX9nxZBNQWDjAJBgNVHR 4793 MEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzANBgkq 4794 hkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4ivem4cIckfxzTBBiPHCjrrjB2X8Ktn8G 4795 SZ1MdyIZV8fwdEmD90IvtMHgtzK- 4796 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fVrJvnYA 4797 UBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4798 }, 4799 "signature" : 4800 " 4801 BZS0_Ab6pqvGNXe5lqT4Sc3jakyWQeiK9KlVSnimwWnjCCyMtyB9bwvlbILZba3IJiFe 4802 _3F9bIQpSytGS0f2TQrPTKC7pSjwDw-3kH7HkHcPPJd- 4803 PpMMfQvRx7AIV8vBqO9MijIC62iN0V2se5z2v8VFjGSoRGgq225w7FvrnWE" 4804 } 4805 } 4806 A.2.3.2. Sample DeleteTAResponse 4808 { 4809 "DeleteTATBSResponse": { 4810 "ver": "1.0", 4811 "status": "pass", 4812 "rid": "req-2", 4813 "tid": "tran-01", 4814 "content": { 4815 "did": "zAHkb0-SQh9U_OT8mR5dB-tygcqpUJ9_x07pIiw8WoM" 4816 } 4817 } 4818 } 4820 { 4821 "DeleteTAResponse":{ 4822 "payload":" 4823 ew0KCSJEZWxldGVUQVRCU1Jlc3BvbnNlIjogew0KCQkidmVyIjogIjEuMCIsDQoJCSJz 4824 dGF0dXMiOiAicGFzcyIsDQoJCSJyaWQiOiAicmVxLTIiLA0KCQkidGlkIjogInRyYW4t 4825 MDEiLA0KCQkiY29udGVudCI6IHsNCgkJCSJwcm90ZWN0ZWQiOnsiZW5jIjoiQTEyOENC 4826 Qy1IUzI1NiJ9LA0KCQkJInJlY2lwaWVudHMiOlsNCgkJCQl7DQoJCQkJCSJoZWFkZXIi 4827 OnsiYWxnIjoiUlNBMV81In0sDQoJCQkJCSJlbmNyeXB0ZWRfa2V5IjoiTXdtU1ZHaWU2 4828 eHpfQmxTaFlmTFRKRHhKT3oyNWhvYy1HZ2NEM2o5OWFyM2E4X2lYY182ZE44bFRTb1dD 4829 X19wZEFhaEMyWk5SakdIcTBCZ2JDYTRKalk0eXRkMVBVWDB6M1psbXl1YnRXM291eEpY 4830 el9PMzg1WGM4S3hySndjbElyZGx2WUY2OVZmeERLQkVzUHJCdzlVenVIa1VmSU4xWlFU 4831 bWZ0QmVaSlJnIg0KCQkJCX0NCgkJCV0sDQoJCQkiaXYiOiJBeFk4REN0RGFHbHNiR2xq 4832 YjNSb1pRIiwNCgkJCSJjaXBoZXJ0ZXh0IjoiamhQTlV5ZkFTel9rVV9GbEM2LUtCME01 4833 WDBHNE5MbHc0LWt0bERyajZTWlUteUp6eUFUbC1oY0ZBWWMwLXJMVEF4cF93N1d1WER0 4834 Y3N3SzJSSzRjcWciLA0KCQkJInRhZyI6IlBBeGo5N25oT29qVTNIREhxSll4MGZMNWpt 4835 b0xkTlJkTHRTAMIzUTdrYXciDQoJCX0NCgl9DQp9", 4836 "protected": "eyJhbGciOiJSUzI1NiJ9", 4837 "header": { 4838 "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d", 4839 "signer":" 4840 MIIC3zCCAkigAwIBAgIJAJf2fFkE1BYOMA0GCSqGSIb3DQEBBQUAMFoxCzAJ 4841 BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp 4842 Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcN 4843 MTUwNzAyMDkwMTE4WhcNMjAwNjMwMDkwMTE4WjBaMQswCQYDVQQGEwJVUzET 4844 MBEGA1UECAwKQ2FsaWZvcm5pYTETMBEGA1UEBwwKQ2FsaWZvcm5pYTEhMB8G 4845 A1UECgwYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIGfMA0GCSqGSIb3DQEB 4846 AQUAA4GNADCBiQKBgQC8ZtxM1bYickpgSVG- 4847 meHInI3f_chlMBdL8l7daOEztSs_a6GLqmvSu- 4848 AoDpTsfEd4EazdMBp5fmgLRGdCYMcI6bgpO94h5CCnlj8xFKPq7qGixdwGUA 4849 6b_ZI3c4cZ8eu73VMNrrn_z3WTZlExlpT9XVj- 4850 ivhfJ4a6T20EtMM5qwIDAQABo4GsMIGpMHQGA1UdIwRtMGuhXqRcMFoxCzAJ 4851 BgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRMwEQYDVQQHDApDYWxp 4852 Zm9ybmlhMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGSCCQCX 4853 9nxZBNQWDjAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwIGwDAWBgNVHSUBAf8E 4854 DDAKBggrBgEFBQcDAzANBgkqhkiG9w0BAQUFAAOBgQAGkz9QpoxghZUWT4iv 4855 em4cIckfxzTBBiPHCjrrjB2X8Ktn8GSZ1MdyIZV8fwdEmD90IvtMHgtzK- 4856 9wo6Aibj_rVIpxGb7trP82uzc2X8VwYnQbuqQyzofQvcwZHLYplvi95pZ5fV 4857 rJvnYAUBFyfrdT5GjqL1nqH3a_Y3QPscuCjg" 4858 }, 4859 "signature":" 4860 DfoBOetNelKsnAe_m4Z9K5UbihgWNYZsp5jVybiI05sOagDzv6R4do9npaAlAvpNK8HJ 4861 CxD6D22J8GDUExlIhSR1aDuDCQm6QzmjdkFdxAz5TRYl6zpPCZqgSToN_g1TZxqxEv6V 4862 Ob5fies4g6MHvCH-Il_-KbHq5YpwGxEEFdg" 4863 } 4864 } 4865 A.3. Example OTrP Agent Option 4867 The most popular TEE devices today are Android powered devices. In 4868 an Android device, an OTrP Agent can be a bound service with a 4869 service registration ID that a Client Application can use. This 4870 option allows a Client Application not to depend on any OTrP Agent 4871 SDK or provider. 4873 An OTrP Agent is responsible to detect and work with more than one 4874 TEE if a device has more than one. In this version, there is only 4875 one active TEE such that an OTrP Agent only needs to handle the 4876 active TEE. 4878 Appendix B. Contributors 4880 - Brian Witten 4881 Symantec 4882 brian_witten@symantec.com 4884 - Tyler Kim 4885 Solacia 4886 tylerkim@iotrust.kr 4888 Authors' Addresses 4890 Mingliang Pei 4891 Symantec 4892 350 Ellis St 4893 Mountain View, CA 94043 4894 USA 4896 Email: mingliang_pei@symantec.com 4898 Andrew Atyeo 4899 Intercede 4900 St. Mary's Road, Lutterworth 4901 Leicestershire, LE17 4PS 4902 Great Britain 4904 Email: andrew.atyeo@intercede.com 4905 Nick Cook 4906 ARM Ltd. 4907 110 Fulbourn Rd 4908 Cambridge, CB1 9NJ 4909 Great Britain 4911 Email: nicholas.cook@arm.com 4913 Minho Yoo 4914 Solacia 4915 5F, Daerung Post Tower 2, 306 Digital-ro 4916 Seoul 152-790 4917 Korea 4919 Email: paromix@gmail.com 4921 Hannes Tschofenig 4922 ARM Ltd. 4923 110 Fulbourn Rd 4924 Cambridge, CB1 9NJ 4925 Great Britain 4927 Email: Hannes.tschofenig@arm.com