idnits 2.17.1 draft-ietf-teep-architecture-03.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 : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 18 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 08, 2019) is 1753 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CA' is mentioned on line 1066, but not defined == Missing Reference: 'Soc' is mentioned on line 1068, but not defined == Missing Reference: 'OEM' is mentioned on line 1080, but not defined == Unused Reference: 'RFC6024' is defined on line 1634, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEEP M. Pei 3 Internet-Draft Symantec 4 Intended status: Informational H. Tschofenig 5 Expires: January 9, 2020 Arm Limited 6 D. Wheeler 7 Intel 8 A. Atyeo 9 Intercede 10 L. Dapeng 11 Alibaba Group 12 July 08, 2019 14 Trusted Execution Environment Provisioning (TEEP) Architecture 15 draft-ietf-teep-architecture-03 17 Abstract 19 A Trusted Execution Environment (TEE) is designed to provide a 20 hardware-isolation mechanism to separate a regular operating system 21 from security-sensitive application components. 23 This architecture document motivates the design and standardization 24 of a protocol for managing the lifecycle of trusted applications 25 running inside a TEE. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 9, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 4.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 4.2. Authentication . . . . . . . . . . . . . . . . . . . . . 9 79 4.3. Internet of Things . . . . . . . . . . . . . . . . . . . 9 80 4.4. Confidential Cloud Computing . . . . . . . . . . . . . . 9 81 5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9 82 5.1. System Components . . . . . . . . . . . . . . . . . . . . 9 83 5.2. Different Renditions of TEEP Architecture . . . . . . . . 12 84 5.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 14 85 5.4. Client Apps, Trusted Apps, and Personalization Data . . . 15 86 5.5. Examples of Application Delivery Mechanisms in Existing 87 TEEs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 5.6. TEEP Architectural Support for Client App, TA, and 89 Personalization Data Delivery . . . . . . . . . . . . . . 17 90 5.7. Entity Relations . . . . . . . . . . . . . . . . . . . . 17 91 5.8. Trust Anchors in TEE . . . . . . . . . . . . . . . . . . 20 92 5.9. Trust Anchors in TAM . . . . . . . . . . . . . . . . . . 20 93 5.10. Keys and Certificate Types . . . . . . . . . . . . . . . 21 94 5.11. Scalability . . . . . . . . . . . . . . . . . . . . . . . 23 95 5.12. Message Security . . . . . . . . . . . . . . . . . . . . 23 96 5.13. Security Domain . . . . . . . . . . . . . . . . . . . . . 23 97 5.14. A Sample Device Setup Flow . . . . . . . . . . . . . . . 23 98 6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 24 99 6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 25 100 6.2. TEEP Broker Implementation Consideration . . . . . . . . 25 101 6.2.1. TEEP Broker Distribution . . . . . . . . . . . . . . 26 102 6.2.2. Number of TEEP Brokers . . . . . . . . . . . . . . . 26 103 7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 26 104 7.1. Attestation Cryptographic Properties . . . . . . . . . . 28 105 7.2. TEEP Attestation Structure . . . . . . . . . . . . . . . 29 106 7.3. TEEP Attestation Claims . . . . . . . . . . . . . . . . . 31 107 7.4. TEEP Attestation Flow . . . . . . . . . . . . . . . . . . 31 108 7.5. Attestation Key Example . . . . . . . . . . . . . . . . . 31 109 7.5.1. Attestation Hierarchy Establishment: Manufacture . . 32 110 7.5.2. Attestation Hierarchy Establishment: Device Boot . . 32 111 7.5.3. Attestation Hierarchy Establishment: TAM . . . . . . 32 112 8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 32 113 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 114 9.1. TA Trust Check at TEE . . . . . . . . . . . . . . . . . . 33 115 9.2. One TA Multiple SP Case . . . . . . . . . . . . . . . . . 33 116 9.3. Broker Trust Model . . . . . . . . . . . . . . . . . . . 34 117 9.4. Data Protection at TAM and TEE . . . . . . . . . . . . . 34 118 9.5. Compromised CA . . . . . . . . . . . . . . . . . . . . . 34 119 9.6. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 34 120 9.7. Certificate Renewal . . . . . . . . . . . . . . . . . . . 34 121 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 122 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 123 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 124 12.1. Normative References . . . . . . . . . . . . . . . . . . 35 125 12.2. Informative References . . . . . . . . . . . . . . . . . 35 126 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 37 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 129 1. Introduction 131 Applications executing in a device are exposed to many different 132 attacks intended to compromise the execution of the application, or 133 reveal the data upon which those applications are operating. These 134 attacks increase with the number of other applications on the device, 135 with such other applications coming from potentially untrustworthy 136 sources. The potential for attacks further increase with the 137 complexity of features and applications on devices, and the 138 unintended interactions among those features and applications. The 139 danger of attacks on a system increases as the sensitivity of the 140 applications or data on the device increases. As an example, 141 exposure of emails from a mail client is likely to be of concern to 142 its owner, but a compromise of a banking application raises even 143 greater concerns. 145 The Trusted Execution Environment (TEE) concept is designed to 146 execute applications in a protected environment that separates 147 applications inside the TEE from the regular operating system and 148 from other applications on the device. This separation reduces the 149 possibility of a successful attack on application components and the 150 data contained inside the TEE. Typically, application components are 151 chosen to execute inside a TEE because those application components 152 perform security sensitive operations or operate on sensitive data. 153 An application component running inside a TEE is referred to as a 154 Trusted Application (TA), while a normal application running in the 155 regular operating system is referred to as an Untrusted Application 156 (UA). 158 The TEE uses hardware to enforce protections on the TA and its data, 159 but also presents a more limited set of services to applications 160 inside the TEE than is normally available to UA's running in the 161 normal operating system. 163 But not all TEEs are the same, and different vendors may have 164 different implementations of TEEs with different security properties, 165 different features, and different control mechanisms to operate on 166 TAs. Some vendors may themselves market multiple different TEEs with 167 different properties attuned to different markets. A device vendor 168 may integrate one or more TEEs into their devices depending on market 169 needs. 171 To simplify the life of developers and service providers interacting 172 with TAs in a TEE, an interoperable protocol for managing TAs running 173 in different TEEs of various devices is needed. In this TEE 174 ecosystem, there often arises a need for an external trusted party to 175 verify the identity, claims, and rights of Service Providers(SP), 176 devices, and their TEEs. This trusted third party is the Trusted 177 Application Manager (TAM). 179 This protocol addresses the following problems: 181 - A Service Provider (SP) intending to provide services through a TA 182 to users of a device needs to determine security-relevant 183 information of a device before provisioning their TA to the TEE 184 within the device. Examples include the verification of the 185 device 'root of trust' and the type of TEE included in a device. 187 - A TEE in a device needs to determine whether a Service Provider 188 (SP) that wants to manage a TA in the device is authorized to 189 manage TAs in the TEE, and what TAs the SP is permitted to manage. 191 - The parties involved in the protocol must be able to attest that a 192 TEE is genuine and capable of providing the security protections 193 required by a particular TA. 195 - A Service Provider (SP) must be able to determine if a TA exists 196 (is installed) on a device (in the TEE), and if not, install the 197 TA in the TEE. 199 - A Service Provider (SP) must be able to check whether a TA in a 200 device's TEE is the most up-to-date version, and if not, update 201 the TA in the TEE. 203 - A Service Provider (SP) must be able to remove a TA in a device's 204 TEE if the SP is no longer offering such services or the services 205 are being revoked from a particular user (or device). For 206 example, if a subscription or contract for a particular service 207 has expired, or a payment by the user has not been completed or 208 has been rescinded. 210 - A Service Provider (SP) must be able to define the relationship 211 between cooperating TAs under the SP's control, and specify 212 whether the TAs can communicate, share data, and/or share key 213 material. 215 2. Terminology 217 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 218 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 219 "OPTIONAL" in this document are to be interpreted as described in BCP 220 14 [RFC2119] [RFC8174] when, and only when, they appear in all 221 capitals, as shown here. 223 The following terms are used: 225 - Client Application: An application running in a Rich Execution 226 Environment, such as an Android, Windows, or iOS application. We 227 sometimes refer to this as the 'Client App'. 229 - Device: A physical piece of hardware that hosts a TEE along with a 230 Rich Execution Environment. A Device contains a default list of 231 Trust Anchors that identify entities (e.g., TAMs) that are trusted 232 by the Device. This list is normally set by the Device 233 Manufacturer, and may be governed by the Device's network carrier. 234 The list of Trust Anchors is normally modifiable by the Device's 235 owner or Device Administrator. However the Device manufacturer 236 and network carrier may restrict some modifications, for example, 237 by not allowing the manufacturer or carrier's Trust Anchor to be 238 removed or disabled. 240 - Rich Execution Environment (REE): An environment that is provided 241 and governed by a typical OS (e.g., Linux, Windows, Android, iOS), 242 potentially in conjunction with other supporting operating systems 243 and hypervisors; it is outside of the TEE. This environment and 244 applications running on it are considered un-trusted. 246 - Service Provider (SP): An entity that wishes to provide a service 247 on Devices that requires the use of one or more Trusted 248 Applications. A Service Provider requires the help of a TAM in 249 order to provision the Trusted Applications to remote devices. 251 - Device User: A human being that uses a device. Many devices have 252 a single device user. Some devices have a primary device user 253 with other human beings as secondary device users (e.g., parent 254 allowing children to use their tablet or laptop). Relates to 255 Device Owner and Device Administrator. 257 - Device Owner: A device is always owned by someone. It is common 258 for the (primary) device user to also own the device, making the 259 device user/owner also the device administrator. In enterprise 260 environments it is more common for the enterprise to own the 261 device, and device users have no or limited administration rights. 262 In this case, the enterprise appoints a device administrator that 263 is not the device owner. 265 - Device Administrator (DA): An entity that is responsible for 266 administration of a Device, which could be the device owner. A 267 Device Administrator has privileges on the Device to install and 268 remove applications and TAs, approve or reject Trust Anchors, and 269 approve or reject Service Providers, among possibly other 270 privileges on the Device. A Device Administrator can manage the 271 list of allowed TAMs by modifying the list of Trust Anchors on the 272 Device. Although a Device Administrator may have privileges and 273 Device-specific controls to locally administer a device, the 274 Device Administrator may choose to remotely administrate a device 275 through a TAM. 277 - Trust Anchor: A public key in a device whose corresponding private 278 key is held by an entity implicitly trusted by the device. The 279 Trust Anchor may be a certificate or it may be a raw public key 280 along with additional data if necessary such as its public key 281 algorithm and parameters. The Trust Anchor is normally stored in 282 a location that resists unauthorized modification, insertion, or 283 replacement. The digital fingerprint of a Trust Anchor may be 284 stored along with the Trust Anchor certificate or public key. A 285 device can use the fingerprint to uniquely identify a Trust 286 Anchor. The Trust Anchor private key owner can sign certificates 287 of other public keys, which conveys trust about those keys to the 288 device. A certificate signed by the Trust Anchor communicates 289 that the private key holder of the signed certificate is trusted 290 by the Trust Anchor holder, and can therefore be trusted by the 291 device. Trust Anchors in a device may be updated by an authorized 292 party when a Trust Anchor should be deprecated or a new Trust 293 Anchor should be added. 295 - Trusted Application (TA): An application component that runs in a 296 TEE. 298 - Trusted Execution Environment (TEE): An execution environment that 299 runs alongside of, but is isolated from, an REE. A TEE has 300 security capabilities and meets certain security-related 301 requirements. It protects TEE assets from general software 302 attacks, defines rigid safeguards as to data and functions that a 303 program can access, and resists a set of defined threats. It 304 should have at least the following three properties: 306 (a) A device unique credential that cannot be cloned; 308 (b) Assurance that only authorized code can run in the TEE; 310 (c) Memory that cannot be read by code outside the TEE. 312 There are multiple technologies that can be used to implement a 313 TEE, and the level of security achieved varies accordingly. 315 - Root-of-Trust (RoT): A hardware or software component in a device 316 that is inherently trusted to perform a certain security-critical 317 function. A RoT should be secure by design, small, and protected 318 by hardware against modification or interference. Examples of 319 RoTs include software/firmware measurement and verification using 320 a Trust Anchor (RoT for Verification), provide signed assertions 321 using a protected attestation key (RoT for Reporting), or protect 322 the storage and/or use of cryptographic keys (RoT for Storage). 323 Other RoTs are possible, including RoT for Integrity, and RoT for 324 Measurement. Reference: NIST SP800-164 (Draft). 326 - Trusted Firmware (TFW): A firmware in a device that can be 327 verified with a Trust Anchor by RoT for Verification. 329 - Bootloader key: This symmetric key is protected by 330 electronic fuse (eFUSE) technology. In this context it is used to 331 decrypt a 332 TFW private key, which belongs to a device-unique private/public 333 key pair. Not every device is equipped with a bootloader key. 335 This document uses the following abbreviations: 337 - CA: Certificate Authority 339 - REE: Rich Execution Environment 341 - RoT: Root of Trust 343 - SD: Security Domain 345 - SP: Service Provider 347 - TA: Trusted Application 349 - TAM: Trusted Application Manager 351 - TEE: Trusted Execution Environment 353 - TFW: Trusted Firmware 355 3. Assumptions 357 This specification assumes that an applicable device is equipped with 358 one or more TEEs and each TEE is pre-provisioned with a device-unique 359 public/private key pair, which is securely stored. 361 A TEE uses an isolation mechanism between Trusted Applications to 362 ensure that one TA cannot read, modify or delete the data and code of 363 another TA. 365 4. Use Cases 367 4.1. Payment 369 A payment application in a mobile device requires high security and 370 trust about the hosting device. Payments initiated from a mobile 371 device can use a Trusted Application to provide strong identification 372 and proof of transaction. 374 For a mobile payment application, some biometric identification 375 information could also be stored in a TEE. The mobile payment 376 application can use such information for authentication. 378 A secure user interface (UI) may be used in a mobile device to 379 prevent malicious software from stealing sensitive user input data. 380 Such an application implementation often relies on a TEE for user 381 input protection. 383 4.2. Authentication 385 For better security of authentication, a device may store its 386 sensitive authentication keys inside a TEE, providing hardware- 387 protected security key strength and trusted code execution. 389 4.3. Internet of Things 391 The Internet of Things (IoT) has been posing threats to networks and 392 national infrastructures because of existing weak security in 393 devices. It is very desirable that IoT devices can prevent malware 394 from manipulating actuators (e.g., unlocking a door), or stealing or 395 modifying sensitive data such as authentication credentials in the 396 device. A TEE can be the best way to implement such IoT security 397 functions. 399 TEEs could be used to store variety of sensitive data for IoT 400 devices. For example, a TEE could be used in smart door locks to 401 store a user's biometric information for identification, and for 402 protecting access the locking mechanism. 404 4.4. Confidential Cloud Computing 406 A tenant can store sensitive data in a TEE in a cloud computing 407 server such that only the tenant can access the data, preventing the 408 cloud hosting provider from accessing the data. A tenant can run TAs 409 inside a server TEE for secure operation and enhanced data security. 410 This provides benefits not only to tenants with better data security 411 but also to cloud hosting provider for reduced liability and 412 increased cloud adoption. 414 5. Architecture 416 5.1. System Components 418 The following are the main components in the system. Full 419 descriptions of components not previously defined are provided below. 420 Interactions of all components are further explained in the following 421 paragraphs. 423 +-------------------------------------------+ 424 | Device | 425 | +--------+ | Service Provider 426 | +-------------+ | |----------+ | 427 | | TEE-1 | | TEEP |---------+| | 428 | | +--------+ | +----| Broker | | || +--------+ | 429 | | | TEEP | | | | |<---+ | |+-->| |<-+ 430 | | | Agent |<----+ | | | | | +-| TAM-1 | 431 | | +--------+ | | |<-+ | | +->| | |<-+ 432 | | | +--------+ | | | | +--------+ | 433 | | +---+ +---+ | | | | | TAM-2 | | 434 | +-->|TA1| |TA2| | +-------+ | | | +--------+ | 435 | | | | | | |<---------| App-2 |--+ | | | 436 | | | +---+ +---+ | +-------+ | | | Device Administrator 437 | | +-------------+ | App-1 | | | | 438 | | | | | | | 439 | +--------------------| |---+ | | 440 | | |--------+ | 441 | +-------+ | 442 +-------------------------------------------+ 444 Figure 1: Notional Architecture of TEEP 446 - Service Providers (SP) and Device Administrators (DA) utilize the 447 services of a TAM to manage TAs on Devices. SPs do not directly 448 interact with devices. DAs may elect to use a TAM for remote 449 administration of TAs instead of managing each device directly. 451 - TAM: A TAM is responsible for performing lifecycle management 452 activity on TA's on behalf of Service Providers and Device 453 Administrators. This includes creation and deletion of TA's, and 454 may include, for example, over-the-air updates to keep an SP's TAs 455 up-to-date and clean up when a version should be removed. TAMs 456 may provide services that make it easier for SPs or DAs to use the 457 TAM's service to manage multiple devices, although that is not 458 required of a TAM. 460 The TAM performs its management of TA's through an interaction 461 with a Device's TEEP Broker. As shown in #notionalarch, the TAM 462 cannot directly contact a Device, but must wait for a the TEEP 463 Broker or a Client Application to contact the TAM requesting a 464 particular service. This architecture is intentional in order to 465 accommodate network and application firewalls that normally 466 protect user and enterprise devices from arbitrary connections 467 from external network entities. 469 A TAM may be publicly available for use by many SPs, or a TAM may 470 be private, and accessible by only one or a limited number of SPs. 472 It is expected that manufacturers and carriers will run their own 473 private TAM. Another example of a private TAM is a TAM running as 474 a Software-as-a-Service (SaaS) within an SP. 476 A SP or Device Administrator chooses a particular TAM based on 477 whether the TAM is trusted by a Device or set of Devices. The TAM 478 is trusted by a device if the TAM's public key is an authorized 479 Trust Anchor in the Device. A SP or Device Administrator may run 480 their own TAM, however the Devices they wish to manage must 481 include this TAM's pubic key in the Trust Anchor list. 483 A SP or Device Administrator is free to utilize multiple TAMs. 484 This may be required for a SP to manage multiple different types 485 of devices from different manufacturers, or devices on different 486 carriers, since the Trust Anchor list on these different devices 487 may contain different TAMs. A Device Administrator may be able to 488 add their own TAM's public key or certificate to the Trust Anchor 489 list on all their devices, overcoming this limitation. 491 Any entity is free to operate a TAM. For a TAM to be successful, 492 it must have its public key or certificate installed in Devices 493 Trust Anchor list. A TAM may set up a relationship with device 494 manufacturers or carriers to have them install the TAM's keys in 495 their device's Trust Anchor list. Alternatively, a TAM may 496 publish its certificate and allow Device Administrators to install 497 the TAM's certificate in their devices as an after-market-action. 499 - TEEP Broker: The TEEP Broker is an application running in a Rich 500 Execution Environment (REE) that enables the message protocol 501 exchange between a TAM and a TEE in a device. The TEEP Broker 502 does not process messages on behalf of a TEE, but merely is 503 responsible for relaying messages from the TAM to the TEE, and for 504 returning the TEE's responses to the TAM. 506 A Client Application is expected to communicate with a TAM to 507 request TAs that it needs to use. The Client Application needs to 508 pass the messages from the TAM to TEEs in the device. This calls 509 for a component in the REE that Client Applications can use to 510 pass messages to TEEs. The TEEP Broker is thus an application in 511 the REE or software library that can relay messages from a Client 512 Application to a TEE in the device. A device usually comes with 513 only one active TEE. A TEE may provide such a Broker to the 514 device manufacturer to be bundled in devices. Such a TEE must 515 also include a Broker counterpart, namely, a TEEP Agent inside the 516 TEE, to parse TAM messages sent through the Broker. A TEEP Broker 517 is generally acting as a dummy relaying box with just the TEE 518 interacting capability; it doesn't need and shouldn't parse 519 protocol messages. 521 - TEEP Agent: the TEEP Agent is a processing module running inside a 522 TEE that receives TAM requests that are relayed via a TEEP Broker 523 that runs in an REE. A TEEP Agent in the TEE may parse requests 524 or forward requests to other processing modules in a TEE, which is 525 up to a TEE provider's implementation. A response message 526 corresponding to a TAM request is sent by a TEEP Agent back to a 527 TEEP Broker. 529 - Certification Authority (CA): Certificate-based credentials used 530 for authenticating a device, a TAM and an SP. A device embeds a 531 list of root certificates (Trust Anchors), from trusted CAs that a 532 TAM will be validated against. A TAM will remotely attest a 533 device by checking whether a device comes with a certificate from 534 a CA that the TAM trusts. The CAs do not need to be the same; 535 different CAs can be chosen by each TAM, and different device CAs 536 can be used by different device manufacturers. 538 5.2. Different Renditions of TEEP Architecture 540 There is nothing prohibiting a device from implementing multiple 541 TEEs. In addition, some TEEs (for example, SGX) present themselves 542 as separate containers within memory without a controlling manager 543 within the TEE. In these cases, the rich operating system hosts 544 multiple TEEP brokers, where each broker manages a particular TEE or 545 set of TEEs. Enumeration and access to the appropriate broker is up 546 to the rich OS and the applications. Verification that the correct 547 TA has been reached then becomes a matter of properly verifying TA 548 attestations, which are unforgeable. The multiple TEE approach is 549 shown in the diagram below. For brevity, TEEP Broker 2 is shown 550 interacting with only one TAM and UA, but no such limitation is 551 intended to be implied in the architecture. 553 +-------------------------------------------+ 554 | Device | 555 | +--------+ | Service Provider 556 | | |----------+ | 557 | +-------------+ | TEEP |---------+| | 558 | | TEE-1 | +---| Broker | | || +--------+ | 559 | | | | | 1 |<---+ | |+-->| |<-+ 560 | | +-------+ | | | | | | | | | 561 | | | TEEP | | | | | | | | | | 562 | | | Agent |<------+ | | | | | | | 563 | | | 1 | | | | | | | | | 564 | | +-------+ | | | | | | | | 565 | | | | | | | | | | 566 | | +---+ +---+ | | | | | | +-| TAM-1 | 567 | | |TA1| |TA2| | | |<-+ | | +->| | |<-+ 568 | +-->| | | |<---+ +--------+ | | | | +--------+ | 569 | | | +---+ +---+ | | | | | | TAM-2 | | 570 | | | | | +-------+ | | | +--------+ | 571 | | +-------------+ +-----| App-2 |--+ | | ^ | 572 | | +-------+ | | | | Device 573 | +--------------------| App-1 | | | | | Administrator 574 | +------| | | | | | 575 | +-----------|-+ | |---+ | | | 576 | | TEE-2 | | | |--------+ | | 577 | | +------+ | | | |------+ | | 578 | | | TEEP | | | +-------+ | | | 579 | | | Agent|<-----+ | | | 580 | | | 2 | | | | | | | 581 | | +------+ | | | | | | 582 | | | | | | | | 583 | | +---+ | | | | | | 584 | | |TA3|<----+ | | +----------+ | | | 585 | | | | | | | TEEP |<--+ | | 586 | | +---+ | +--| Broker |----------------+ 587 | | | | 2 | | 588 | +-------------+ +----------+ | 589 | | 590 +-------------------------------------------+ 592 Figure 2: Notional Architecture of TEEP wtih multiple TEEs 594 In the diagram above, TEEP Broker 1 controls interactions with the 595 TA's in TEE-1, and TEEP Broker 2 controls interactions with the TA's 596 in TEE-2. This presents some challenges for a TAM in completely 597 managing the device, since a TAM may not interact with all the TEEP 598 Brokers on a particular platform. In addition, since TEE's may be 599 physically separated, with wholly different resources, there may be 600 no need for TEEP Brokers to share information on installed TAs or 601 resource usage. However, the architecture guarantees that the TAM 602 will receive all the relevant information from the TEEP Broker to 603 which it communicates. 605 5.3. Multiple TAMs and Relationship to TAs 607 As shown in Figure 2, the TEEP Broker provides connections from the 608 TEE and the Client App to one or more TAMs. The selection of which 609 TAM to communicate with is dependent on information from the Client 610 App and is directly related to the TA. 612 When a SP offers a service which requires a TA, the SP associates 613 that service with a specific TA. The TA itself is digitally signed, 614 protecting its integrity, but the signature also links the TA back to 615 the signer. The signer is usually the SP, but in some cases may be 616 another party that the SP trusts. The SP selects one or more TAMs 617 through which to offer their service, and communicates the 618 information of the service and the specific client apps and TAs to 619 the TAM. 621 The SP chooses TAMs based upon the markets into which the TAM can 622 provide access. There may be TAMs that provide services to specific 623 types of mobile devices, or mobile device operating systems, or 624 specific geographical regions or network carriers. A SP may be 625 motivated to utilize multiple TAMs for its service in order to 626 maximize market penetration and availability on multiple types of 627 devices. This likely means that the same service will be available 628 through multiple TAMs. 630 When the SP publishes the Client App to an app store or other app 631 repositories, the SP binds the Client App with a manifest that 632 identifies what TAMs can be contacted for the TA. In some 633 situations, an SP may use only a single TAM - this is likely the case 634 for enterprise applications or SPs serving a closed community. For 635 broad public apps, there will likely be multiple TAMs in the manifest 636 - one servicing one brand of mobile device and another servicing a 637 different manufacturer, etc. Because different devices and different 638 manufacturers trust different TAMs, the manifest will include 639 different TAMs that support this SP's client app and TA. Multiple 640 TAMs allow the SP to provide thier service and this app (and TA) to 641 multiple different devices. 643 When the TEEP Broker receives a request to contact the TAM for a 644 Client App in order to install a TA, a list of TAMs may be provided. 645 The TEEP Broker selects a single TAM that is consistent with the list 646 of trusted TAMs (trust anchors) provisioned on the device. For any 647 client app, there should be only a single TAM for the TEEP Broker to 648 contact. This is also the case when a Client App uses multiple TAs, 649 or when one TA depends on anther TA in a software dependency (see 650 section TBD). The reason is that the SP should provide each TAM that 651 it places in the Client App's manifest all the TAs that the app 652 requires. There is no benefit to going to multiple different TAMs, 653 and there is no need for a special TAM to be contacted for a specific 654 TA. 656 [Note: This should always be the case. When a particular device or 657 TEE supports only a special proprietary attestation mechanism, then a 658 specific TAM will be needed that supports that attestation scheme. 659 The TAM should also support standard atttestation signatures as well. 660 It is highly unlikely that a set of TAs would use different 661 proprietary attestation mechanisms since a TEE is likley to support 662 only one such proprietary scheme.] 664 [Note: This situation gets more complex in situations where a Client 665 App expects another application or a device to already have a 666 specific TA installed. This situation does not occur with SGX, but 667 could occur in situations where the secure world maintains an trusted 668 operating system and runs an entire trusted system with multiple TAs 669 running. This requires more discussion.] 671 5.4. Client Apps, Trusted Apps, and Personalization Data 673 In TEEP, there is an explicit relationship and dependence between the 674 client app in the REE and one or more TAs in the TEE, as shown in 675 Figure 2. From the perspective of a device user, a client app that 676 uses one or more TA's in a TEE appears no different from any other 677 untrusted application in the REE. However, the way the client app 678 and its corresponding TA's are packaged, delivered, and installed on 679 the device can vary. The variations depend on whether the client app 680 and TA are bundled together or are provided separately, and this has 681 implications to the management of the TAs in the TEE. In addition to 682 the client app and TA, the TA and/or TEE may require some additional 683 data to personalize the TA to the service provider or the device 684 user. This personalization data is dependent on the TEE, the TA and 685 the SP; an example of personalization data might be username and 686 password of the device user's account with the SP, or a secret 687 symmetric key used to by the TA to communicate with the SP. The 688 personalization data must be encrypted to preserve the 689 confidentiality of potentially sensitive data contained within it. 690 Other than this requirement to support confidentiality, TEEP place no 691 limitations or requirements on the personalization data. 693 There are three possible cases for bundling of the Client App, TA, 694 and personalization data: 696 1. The Client App, TA, and personalization data are all bundled 697 together in a single package by the SP and provided to the TEEP 698 Broker through the TAM. 700 2. The Client App and the TA are bundled together in a single 701 binary, which the TAM or a publicly accessible app store 702 maintains in repository, and the personalization data is 703 separately provided by the SP. In this case, the personalization 704 data is collected by the TAM and included in the InstallTA 705 message to the TEEP Broker. 707 3. All components are independent. The device user installs the 708 Client App through some independent or device-specific mechanism, 709 and the TAM provides the TA and personalization data from the SP. 710 Delivery of the TA and personalization data may be combined or 711 separate. 713 5.5. Examples of Application Delivery Mechanisms in Existing TEEs 715 In order to better understand these cases, it is helpful to review 716 actual implementations of TEEs and their application delivery 717 mechanisms. 719 In Intel Software Guard Extensions (SGX), the Client App and TA are 720 typically bound into the same binary (Case 2). The TA is compiled 721 into the Client App binary using SGX tools, and exists in the binary 722 as a shared library (.so or .dll). The Client App loads the TA into 723 an SGX enclave when the client needs the TA. This organization makes 724 it easy to maintain compatibility between the Client App and the TA, 725 since they are updated together. It is entirely possible to create a 726 Client App that loads an external TA into an SGX enclave and use that 727 TA (Case 3). In this case, the Client App would require a reference 728 to an external file or download such a file dynamically, place the 729 contents of the file into memory, and load that as a TA. Obviously, 730 such file or downloaded content must be properly formatted and signed 731 for it to be accepted by the SGX TEE. In SGX, for Case 2 and Case 3, 732 the personalization data is normally loaded into the SGX enclave (the 733 TA) after the TA has started. Although Case 1 is possible with SGX, 734 there are no instances of this known to be in use at this time, since 735 such a construction would required a special installation program and 736 SGX TA to recieve the encrypted binary, decrypt it, separate it into 737 the three different elements, and then install all three. This 738 installation is complex, because the Client App decrypted inside the 739 TEE must be passed out of the TEE to an installer in the REE which 740 would install the Client App; this assumes that the Client App binary 741 includes the TA code also, otherwise there is a significant problem 742 in getting the SGX encalve code (the TA) from the TEE, through the 743 installer and into the Client App in a trusted fashion. Finally, the 744 personalization data would need to be sent out of the TEE (encrypted 745 in an SGX encalve-to-enclave manner) to the REE's installation app, 746 which would pass this data to the installed Client App, which would 747 in turn send this data to the SGX enclave (TA). This complexity is 748 due to the fact that each SGX enclave is separate and does not have 749 direct communication to one another. 751 [NOTE: Need to add an equivalent discussion for an ARM/TZ 752 implementation] 754 5.6. TEEP Architectural Support for Client App, TA, and Personalization 755 Data Delivery 757 This section defines TEEP support for the three different cases for 758 delivery of the Client App, TA, and personalization data. 760 [Note: discussion of format of this single binary, and who/what is 761 responsible for splitting these things apart, and installing the 762 client app into the REE, the TA into the TEE, and the personalization 763 data into the TEE or TA. Obviously the decryption must be done by 764 the TEE but this may not be supported by all TAs.] 766 5.7. Entity Relations 768 This architecture leverages asymmetric cryptography to authenticate a 769 device to a TAM. Additionally, a TEE in a device authenticates a TAM 770 and TA signer. The provisioning of Trust Anchors to a device may 771 different from one use case to the other. A device administrator may 772 want to have the capability to control what TAs are allowed. A 773 device manufacturer enables verification of the TA signers and TAM 774 providers; it may embed a list of default Trust Anchors that the 775 signer of an allowed TA's signer certificate should chain to. A 776 device administrator may choose to accept a subset of the allowed TAs 777 via consent or action of downloading. 779 PKI CA -- CA CA -- 780 | | | 781 | | | 782 | | | 783 Device | | --- Agent / Client App --- | 784 SW | | | | | 785 | | | | | 786 | | | | | 787 | -- TEE TAM------- 788 | 789 | 790 FW 792 Figure 3: Entities 794 (App Developer) (App Store) (TAM) (Device with TEE) (CAs) 795 | | 796 | --> (Embedded TEE cert) <-- 797 | | 798 | <------------------------------ Get an app cert ----- | 799 | | <-- Get a TAM cert ------ | 800 | 801 1. Build two apps: 802 Client App 803 TA 804 | 805 | 806 Client App -- 2a. --> | ----- 3. Install -------> | 807 TA ------- 2b. Supply ------> | 4. Messaging-->| 808 | | | | 810 Figure 4: Developer Experience 812 Figure 4 shows an application developer building two applications: 1) 813 a rich Client Application; 2) a TA that provides some security 814 functions to be run inside a TEE. At step 2, the application 815 developer uploads the Client Application (2a) to an Application 816 Store. The Client Application may optionally bundle the TA binary. 817 Meanwhile, the application developer may provide its TA to a TAM 818 provider that will be managing the TA in various devices. 3. A user 819 will go to an Application Store to download the Client Application. 820 The Client Application will trigger TA installation by initiating 821 communication with a TAM. This is the step 4. The Client 822 Application will get messages from TAM, and interacts with device TEE 823 via an Agent. 825 The following diagram shows a system diagram about the entity 826 relationships between CAs, TAMs, SPs and devices. 828 ------- Message Protocol ----- 829 | | 830 | | 831 -------------------- --------------- ---------- 832 | REE | TEE | | TAM | | SP | 833 | --- | --- | | --- | | -- | 834 | | | | | | | 835 | Client | TEEP | | TA | | TA | 836 | Apps | Agent | | Mgmt | | | 837 | | | | | | | | 838 | | | TAs | | | | | 839 | TEEP | | | | | | 840 | Broker | List of | | List of | | | 841 | | Trusted | | Trusted | | | 842 | | TAM/SP | | FW/TEE | | | 843 | | CAs | | CAs | | | 844 | | | | | | | 845 | |TEE Key/ | | TAM Key/ | |SP Key/ | 846 | | Cert | | Cert | | Cert | 847 | | FW Key/ | | | | | 848 | | Cert | | | | | 849 -------------------- --------------- ---------- 850 | | | 851 | | | 852 ------------- ---------- --------- 853 | TEE CA | | TAM CA | | SP CA | 854 ------------- ---------- --------- 856 Figure 5: Keys 858 In the previous diagram, different CAs can be used for different 859 types of certificates. Messages are always signed, where the signer 860 key is the message originator's private key such as that of a TAM, 861 the private key of trusted firmware (TFW), or a TEE's private key. 863 The main components consist of a set of standard messages created by 864 a TAM to deliver TA management commands to a device, and device 865 attestation and response messages created by a TEE that responds to a 866 TAM's message. 868 It should be noted that network communication capability is generally 869 not available in TAs in today's TEE-powered devices. The networking 870 functionality must be delegated to a rich Client Application. Client 871 Applications will need to rely on an agent in the REE to interact 872 with a TEE for message exchanges. Consequently, a TAM generally 873 communicates with a Client Application about how it gets messages 874 that originate from a TEE inside a device. Similarly, a TA or TEE 875 generally gets messages from a TAM via some Client Application, 876 namely, a TEEP Broker in this protocol architecture, not directly 877 from the network. 879 It is imperative to have an interoperable protocol to communicate 880 with different TAMs and different TEEs in different devices. This is 881 the role of the Broker, which is a software component that bridges 882 communication between a TAM and a TEE. Furthermore the Broker 883 communicates with a Agent inside a TEE that is responsible to process 884 TAM requests. The Broker in REE does not need to know the actual 885 content of messages except for the TEE routing information. 887 5.8. Trust Anchors in TEE 889 Each TEE comes with a trust store that contains a whitelist of Trust 890 Anchors that are used to validate a TAM's certificate. A TEE will 891 accept a TAM to create new Security Domains and install new TAs on 892 behalf of an SP only if the TAM's certificate is chained to one of 893 the root CA certificates in the TEE's trust store. 895 A TEE's trust store is typically preloaded at manufacturing time. It 896 is out of the scope in this document to specify how the trust anchors 897 should be updated when a new root certificate should be added or 898 existing one should be updated or removed. A device manufacturer is 899 expected to provide its TEE trust anchors live update or out-of-band 900 update to Device Administrators. 902 When trust anchor update is carried out, it is imperative that any 903 update must maintain integrity where only authentic trust anchor list 904 from a device manufacturer or a Device Administrator is accepted. 905 This calls for a complete lifecycle flow in authorizing who can make 906 trust anchor update and whether a given trust anchor list are non- 907 tampered from the original provider. The signing of a trust anchor 908 list for integrity check and update authorization methods are 909 desirable to be developed. This can be addressed outside of this 910 architecture document. 912 Before a TAM can begin operation in the marketplace to support a 913 device with a particular TEE, it must obtain a TAM certificate from a 914 CA that is listed in the trust store of the TEE. 916 5.9. Trust Anchors in TAM 918 The Trust Anchor store in a TAM consists of a list of CA certificates 919 that sign various device TEE certificates. A TAM will accept a 920 device for TA management if the TEE in the device uses a TEE 921 certificate that is chained to a CA that the TAM trusts. 923 5.10. Keys and Certificate Types 925 This architecture leverages the following credentials, which allow 926 delivering end-to-end security without relying on any transport 927 security. 929 +-------------+----------+--------+-------------------+-------------+ 930 | Key Entity | Location | Issuer | Checked Against | Cardinality | 931 | Name | | | | | 932 +-------------+----------+--------+-------------------+-------------+ 933 | 1. TFW key | Device | FW CA | A whitelist of | 1 per | 934 | pair and | secure | | FW root CA | device | 935 | certificate | storage | | trusted by TAMs | | 936 | | | | | | 937 | 2. TEE key | Device | TEE CA | A whitelist of | 1 per | 938 | pair and | TEE | under | TEE root CA | device | 939 | certificate | | a root | trusted by TAMs | | 940 | | | CA | | | 941 | | | | | | 942 | 3. TAM key | TAM | TAM CA | A whitelist of | 1 or | 943 | pair and | provider | under | TAM root CA | multiple | 944 | certificate | | a root | embedded in TEE | can be used | 945 | | | CA | | by a TAM | 946 | | | | | | 947 | 4. SP key | SP | SP | A SP uses a TAM. | 1 or | 948 | pair and | | signer | TA is signed by a | multiple | 949 | certificate | | CA | SP signer. TEE | can be used | 950 | | | | delegates trust | by a TAM | 951 | | | | of TA to TAM. SP | | 952 | | | | signer is | | 953 | | | | associated with a | | 954 | | | | TA as the owner. | | 955 +-------------+----------+--------+-------------------+-------------+ 957 Figure 6: Key and Certificate Types 959 1. TFW key pair and certificate: A key pair and certificate for 960 evidence of trustworthy firmware in a device. This key pair is 961 optional for TEEP architecture. Some TEE may present its trusted 962 attributes to a TAM using signed attestation with a TFW key. For 963 example, a platform that uses a hardware based TEE can have 964 attestation data signed by a hardware protected TFW key. 966 o Location: Device secure storage 968 o Supported Key Type: RSA and ECC 970 o Issuer: OEM CA 971 o Checked Against: A whitelist of FW root CA trusted by TAMs 973 o Cardinality: One per device 975 2. TEE key pair and certificate: It is used for device attestation 976 to a remote TAM and SP. 978 o This key pair is burned into the device by the device 979 manufacturer. The key pair and its certificate are valid for 980 the expected lifetime of the device. 982 o Location: Device TEE 984 o Supported Key Type: RSA and ECC 986 o Issuer: A CA that chains to a TEE root CA 988 o Checked Against: A whitelist of TEE root CAs trusted by TAMs 990 o Cardinality: One per device 992 3. TAM key pair and certificate: A TAM provider acquires a 993 certificate from a CA that a TEE trusts. 995 o Location: TAM provider 997 o Supported Key Type: RSA and ECC. 999 o Supported Key Size: RSA 2048-bit, ECC P-256 and P-384. Other 1000 sizes should be anticipated in future. 1002 o Issuer: TAM CA that chains to a root CA 1004 o Checked Against: A whitelist of TAM root CAs embedded in a TEE 1006 o Cardinality: One or multiple can be used by a TAM 1008 4. SP key pair and certificate: An SP uses its own key pair and 1009 certificate to sign a TA. 1011 o Location: SP 1013 o Supported Key Type: RSA and ECC 1015 o Supported Key Size: RSA 2048-bit, ECC P-256 and P-384. Other 1016 sizes should be anticipated in future. 1018 o Issuer: An SP signer CA that chains to a root CA 1019 o Checked Against: An SP uses a TAM. A TEE trusts an SP by 1020 validating trust against a TAM that the SP uses. A TEE trusts 1021 a TAM to ensure that a TA is trustworthy. 1023 o Cardinality: One or multiple can be used by an SP 1025 5.11. Scalability 1027 This architecture uses a PKI. Trust Anchors exist on the devices to 1028 enable the TEE to authenticate TAMs, and TAMs use Trust Anchors to 1029 authenticate TEEs. Since a PKI is used, many intermediate CA 1030 certificates can chain to a root certificate, each of which can issue 1031 many certificates. This makes the protocol highly scalable. New 1032 factories that produce TEEs can join the ecosystem. In this case, 1033 such a factory can get an intermediate CA certificate from one of the 1034 existing roots without requiring that TAMs are updated with 1035 information about the new device factory. Likewise, new TAMs can 1036 join the ecosystem, providing they are issued a TAM certificate that 1037 chains to an existing root whereby existing TEEs will be allowed to 1038 be personalized by the TAM without requiring changes to the TEE 1039 itself. This enables the ecosystem to scale, and avoids the need for 1040 centralized databases of all TEEs produced or all TAMs that exist. 1042 5.12. Message Security 1044 Messages created by a TAM are used to deliver TA management commands 1045 to a device, and device attestation and messages created by the 1046 device TEE to respond to TAM messages. 1048 These messages are signed end-to-end and are typically encrypted such 1049 that only the targeted device TEE or TAM is able to decrypt and view 1050 the actual content. 1052 5.13. Security Domain 1054 No security domain (SD) is explicitly assumed in a TEE for TA 1055 management. Some TEE, for example, some TEE compliant with Global 1056 Platform (GP), may continue to choose to use SD to organize resource 1057 partition and security boundaries. It is up to a TEE implementation 1058 to decide how a SD is attached to a TA installation, for example, one 1059 SD could be created per TA. 1061 5.14. A Sample Device Setup Flow 1063 Step 1: Prepare Images for Devices 1065 1. [TEE vendor] Deliver TEE Image (CODE Binary) to device OEM 1066 2. [CA] Deliver root CA Whitelist 1068 3. [Soc] Deliver TFW Image 1070 Step 2: Inject Key Pairs and Images to Devices 1072 1. [OEM] Generate TFW Key Pair (May be shared among multiple 1073 devices) 1075 2. [OEM] Flash signed TFW Image and signed TEE Image onto devices 1076 (signed by TFW Key) 1078 Step 3: Set up attestation key pairs in devices 1080 1. [OEM] Flash TFW Public Key and a bootloader key. 1082 2. [TFW/TEE] Generate a unique attestation key pair and get a 1083 certificate for the device. 1085 Step 4: Set up Trust Anchors in devices 1087 1. [TFW/TEE] Store the key and certificate encrypted with the 1088 bootloader key 1090 2. [TEE vendor or OEM] Store trusted CA certificate list into 1091 devices 1093 6. TEEP Broker 1095 A TEE and TAs do not generally have the capability to communicate to 1096 the outside of the hosting device. For example, GlobalPlatform 1097 [GPTEE] specifies one such architecture. This calls for a software 1098 module in the REE world to handle the network communication. Each 1099 Client Application in the REE might carry this communication 1100 functionality but such functionality must also interact with the TEE 1101 for the message exchange. 1102 The TEE interaction will vary according to different TEEs. In order 1103 for a Client Application to transparently support different TEEs, it 1104 is imperative to have a common interface for a Client Application to 1105 invoke for exchanging messages with TEEs. 1107 A shared module in REE comes to meet this need. A TEEP broker is an 1108 application running in the REE of the device or an SDK that 1109 facilitates communication between a TAM and a TEE. It also provides 1110 interfaces for Client Applications to query and trigger TA 1111 installation that the application needs to use. 1113 It isn't always that a Client Application directly calls such a 1114 Broker to interact with a TEE. A REE Application Installer might 1115 carry out TEE and TAM interaction to install all required TAs that a 1116 Client Application depends. A Client Application may have a metadata 1117 file that describes the TAs it depends on and the associated TAM that 1118 each TA installation goes to use. The REE Application Installer can 1119 inspect the application metadata file and installs TAs on behalf of 1120 the Client Application without requiring the Client Application to 1121 run first. 1123 This interface for Client Applications or Application Installers may 1124 be commonly in a form of an OS service call for an REE OS. A Client 1125 Application or an Application Installer interacts with the device TEE 1126 and the TAMs. 1128 6.1. Role of the TEEP Broker 1130 A TEEP Broker abstracts the message exchanges with a TEE in a device. 1131 The input data is originated from a TAM or the first initialization 1132 call to trigger a TA installation. 1134 The Broker doesn't need to parse a message content received from a 1135 TAM that should be processed by a TEE. When a device has more than 1136 one TEE, one TEEP Broker per TEE could be present in REE. A TEEP 1137 Broker interacts with a TEEP Agent inside a TEE. 1139 A TAM message may indicate the target TEE where a TA should be 1140 installed. A compliant TEEP protocol should include a target TEE 1141 identifier for a TEEP Broker when multiple TEEs are present. 1143 The Broker relays the response messages generated from a TEEP Agent 1144 in a TEE to the TAM. The Broker is not expected to handle any 1145 network connection with an application or TAM. 1147 The Broker only needs to return an error message if the TEE is not 1148 reachable for some reason. Other errors are represented as response 1149 messages returned from the TEE which will then be passed to the TAM. 1151 6.2. TEEP Broker Implementation Consideration 1153 A Provider should consider methods of distribution, scope and 1154 concurrency on devices and runtime options when implementing a TEEP 1155 Broker. Several non-exhaustive options are discussed below. 1156 Providers are encouraged to take advantage of the latest 1157 communication and platform capabilities to offer the best user 1158 experience. 1160 6.2.1. TEEP Broker Distribution 1162 The Broker installation is commonly carried out at OEM time. A user 1163 can dynamically download and install a Broker on-demand. 1165 6.2.2. Number of TEEP Brokers 1167 There should be generally only one shared TEEP Broker in a device. 1168 The device's TEE vendor will most probably supply one Broker. When 1169 multiple TEEs are present in a device, one TEEP Broker per TEE may be 1170 used. 1172 When only one Broker is used per device, the Broker provider is 1173 responsible to allow multiple TAMs and TEE providers to achieve 1174 interoperability. With a standard Broker interface, each TAM can 1175 implement its own SDK for its SP Client Applications to work with 1176 this Broker. 1178 Multiple independent Broker providers can be used as long as they 1179 have standard interface to a Client Application or TAM SDK. Only one 1180 Broker is generally expected in a device. 1182 7. Attestation 1184 Attestation is the process through which one entity (an attestor) 1185 presents a series of claims to another entity (a verifier), and 1186 provides sufficient proof that the claims are true. Different 1187 verifiers may have different standards for attestation proofs and not 1188 all attestations are acceptable to every verifier. TEEP attestations 1189 are based upon the use of an asymmetric key pair under the control of 1190 the TEE to create digital signatures across a well-defined claim set. 1192 In TEEP, the primary purpose of an attestation is to allow a device 1193 to prove to TAMs and SPs that a TEE in the device has particular 1194 properties, was built by a particular manufacturer, or is executing a 1195 particular TA. Other claims are possible; this architecture 1196 specification does not limit the attestation claims, but defines a 1197 minimal set of claims required for TEEP to operate properly. 1198 Extensions to these claims are possible, but are not defined in the 1199 TEEP specifications. Other standards or groups may define the format 1200 and semantics of extended claims. The TEEP specification defines the 1201 claims format such that these extended claims may be easily included 1202 in a TEEP attestation message. 1204 As of the writing of this specification, device and TEE attestations 1205 have not been standardized across the market. Different devices, 1206 manufacturers, and TEEs support different attestation algorithms and 1207 mechanisms. In order for TEEP to be inclusive, the attestation 1208 format shall allow for both proprietary attestation signatures, as 1209 well as a standardized form of attestation signature. Either form of 1210 attestation signature may be applied to a set of TEEP claims, and 1211 both forms of attestation shall be considered conformant with TEEP. 1212 However, it should be recognized that not all TAMs or SPs may be able 1213 to process all proprietary forms of attestations. All TAMs and SPs 1214 MUST be able to process the TEEP standard attestation format and 1215 attached signature. 1217 The attestation formats and mechanisms described and mandated by TEEP 1218 shall convey a particular set of cryptographic properties based on 1219 minimal assumptions. The cryptographic properties are conveyed by 1220 the attestation; however the assumptions are not conveyed within the 1221 attestation itself. 1223 The assumptions which may apply to an attestation have to do with the 1224 quality of the attestation and the quality and security provided by 1225 the TEE, the device, the manufacturer, or others involved in the 1226 device or TEE ecosystem. Some of the assumptions that might apply to 1227 an attestations include (this may not be a comprehensive list): 1229 - Assumptions regarding the security measures a manufacturer takes 1230 when provisioning keys into devices/TEEs; 1232 - Assumptions regarding what hardware and software components have 1233 access to the Attestation keys of the TEE; 1235 - Assumptions related to the source or local verification of claims 1236 within an attestation prior to a TEE signing a set of claims; 1238 - Assumptions regarding the level of protection afforded to 1239 attestation keys against exfiltration, modification, and side 1240 channel attacks; 1242 - Assumptions regarding the limitations of use applied to TEE 1243 Attestation keys; 1245 - Assumptions regarding the processes in place to discover or detect 1246 TEE breeches; and 1248 - Assumptions regarding the revocation and recovery process of TEE 1249 attestation keys. 1251 TAMs and SPs must be comfortable with the assumptions that are 1252 inherently part of any attestation they accept. Alternatively, any 1253 TAM or SP may choose not to accept an attestation generated from a 1254 particular manufacturer or device's TEE based on the inherent 1255 assumptions. The choice and policy decisions are left up to the 1256 particular TAM/SP. 1258 Some TAMs or SPs may require additional claims in order to properly 1259 authorize a device or TEE. These additional claims may help clear up 1260 any assumptions for which the TAM/SP wants to alleviate. The 1261 specific format for these additional claims are outside the scope of 1262 this specification, but the OTrP protocol SHALL allow these 1263 additional claims to be included in the attestation messages. 1265 The following sub-sections define the cryptographic properties 1266 conveyed by the TEEP attestation, the basic set of TEEP claims 1267 required in a TEEP attestation, the TEEP attestation flow between the 1268 TAM the device TEE, and some implementation examples of how an 1269 attestation key may be realized in a real TEEP device. 1271 7.1. Attestation Cryptographic Properties 1273 The attestation constructed by TEEP must convey certain cryptographic 1274 properties from the attestor to the verifier; in the case of TEEP, 1275 the attestation must convey properties from the device to the TAM 1276 and/or SP. The properties required by TEEP include: 1278 - Non-repudiation, Unique Proof of Source - the cryptographic 1279 digital signature across the attestation, and optionally along 1280 with information in the attestion itself SHALL uniquely identify a 1281 specific TEE in a specific device. 1283 - Integrity of claims - the cryptographic digital signature across 1284 the attestation SHALL cover the entire attestation including all 1285 meta data and all the claims in the attestation, ensuring that the 1286 attestation has not be modified since the TEE signed the 1287 attestation. 1289 Standard public key algorithms such as RSA and ECDSA digital 1290 signatures convey these properties. Group public key algorithms such 1291 as EPID can also convey these properties, if the attestation includes 1292 a unique device identifier and an identifier for the TEE. Other 1293 cryptographic operations used in other attestation schemes may also 1294 convey these properties. 1296 The TEEP standard attestation format SHALL use one of the following 1297 digital signature formats: 1299 - RSA-2048 with SHA-256 or SHA-384 in RSASSA-PKCS1-v1_5 or PSS 1300 format 1302 - RSA-3072 with SHA-256 or SHA-384 in RSASSA-PKCS1-v1_5 or PSS 1303 format 1305 - ECDSA-256 using NIST P256 curve using SHA-256 1307 - ECDSA-384 using NIST P384 curve using SHA-384 1309 - HashEdDSA using Ed25519 with SHA-512 (Ed25519ph in RFC8032) and 1310 context="TEEP Attestation" 1312 - EdDSA using Ed448 with SHAK256 (Ed448ph in RFC8032) and 1313 context="TEEP Attestation" 1315 All TAMs and SPs MUST be able to accept attestations using these 1316 algorithms, contingent on their acceptance of the assumptions implied 1317 by the attestations. 1319 7.2. TEEP Attestation Structure 1321 For a TEEP attestation to be useful, it must contain an information 1322 set allowing the TAM and/or SP to assess the attestation and make a 1323 related security policy decision. The structure of the TEEP 1324 attestation is shown in the diagram below. 1326 +------(Signed By)-----------+ 1327 | | 1328 /--------------------------\ V 1329 +---------------+-------------+--------------------------+ 1330 | Attestation | The | The | 1331 | Header | Claims | Attestation Signature(s) | 1332 +---------------+-------------+--------------------------+ 1333 | 1334 | 1335 +------------+--(Contains)------+-----------------+--------------+ 1336 | | | | | 1337 V V V V V 1338 +-------------+ +-------------+ +----------+ +-----------------+ +------------+ 1339 | Device | | TEE | | | | Action or | | Additional | 1340 | Identifying | | Identifying | | Liveness | | Operation | | or optional| 1341 | Info | | Info | | Proof | | Specific claims | | Claims | 1342 +-------------+ +-------------+ +----------+ +-----------------+ +------------+ 1344 Figure 7: Structure of TEEP Attestation 1346 The Attestation Header SHALL identify the "Attestation Type" and the 1347 "Attestation Signature Type" along with an "Attestation Format 1348 Version Number." The "Attestation Type" identifies the minimal set 1349 of claims that MUST be included in the attestation; this is an 1350 identifier for a profile that defines the claims that should be 1351 included in the attestation as part of the "Action or Operation 1352 Specific Claims." The "Attestation Signature Type" identifies the 1353 type of attestation signature that is attached. The type of 1354 attestation signature SHALL be one of the standard signatures types 1355 identified by an IANA number, a proprietary signature type identified 1356 by an IANA number, or the generic "Proprietary Signature" with an 1357 accompanying proprietary identifier. Not all TAMs may be able to 1358 process proprietary signatures. 1360 The claims in the attestation are set of mandatory and optional 1361 claims. The claims themselves SHALL be defined in an attestation 1362 claims dictionary. See the next section on TEEP Attestation Claims. 1363 Claims are grouped in profiles under an identifier (Attestation 1364 Type), however all attestations require a minimal set of claims which 1365 includes: 1367 - Device Identifying Info: TEEP attestations must uniquely identify 1368 a device to the TAM and SP. This identifier allows the TAM/SP to 1369 provide services unique to the device, such as managing installed 1370 TAs, and providing subscriptions to services, and locating device- 1371 specific keying material to communicate wiht or authenticate the 1372 device. Additionally, device manufacturer information must be 1373 provided to provide better universal uniqueness qualities without 1374 requiring globally unique identifiers for all devices. 1376 - TEE Identifying info: The type of TEE that generated this 1377 attestation must be identified. Standard TEE types are identified 1378 by an IANA number, but also must include version identification 1379 information such as the hardware, firmware, and software version 1380 of the TEE, as applicable by the TEE type. Structure to the 1381 version number is required.TEE manufacturer information for the 1382 TEE is required in order to disambiguate the same TEE type created 1383 by different manufacturers and resolve potential assumptions 1384 around manufacturer provisioning, keying and support for the TEE. 1386 - Liveness Proof: a claim that includes liveness information SHALL 1387 be included which may be a large nonce or may be a timestamp and 1388 short nonce. 1390 - Action Specific Claims: Certain attestation types shall include 1391 specific claims. For example an attestation from a specific TA 1392 shall include a measurement, version and signing public key for 1393 the TA. 1395 - Additional Claims: (Optional - May be empty set) A TAM or SP may 1396 require specific additional claims in order to address potential 1397 assumptions, such as the requirement that a device's REE performed 1398 a secure boot, or that the device is not currenlty in a debug or 1399 non-productions state. A TAM may require a device to provide a 1400 device health attestation that may include some claims or 1401 measurements about the REE. These claims are TAM specific. 1403 7.3. TEEP Attestation Claims 1405 TEEP requires a set of attestation claims that provide sufficient 1406 evidence to the TAM and/or SP that the device and its TEE meet 1407 certain minimal requirements. Because attestation formats are not 1408 yet broadly standardized across the industry, standardization work is 1409 currently ongoing, and it is expected that extensions to the 1410 attestation claims will be required as new TEEs and devices are 1411 created, the set of attestation claims required by TEEP SHALL be 1412 defined in an IANA registry. That registry SHALL be defined in the 1413 OTrP protocol with sufficient elements to address basic TEEP claims, 1414 expected new standard claims (for example from 1415 https://www.ietf.org/id/draft-mandyam-eat-01.txt), and proprietary 1416 claim sets. 1418 7.4. TEEP Attestation Flow 1420 Attesations are required in TEEP under the following flows: 1422 - When a TEE responds with device state information (dsi) to the TAM 1423 or SP, including a "GetDeviceState" response, "InstallTA" 1424 response, etc. 1426 - When a new key pair is generated for a TA-to-TAM or TA-to-SP 1427 communication, the keypair must be covered by an attestation, 1428 including "CreateSecurityDomain" response, "UpdateSecurityDomain" 1429 response, etc. 1431 7.5. Attestation Key Example 1433 The attestation hierarchy and seed required for TAM protocol 1434 operation must be built into the device at manufacture. Additional 1435 TEEs can be added post-manufacture using the scheme proposed, but it 1436 is outside of the current scope of this document to detail that. 1438 It should be noted that the attestation scheme described is based on 1439 signatures. The only decryption that may take place is through the 1440 use of a bootloader key. 1442 A boot module generated attestation can be optional where the 1443 starting point of device attestation can be at TEE certificates. A 1444 TAM can define its policies on what kinds of TEE it trusts if TFW 1445 attestation is not included during the TEE attestation. 1447 7.5.1. Attestation Hierarchy Establishment: Manufacture 1449 During manufacture the following steps are required: 1451 1. A device-specific TFW key pair and certificate are burnt into the 1452 device. This key pair will be used for signing operations 1453 performed by the boot module. 1455 2. TEE images are loaded and include a TEE instance-specific key 1456 pair and certificate. The key pair and certificate are included 1457 in the image and covered by the code signing hash. 1459 3. The process for TEE images is repeated for any subordinate TEEs, 1460 which are additional TEEs after the root TEE that some devices 1461 have. 1463 7.5.2. Attestation Hierarchy Establishment: Device Boot 1465 During device boot the following steps are required: 1467 1. The boot module releases the TFW private key by decrypting it 1468 with the bootloader key. 1470 2. The boot module verifies the code-signing signature of the active 1471 TEE and places its TEE public key into a signing buffer, along 1472 with its identifier for later access. For a TEE non-compliant to 1473 this architecture, the boot module leaves the TEE public key 1474 field blank. 1476 3. The boot module signs the signing buffer with the TFW private 1477 key. 1479 4. Each active TEE performs the same operation as the boot module, 1480 building up their own signed buffer containing subordinate TEE 1481 information. 1483 7.5.3. Attestation Hierarchy Establishment: TAM 1485 Before a TAM can begin operation in the marketplace, it must obtain a 1486 TAM certificate from a CA that is registered in the trust store of 1487 devices. In this way, the TEE can check the intermediate and root CA 1488 and verify that it trusts this TAM to perform operations on the TEE. 1490 8. Algorithm and Attestation Agility 1492 RFC 7696 [RFC7696] outlines the requirements to migrate from one 1493 mandatory-to-implement algorithm suite to another over time. This 1494 feature is also known as crypto agility. Protocol evolution is 1495 greatly simplified when crypto agility is already considered during 1496 the design of the protocol. In the case of the Open Trust Protocol 1497 (OTrP) the diverse range of use cases, from trusted app updates for 1498 smart phones and tablets to updates of code on higher-end IoT 1499 devices, creates the need for different mandatory-to-implement 1500 algorithms already from the start. 1502 Crypto agility in the OTrP concerns the use of symmetric as well as 1503 asymmetric algorithms. Symmetric algorithms are used for encryption 1504 of content whereas the asymmetric algorithms are mostly used for 1505 signing messages. 1507 In addition to the use of cryptographic algorithms in OTrP there is 1508 also the need to make use of different attestation technologies. A 1509 Device must provide techniques to inform a TAM about the attestation 1510 technology it supports. For many deployment cases it is more likely 1511 for the TAM to support one or more attestation techniques whereas the 1512 Device may only support one. 1514 9. Security Considerations 1516 9.1. TA Trust Check at TEE 1518 A TA binary is signed by a TA signer certificate. This TA signing 1519 certificate/private key belongs to the SP, and may be self-signed 1520 (i.e., it need not participate in a trust hierarchy). It is the 1521 responsibility of the TAM to only allow verified TAs from trusted SPs 1522 into the system. Delivery of that TA to the TEE is then the 1523 responsibility of the TEE, using the security mechanisms provided by 1524 the protocol. 1526 We allow a way for an (untrusted) application to check the 1527 trustworthiness of a TA. A TEEP Broker has a function to allow an 1528 application to query the information about a TA. 1530 An application in the Rich O/S may perform verification of the TA by 1531 verifying the signature of the TA. The GetTAInformation function is 1532 available to return the TEE supplied TA signer and TAM signer 1533 information to the application. An application can do additional 1534 trust checks on the certificate returned for this TA. It might trust 1535 the TAM, or require additional SP signer trust chaining. 1537 9.2. One TA Multiple SP Case 1539 A TA for multiple SPs must have a different identifier per SP. They 1540 should appear as different TAs when they are installed in the same 1541 device. 1543 9.3. Broker Trust Model 1545 A TEEP Broker could be malware in the vulnerable REE. A Client 1546 Application will connect its TAM provider for required TA 1547 installation. It gets command messages from the TAM, and passes the 1548 message to the Broker. 1550 The architecture enables the TAM to communicate with the device's TEE 1551 to manage TAs. All TAM messages are signed and sensitive data is 1552 encrypted such that the TEEP Broker cannot modify or capture 1553 sensitive data. 1555 9.4. Data Protection at TAM and TEE 1557 The TEE implementation provides protection of data on the device. It 1558 is the responsibility of the TAM to protect data on its servers. 1560 9.5. Compromised CA 1562 A root CA for TAM certificates might get compromised. Some TEE trust 1563 anchor update mechanism is expected from device OEMs. A compromised 1564 intermediate CA is covered by OCSP stapling and OCSP validation check 1565 in the protocol. A TEE should validate certificate revocation about 1566 a TAM certificate chain. 1568 If the root CA of some TEE device certificates is compromised, these 1569 devices might be rejected by a TAM, which is a decision of the TAM 1570 implementation and policy choice. Any intermediate CA for TEE device 1571 certificates SHOULD be validated by TAM with a Certificate Revocation 1572 List (CRL) or Online Certificate Status Protocol (OCSP) method. 1574 9.6. Compromised TAM 1576 The TEE SHOULD use validation of the supplied TAM certificates and 1577 OCSP stapled data to validate that the TAM is trustworthy. 1579 Since PKI is used, the integrity of the clock within the TEE 1580 determines the ability of the TEE to reject an expired TAM 1581 certificate, or revoked TAM certificate. Since OCSP stapling 1582 includes signature generation time, certificate validity dates are 1583 compared to the current time. 1585 9.7. Certificate Renewal 1587 TFW and TEE device certificates are expected to be long lived, longer 1588 than the lifetime of a device. A TAM certificate usually has a 1589 moderate lifetime of 2 to 5 years. A TAM should get renewed or 1590 rekeyed certificates. The root CA certificates for a TAM, which are 1591 embedded into the Trust Anchor store in a device, should have long 1592 lifetimes that don't require device Trust Anchor update. On the 1593 other hand, it is imperative that OEMs or device providers plan for 1594 support of Trust Anchor update in their shipped devices. 1596 10. IANA Considerations 1598 This document does not require actions by IANA. 1600 11. Acknowledgements 1602 The authors thank Dave Thaler for his very thorough review and many 1603 important suggestions. Most content of this document is split from a 1604 previously combined OTrP protocol document 1605 [I-D.ietf-teep-opentrustprotocol]. We thank the former co-authors 1606 Nick Cook and Minho Yoo for the initial document content, and 1607 contributors Brian Witten, Tyler Kim, and Alin Mutu. 1609 12. References 1611 12.1. Normative References 1613 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1614 Requirement Levels", BCP 14, RFC 2119, 1615 DOI 10.17487/RFC2119, March 1997, 1616 . 1618 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1619 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1620 May 2017, . 1622 12.2. Informative References 1624 [GPTEE] Global Platform, "GlobalPlatform Device Technology: TEE 1625 System Architecture, v1.1", Global Platform GPD_SPE_009, 1626 January 2017, . 1629 [I-D.ietf-teep-opentrustprotocol] 1630 Pei, M., Atyeo, A., Cook, N., Yoo, M., and H. Tschofenig, 1631 "The Open Trust Protocol (OTrP)", draft-ietf-teep- 1632 opentrustprotocol-03 (work in progress), May 2019. 1634 [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management 1635 Requirements", RFC 6024, DOI 10.17487/RFC6024, October 1636 2010, . 1638 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 1639 Agility and Selecting Mandatory-to-Implement Algorithms", 1640 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 1641 . 1643 Appendix A. History 1645 RFC EDITOR: PLEASE REMOVE THIS SECTION 1647 IETF Drafts 1649 draft-00: - Initial working group document 1651 Authors' Addresses 1653 Mingliang Pei 1654 Symantec 1656 EMail: mingliang_pei@symantec.com 1658 Hannes Tschofenig 1659 Arm Limited 1661 EMail: hannes.tschofenig@arm.com 1663 David Wheeler 1664 Intel 1666 EMail: david.m.wheeler@intel.com 1668 Andrew Atyeo 1669 Intercede 1671 EMail: andrew.atyeo@intercede.com 1673 Liu Dapeng 1674 Alibaba Group 1676 EMail: maxpassion@gmail.com