idnits 2.17.1 draft-ietf-teep-architecture-02.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 (March 11, 2019) is 1866 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CA' is mentioned on line 1139, but not defined == Missing Reference: 'Soc' is mentioned on line 1141, but not defined == Missing Reference: 'OEM' is mentioned on line 1153, but not defined == Unused Reference: 'RFC6024' is defined on line 1708, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-teep-opentrustprotocol-02 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). 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: September 12, 2019 Arm Limited 6 D. Wheeler 7 Intel 8 A. Atyeo 9 Intercede 10 L. Dapeng 11 Alibaba Group 12 March 11, 2019 14 Trusted Execution Environment Provisioning (TEEP) Architecture 15 draft-ietf-teep-architecture-02 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 September 12, 2019. 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 . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . 20 94 5.11. Scalability . . . . . . . . . . . . . . . . . . . . . . . 23 95 5.12. Message Security . . . . . . . . . . . . . . . . . . . . 23 96 5.13. Security Domain Hierarchy and Ownership . . . . . . . . . 23 97 5.14. SD Owner Identification and TAM Certificate Requirements 24 98 5.15. Service Provider Container . . . . . . . . . . . . . . . 25 99 5.16. A Sample Device Setup Flow . . . . . . . . . . . . . . . 25 100 6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 26 101 6.1. Role of the Agent . . . . . . . . . . . . . . . . . . . . 27 102 6.2. Agent Implementation Consideration . . . . . . . . . . . 27 103 6.2.1. Agent Distribution . . . . . . . . . . . . . . . . . 27 104 6.2.2. Number of Agents . . . . . . . . . . . . . . . . . . 27 105 7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 28 106 7.1. Attestation Cryptographic Properties . . . . . . . . . . 30 107 7.2. TEEP Attestation Structure . . . . . . . . . . . . . . . 31 108 7.3. TEEP Attestation Claims . . . . . . . . . . . . . . . . . 32 109 7.4. TEEP Attestation Flow . . . . . . . . . . . . . . . . . . 33 110 7.5. Attestation Key Example . . . . . . . . . . . . . . . . . 33 111 7.5.1. Attestation Hierarchy Establishment: Manufacture . . 33 112 7.5.2. Attestation Hierarchy Establishment: Device Boot . . 34 113 7.5.3. Attestation Hierarchy Establishment: TAM . . . . . . 34 114 8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 34 115 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 116 9.1. TA Trust Check at TEE . . . . . . . . . . . . . . . . . . 35 117 9.2. One TA Multiple SP Case . . . . . . . . . . . . . . . . . 35 118 9.3. Agent Trust Model . . . . . . . . . . . . . . . . . . . . 35 119 9.4. Data Protection at TAM and TEE . . . . . . . . . . . . . 36 120 9.5. Compromised CA . . . . . . . . . . . . . . . . . . . . . 36 121 9.6. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 36 122 9.7. Certificate Renewal . . . . . . . . . . . . . . . . . . . 36 123 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 124 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 125 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 126 12.1. Normative References . . . . . . . . . . . . . . . . . . 37 127 12.2. Informative References . . . . . . . . . . . . . . . . . 37 128 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 38 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 131 1. Introduction 133 Applications executing in a device are exposed to many different 134 attacks intended to compromise the execution of the application, or 135 reveal the data upon which those applications are operating. These 136 attacks increase with the number of other applications on the device, 137 with such other applications coming from potentially untrustworthy 138 sources. The potential for attacks further increase with the 139 complexity of features and applications on devices, and the 140 unintended interactions among those features and applications. The 141 danger of attacks on a system increases as the sensitivity of the 142 applications or data on the device increases. As an example, 143 exposure of emails from a mail client is likely to be of concern to 144 its owner, but a compromise of a banking application raises even 145 greater concerns. 147 The Trusted Execution Environment (TEE) concept is designed to 148 execute applications in a protected environment that separates 149 applications inside the TEE from the regular operating system and 150 from other applications on the device. This separation reduces the 151 possibility of a successful attack on application components and the 152 data contained inside the TEE. Typically, application components are 153 chosen to execute inside a TEE because those application components 154 perform security sensitive operations or operate on sensitive data. 155 An application component running inside a TEE is referred to as a 156 Trusted Application (TA), while a normal application running in the 157 regular operating system is referred to as an Untrusted Application 158 (UA). 160 The TEE uses hardware to enforce protections on the TA and its data, 161 but also presents a more limited set of services to applications 162 inside the TEE than is normally available to UA's running in the 163 normal operating system. 165 But not all TEEs are the same, and different vendors may have 166 different implementations of TEEs with different security properties, 167 different features, and different control mechanisms to operate on 168 TAs. Some vendors may themselves market multiple different TEEs with 169 different properties attuned to different markets. A device vendor 170 may integrate one or more TEEs into their devices depending on market 171 needs. 173 To simplify the life of developers and service providers interacting 174 with TAs in a TEE, an interoperable protocol for managing TAs running 175 in different TEEs of various devices is needed. In this TEE 176 ecosystem, there often arises a need for an external trusted party to 177 verify the identity, claims, and rights of Service Providers(SP), 178 devices, and their TEEs. This trusted third party is the Trusted 179 Application Manager (TAM). 181 This protocol addresses the following problems: 183 - A Service Provider (SP) intending to provide services through a TA 184 to users of a device needs to determine security-relevant 185 information of a device before provisioning their TA to the TEE 186 within the device. Examples include the verification of the 187 device 'root of trust' and the type of TEE included in a device. 189 - A TEE in a device needs to determine whether a Service Provider 190 (SP) that wants to manage a TA in the device is authorized to 191 manage TAs in the TEE, and what TAs the SP is permitted to manage. 193 - The parties involved in the protocol must be able to attest that a 194 TEE is genuine and capable of providing the security protections 195 required by a particular TA. 197 - A Service Provider (SP) must be able to deterine if a TA exists 198 (is installed) on a device (in the TEE), and if not, install the 199 TA in the TEE. 201 - A Service Provider (SP) must be able to check whether a TA in a 202 device's TEE is the most up-to-date version, and if not, update 203 the TA in the TEE. 205 - A Service Provider (SP) must be able to remove a TA in a device's 206 TEE if the SP is no longer offering such services or the services 207 are being revoked from a particular user (or device). For 208 example, if a subscription or contract for a particular service 209 has expired, or a payment by the user has not been completed or 210 has been recinded. 212 - A Service Provider (SP) must be able to define the relationship 213 between cooperating TAs under the SP's control, and specify 214 whether the TAs can communicate, share data, and/or share key 215 material. 217 2. Terminology 219 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 220 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 221 "OPTIONAL" in this document are to be interpreted as described in BCP 222 14 [RFC2119] [RFC8174] when, and only when, they appear in all 223 capitals, as shown here. 225 The following terms are used: 227 - Client Application: An application running in a Rich Execution 228 Environment, such as an Android, Windows, or iOS application. We 229 sometimes refer to this as the 'Client App'. 231 - Device: A physical piece of hardware that hosts a TEE along with a 232 Rich Execution Environment. A Device contains a default list of 233 Trust Anchors that identify entities (e.g., TAMs) that are trusted 234 by the Device. This list is normally set by the Device 235 Manufacturer, and may be governed by the Device's network carrier. 236 The list of Trust Anchors is normally modifiable by the Device's 237 owner or Device Administrator. However the Device manufacturer 238 and network carrier may restrict some modifications, for example, 239 by not allowing the manufacturer or carrier's Trust Anchor to be 240 removed or disabled. 242 - Rich Execution Environment (REE): An environment that is provided 243 and governed by a typical OS (e.g., Linux, Windows, Android, iOS), 244 potentially in conjunction with other supporting operating systems 245 and hypervisors; it is outside of the TEE. This environment and 246 applications running on it are considered un-trusted. 248 - Service Provider (SP): An entity that wishes to provide a service 249 on Devices that requires the use of one or more Trusted 250 Applications. A Service Provider requires the help of a TAM in 251 order to provision the Trusted Applications to remote devices. 253 - Device User: A human being that uses a device. Many devices have 254 a single device user. Some devices have a primary device user 255 with other human beings as secondary device users (e.g., parent 256 allowing children to use their tablet or laptop). Relates to 257 Device Owner and Device Administrator. 259 - Device Owner: A device is always owned by someone. It is common 260 for the (primary) device user to also own the device, making the 261 device user/owner also the device administrator. In enterprise 262 environments it is more common for the enterprise to own the 263 device, and device users have no or limited administration rights. 264 In this case, the enterprise appoints a device administrator that 265 is not the device owner. 267 - Device Administrator (DA): An entity that is responsible for 268 administration of a Device, which could be the device owner. A 269 Device Administrator has privileges on the Device to install and 270 remove applications and TAs, approve or reject Trust Anchors, and 271 approve or reject Service Providers, among possibly other 272 privileges on the Device. A Device Administrator can manage the 273 list of allowed TAMs by modifying the list of Trust Anchors on the 274 Device. Although a Device Administrator may have privileges and 275 Device-specific controls to locally administer a device, the 276 Device Administrator may choose to remotely administrate a device 277 through a TAM. 279 - Trust Anchor: A public key in a device whose corresponding private 280 key is held by an entity implicitly trusted by the device. The 281 Trust Anchor may be a certificate or it may be a raw public key 282 along with additional data if necessary such as its public key 283 algorithm and parameters. The Trust Anchor is normally stored in 284 a location that resists unauthorized modification, insertion, or 285 replacement. The digital fingerprint of a Trust Anchor may be 286 stored along with the Trust Anchor certificate or public key. A 287 device can use the fingerprint to uniquely identify a Trust 288 Anchor. The Trust Anchor private key owner can sign certificates 289 of other public keys, which conveys trust about those keys to the 290 device. A certificate signed by the Trust Anchor communicates 291 that the private key holder of the signed certificate is trusted 292 by the Trust Anchor holder, and can therefore be trusted by the 293 device. Trust Anchors in a device may be updated by an authorized 294 party when a Trust Anchor should be deprecated or a new Trust 295 Anchor should be added. 297 - Trusted Application (TA): An application component that runs in a 298 TEE. 300 - Trusted Execution Environment (TEE): An execution environment that 301 runs alongside of, but is isolated from, an REE. A TEE has 302 security capabilities and meets certain security-related 303 requirements. It protects TEE assets from general software 304 attacks, defines rigid safeguards as to data and functions that a 305 program can access, and resists a set of defined threats. It 306 should have at least the following three properties: 308 (a) A device unique credential that cannot be cloned; 310 (b) Assurance that only authorized code can run in the TEE; 312 (c) Memory that cannot be read by code outside the TEE. 314 There are multiple technologies that can be used to implement a 315 TEE, and the level of security achieved varies accordingly. 317 - Root-of-Trust (RoT): A hardware or software component in a device 318 that is inherently trusted to perform a certain security-critical 319 function. A RoT should be secure by design, small, and protected 320 by hardware against modification or interference. Examples of 321 RoTs include software/firmware measurement and verification using 322 a Trust Anchor (RoT for Verification), provide signed assertions 323 using a protected attestation key (RoT for Reporting), or protect 324 the storage and/or use of cryptographic keys (RoT for Storage). 325 Other RoTs are possible, including RoT for Integrity, and RoT for 326 Measurement. Reference: NIST SP800-164 (Draft). 328 - Trusted Firmware (TFW): A firmware in a device that can be 329 verified with a Trust Anchor by RoT for Verification. 331 - Bootloader key: This symmetric key is protected by 332 electronic fuse (eFUSE) technology. In this context it is used to 333 decrypt a 334 TFW private key, which belongs to a device-unique private/public 335 key pair. Not every device is equipped with a bootloader key. 337 This document uses the following abbreviations: 339 - CA: Certificate Authority 341 - REE: Rich Execution Environment 343 - RoT: Root of Trust 345 - SD: Security Domain 347 - SP: Service Provider 349 - TA: Trusted Application 351 - TAM: Trusted Application Manager 353 - TEE: Trusted Execution Environment 355 - TFW: Trusted Firmware 357 3. Assumptions 359 This specification assumes that an applicable device is equipped with 360 one or more TEEs and each TEE is pre-provisioned with a device-unique 361 public/private key pair, which is securely stored. 363 A TEE uses an isolation mechanism between Trusted Applications to 364 ensure that one TA cannot read, modify or delete the data and code of 365 another TA. 367 4. Use Cases 369 4.1. Payment 371 A payment application in a mobile device requires high security and 372 trust about the hosting device. Payments initiated from a mobile 373 device can use a Trusted Application to provide strong identification 374 and proof of transaction. 376 For a mobile payment application, some biometric identification 377 information could also be stored in a TEE. The mobile payment 378 application can use such information for authentication. 380 A secure user interface (UI) may be used in a mobile device to 381 prevent malicious software from stealing sensitive user input data. 382 Such an application implementation often relies on a TEE for user 383 input protection. 385 4.2. Authentication 387 For better security of authentication, a device may store its 388 sensitive authentication keys inside a TEE, providing hardware- 389 protected security key strength and trusted code execution. 391 4.3. Internet of Things 393 The Internet of Things (IoT) has been posing threats to networks and 394 national infrastructures because of existing weak security in 395 devices. It is very desirable that IoT devices can prevent malware 396 from manipulating actuators (e.g., unlocking a door), or stealing or 397 modifying sensitive data such as authentication credentials in the 398 device. A TEE can be the best way to implement such IoT security 399 functions. 401 TEEs could be used to store variety of sensitive data for IoT 402 devices. For example, a TEE could be used in smart door locks to 403 store a user's biometric information for identification, and for 404 protecting access the locking mechanism. 406 4.4. Confidential Cloud Computing 408 A tenant can store sensitive data in a TEE in a cloud computing 409 server such that only the tenant can access the data, preventing the 410 cloud hosting provider from accessing the data. A tenant can run TAs 411 inside a server TEE for secure operation and enhanced data security. 412 This provides benefits not only to tenants with better data security 413 but also to cloud hosting provider for reduced liability and 414 increased cloud adoption. 416 5. Architecture 418 5.1. System Components 420 The following are the main components in the system. Full 421 descriptions of components not previously defined are provided below. 422 Interactions of all components are further explained in the following 423 paragraphs. 425 +-------------------------------------------+ 426 | Device | 427 | +--------+ | Service Provider 428 | | |----------+ | 429 | +-------------+ | TEEP |---------+| | 430 | | TEE-1 |<------| Broker | | || +--------+ | 431 | | | | |<---+ | |+-->| |<-+ 432 | | | | | | | | +-| TAM-1 | 433 | | | | |<-+ | | +->| | |<-+ 434 | | +---+ +---+ | +--------+ | | | | +--------+ | 435 | | |TA1| |TA2| | | | | | TAM-2 | | 436 | +-->| | | | | +-------+ | | | +--------+ | 437 | | | | | | |<---------| App-2 |--+ | | | 438 | | | +---+ +---+ | +-------+ | | | Device Administrator 439 | | +-------------+ | App-1 | | | | 440 | | | | | | | 441 | +--------------------| |---+ | | 442 | | |--------+ | 443 | +-------+ | 444 +-------------------------------------------+ 446 Figure 1: Notional Architecture of TEEP 448 - Service Providers (SP) and Device Administrators (DA) utilize the 449 services of a TAM to manage TAs on Devices. SPs do not directly 450 interact with devices. DAs may elect to use a TAM for remote 451 administration of TAs instead of managing each device directly. 453 - TAM: A TAM is responsible for performing lifecycle management 454 activity on TA's and SD's on behalf of Service Providers and 455 Device Administrators. This includes creation and deletion of 456 TA's and SD's, and may include, for example, over-the-air updates 457 to keep an SP's TAs up-to-date and clean up when a version should 458 be removed. TAMs may provide services that make it easier for SPs 459 or DAs to use the TAM's service to manage multiple devices, 460 although that is not required of a TAM. 462 The TAM performs its management of TA's and SD's through an 463 interaction with a Device's TEEP Broker. As shown in 464 #notionalarch, the TAM cannot directly contact a Device, but must 465 wait for a the TEEP Broker or a Client Application to contact the 466 TAM requesting a particular service. This architecture is 467 intentional in order to accommodate network and application 468 firewalls that normally protect user and enterprise devices from 469 arbitrary connections from external network entities. 471 A TAM may be publicly available for use by many SPs, or a TAM may 472 be private, and accessible by only one or a limited number of SPs. 474 It is expected that manufacturers and carriers will run their own 475 private TAM. Another example of a private TAM is a TAM running as 476 a Software-as-a-Service (SaaS) within an SP. 478 A SP or Device Administrator chooses a particular TAM based on 479 whether the TAM is trusted by a Device or set of Devices. The TAM 480 is trusted by a device if the TAM's public key is an authorized 481 Trust Anchor in the Device. A SP or Device Administrator may run 482 their own TAM, however the Devices they wish to manage must 483 include this TAM's pubic key in the Trust Anchor list. 485 A SP or Device Administrator is free to utilize multiple TAMs. 486 This may be required for a SP to manage multiple different types 487 of devices from different manufacturers, or devices on different 488 carriers, since the Trust Anchor list on these different devices 489 may contain different TAMs. A Device Administrator may be able to 490 add their own TAM's public key or certificate to the Trust Anchor 491 list on all their devices, overcoming this limitation. 493 Any entity is free to operate a TAM. For a TAM to be successful, 494 it must have its public key or certificate installed in Devices 495 Trust Anchor list. A TAM may set up a relationship with device 496 manufacturers or carriers to have them install the TAM's keys in 497 their device's Trust Anchor list. Alternatively, a TAM may 498 publish its certificate and allow Device Administrators to install 499 the TAM's certificate in their devices as an after-market-action. 501 - TEEP Broker: The TEEP Broker is an application running in a Rich 502 Execution Environment that enables the message protocol exchange 503 between a TAM and a TEE in a device. The TEEP Broker does not 504 process messages on behalf of a TEE, but merely is responsible for 505 relaying messages from the TAM to the TEE, and for returning the 506 TEE's responses to the TAM. 508 A Client Application is expected to communicate with a TAM to 509 request TAs that it needs to use. The Client Application needs to 510 pass the messages from the TAM to TEEs in the device. This calls 511 for a component in the REE that Client Applications can use to 512 pass messages to TEEs. An Agent is thus an application in the REE 513 or software library that can relay messages from a Client 514 Application to a TEE in the device. A device usually comes with 515 only one active TEE. A TEE may provide such an Agent to the 516 device manufacturer to be bundled in devices. Such a TEE must 517 also include an Agent counterpart, namely, a processing module 518 inside the TEE, to parse TAM messages sent through the Agent. An 519 Agent is generally acting as a dummy relaying box with just the 520 TEE interacting capability; it doesn't need and shouldn't parse 521 protocol messages. 523 - Certification Authority (CA): Certificate-based credentials used 524 for authenticating a device, a TAM and an SP. A device embeds a 525 list of root certificates (Trust Anchors), from trusted CAs that a 526 TAM will be validated against. A TAM will remotely attest a 527 device by checking whether a device comes with a certificate from 528 a CA that the TAM trusts. The CAs do not need to be the same; 529 different CAs can be chosen by each TAM, and different device CAs 530 can be used by different device manufacturers. 532 5.2. Different Renditions of TEEP Architecture 534 There is nothing prohibiting a device from implementing multiple 535 TEEs. In addition, some TEEs ( for example, SGX) present themselves 536 as separate containers within memory without a controlling manager 537 within the TEE. In these cases, the rich operating system hosts 538 multiple TEEP brokers, where each broker manages a particular TEE or 539 set of TEEs. Enumeration and access to the appropriate broker is up 540 to the rich OS and the applications. Verification that the correct 541 TA has been reached then becomes a matter of properly verifying TA 542 attestations, which are unforgeable. The multiple TEE approach is 543 shown in the diagram below. For brevity, TEEP Broker 2 is shown 544 interacting with only one TAM and UA, but no such limitation is 545 intended to be implied in the architecture. 547 +-------------------------------------------+ 548 | Device | 549 | +--------+ | Service Provider 550 | | |----------+ | 551 | +-------------+ | TEEP |---------+| | 552 | | TEE-1 |<------| Broker | | || +--------+ | 553 | | | | 1 |<---+ | |+-->| |<-+ 554 | | +---+ +---+ | | | | | | +-| TAM-1 | 555 | | |TA1| |TA2| | | |<-+ | | +->| | |<-+ 556 | +-->| | | |<---+ +--------+ | | | | +--------+ | 557 | | | +---+ +---+ | | | | | | TAM-2 | | 558 | | | | | +-------+ | | | +--------+ | 559 | | +-------------+ +-----| App-2 |--+ | | ^ | 560 | | +-------+ | | | | Device 561 | +--------------------| App-1 | | | | | Administrator 562 | +------| | | | | | 563 | +-----------|-+ | |---+ | | | 564 | | TEE-2 | | | |--------+ | | 565 | | | | | |------+ | | 566 | | +---+ | | +-------+ | | | 567 | | |TA3|<----+ | +----------+ | | | 568 | | | | | | TEEP |<--+ | | 569 | | +---+ |<---| Broker |----------------+ 570 | | | | 2 | | 571 | | | | | | 572 | +-------------+ +----------+ | 573 | | 574 +-------------------------------------------+ 576 Figure 2: Notional Architecture of TEEP wtih multiple TEEs 578 In the diagram above, TEEP Broker 1 controls interactions with the 579 TA's in TEE-1, and TEEP Broker 2 controls interactions with the TA's 580 in TEE-2. This presents some challenges for a TAM in completely 581 managing the device, since a TAM may not interact with all the TEEP 582 Brokers on a particular platform. In addition, since TEE's may be 583 physically separated, with wholly different resources, there may be 584 no need for TEEP Brokers to share information on installed TAs or 585 resource usage. However, the architecture guarantees that the TAM 586 will receive all the relevant information from the TEEP Broker to 587 which it communicates. 589 5.3. Multiple TAMs and Relationship to TAs 591 As shown in Figure 2, the TEEP Broker provides connections from the 592 TEE and the Client App to one or more TAMs. The selection of which 593 TAM to communicate with is dependent on information from the Client 594 App and is directly related to the TA. 596 When a SP offers a service which requires a TA, the SP associates 597 that service with a specific TA. The TA itself is digitally signed, 598 protecting its integrity, but the signature also links the TA back to 599 the signer. The signer is usually the SP, but in some cases may be 600 another party that the SP trusts. The SP selects one or more TAMs 601 through which to offer their service, and communicates the 602 information of the service and the specific client apps and TAs to 603 the TAM. 605 The SP chooses TAMs based upon the markets into which the TAM can 606 provide access. There may be TAMs that provide services to specific 607 types of mobile devices, or mobile device operating systems, or 608 specific geographical regions or network carriers. A SP may be 609 motivated to utilize multiple TAMs for its service in order to 610 maximize market penetration and availability on multiple types of 611 devices. This likely means that the same service will be available 612 through multiple TAMs. 614 When the SP publishes the Client App to an app store or other app 615 repositories, the SP binds the Client App with a manifest that 616 identifies what TAMs can be contacted for the TA. In some 617 situations, an SP may use only a single TAM - this is likely the case 618 for enterprise applications or SPs serving a closed community. For 619 broad public apps, there will likely be multiple TAMs in the manifest 620 - one servicing one brand of mobile device and another servicing a 621 different manufacturer, etc. Because different devices and different 622 manufacturers trust different TAMs, the manifest will include 623 different TAMs that support this SP's client app and TA. Multiple 624 TAMs allow the SP to provide thier service and this app (and TA) to 625 multiple different devices. 627 When the TEEP Broker recieves a request to contact the TAM for a 628 Client App in order to install a TA, a list of TAMs may be provided. 629 The TEEP Broker selects a single TAM that is consistent with the list 630 of trusted TAMs (trust anchors) provisioned on the device. For any 631 client app, there should be only a single TAM for the TEEP Broker to 632 contact. This is also the case when a Client App uses multiple TAs, 633 or when one TA depends on anther TA in a software dependency (see 634 section TBD). The reason is that the SP should provide each TAM that 635 it places in the Client App's manifest all the TAs that the app 636 requires. There is no benefit to going to multiple different TAMs, 637 and there is no need for a special TAM to be contacted for a specific 638 TA. 640 [Note: This should always be the case. When a particular device or 641 TEE supports only a special proprietary attestation mechanism, then a 642 specific TAM will be needed that supports that attestation scheme. 643 The TAM should also support standard atttestation signatures as well. 645 It is highly unlikely that a set of TAs would use different 646 proprietary attestation mechanisms since a TEE is likley to support 647 only one such proprietary scheme.] 649 [Note: This situation gets more complex in situations where a Client 650 App expects another application or a device to already have a 651 specific TA installed. This situation does not occur with SGX, but 652 could occur in situations where the secure world maintains an trusted 653 operating system and runs an entire trusted system with multiple TAs 654 running. This requires more discussion.] 656 5.4. Client Apps, Trusted Apps, and Personalization Data 658 In TEEP, there is an explicit relationship and dependence between the 659 client app in the REE and one or more TAs in the TEE, as shown in 660 Figure 2. From the perspective of a device user, a client app that 661 uses one or more TA's in a TEE appears no different from any other 662 untrusted application in the REE. However, the way the client app 663 and its corresponding TA's are packaged, delivered, and installed on 664 the device can vary. The variations depend on whether the client app 665 and TA are bundled together or are provided separately, and this has 666 implications to the management of the TAs in the TEE. In addition to 667 the client app and TA, the TA and/or TEE may require some additional 668 data to personalize the TA to the service provider or the device 669 user. This personalization data is dependent on the TEE, the TA and 670 the SP; an example of personalization data might be username and 671 password of the device user's account with the SP, or a secret 672 symmetric key used to by the TA to communicate with the SP. The 673 personalization data must be encrypted to preserve the 674 confidentiality of potentially sensitive data contained within it. 675 Other than this requirement to support confidentiality, TEEP place no 676 limitations or requirements on the personalization data. 678 There are three possible cases for bundling of the Client App, TA, 679 and personalizaiton data: 681 1. The Client App, TA, and personnalization data are all bundled 682 together in a single package by the SP and provided to the TEEP 683 Broker through the TAM. 685 2. The Client App and the TA are bundled together in a single 686 binary, which the TAM or a publicly accessible app store 687 maintains in repository, and the personalization data is 688 separately provided by the SP. In this case, the personalization 689 data is collected by the TAM and included in the InstallTA 690 message to the TEEP Broker. 692 3. All components are independent. The device user installs the 693 Client App through some independent or device-specific mechanism, 694 and the TAM provides the TA and personalization data from the SP. 695 Delivery of the TA and personalization data may be combined or 696 separate. 698 5.5. Examples of Application Delivery Mechanisms in Existing TEEs 700 In order to better understand these cases, it is helpful to review 701 actual implementations of TEEs and their application delivery 702 mechanisms. 704 In Intel Software Guard Extensions (SGX), the Client App and TA are 705 typically bound into the same binary (Case 2). The TA is compiled 706 into the Client App binary using SGX tools, and exists in the binary 707 as a shared library (.so or .dll). The Client App loads the TA into 708 an SGX enclave when the client needs the TA. This organization makes 709 it easy to maintain compatibility between the Client App and the TA, 710 since they are updated together. It is entirely possible to create a 711 Client App that loads an external TA into an SGX enclave and use that 712 TA (Case 3). In this case, the Client App would require a reference 713 to an external file or download such a file dynamically, place the 714 contents of the file into memory, and load that as a TA. Obviously, 715 such file or downloaded content must be properly formatted and signed 716 for it to be accepted by the SGX TEE. In SGX, for Case 2 and Case 3, 717 the personalization data is normally loaded into the SGX enclave (the 718 TA) after the TA has started. Although Case 1 is possible with SGX, 719 there are no instances of this known to be in use at this time, since 720 such a construction would required a special installation program and 721 SGX TA to recieve the encrypted binary, decrypt it, separate it into 722 the three different elements, and then install all three. This 723 installation is complex, because the Client App decrypted inside the 724 TEE must be passed out of the TEE to an installer in the REE which 725 would install the Client App; this assumes that the Client App binary 726 includes the TA code also, otherwise there is a significant problem 727 in getting the SGX encalve code (the TA) from the TEE, through the 728 installer and into the Client App in a trusted fashion. Finally, the 729 personalization data would need to be sent out of the TEE (encrypted 730 in an SGX encalve-to-enclave manner) to the REE's installation app, 731 which would pass this data to the installed Client App, which would 732 in turn send this data to the SGX enclave (TA). This complexity is 733 due to the fact that each SGX enclave is separate and does not have 734 direct communication to one another. 736 [NOTE: Need to add an equivalent discussion for an ARM/TZ 737 implementation] 739 5.6. TEEP Architectural Support for Client App, TA, and Personalization 740 Data Delivery 742 This section defines TEEP support for the three different cases for 743 delivery of the Client App, TA, and personalization data. 745 [Note: discussion of format of this single binary, and who/what is 746 responsible for splitting these things apart, and installing the 747 client app into the REE, the TA into the TEE, and the personalization 748 data into the TEE or TA. Obviously the decryption must be done by 749 the TEE but this may not be suported by all TAs.] 751 5.7. Entity Relations 753 This architecture leverages asymmetric cryptography to authenticate a 754 device to a TAM. Additionally, a TEE in a device authenticates a TAM 755 and TA signer. The provisioning of Trust Anchors to a device may 756 different from one use case to the other. A device administrator may 757 want to have the capability to control what TAs are allowed. A 758 device manufacturer enables verification of the TA signers and TAM 759 providers; it may embed a list of default Trust Anchors that the 760 signer of an allowed TA's signer certificate should chain to. A 761 device administrator may choose to accept a subset of the allowed TAs 762 via consent or action of downloading. 764 PKI CA -- CA CA -- 765 | | | 766 | | | 767 | | | 768 Device | | --- Agent / Client App --- | 769 SW | | | | | 770 | | | | | 771 | | | | | 772 | -- TEE TAM------- 773 | 774 | 775 FW 777 Figure 3: Entities 779 (App Developer) (App Store) (TAM) (Device with TEE) (CAs) 780 | | 781 | --> (Embedded TEE cert) <-- 782 | | 783 | <------------------------------ Get an app cert ----- | 784 | | <-- Get a TAM cert ------ | 785 | 786 1. Build two apps: 787 Client App 788 TA 789 | 790 | 791 Client App -- 2a. --> | ----- 3. Install -------> | 792 TA ------- 2b. Supply ------> | 4. Messaging-->| 793 | | | | 795 Figure 4: Developer Experience 797 Figure 4 shows an application developer building two applications: 1) 798 a rich Client Application; 2) a TA that provides some security 799 functions to be run inside a TEE. At step 2, the application 800 developer uploads the Client Application (2a) to an Application 801 Store. The Client Application may optionally bundle the TA binary. 802 Meanwhile, the application developer may provide its TA to a TAM 803 provider that will be managing the TA in various devices. 3. A user 804 will go to an Application Store to download the Client Application. 805 The Client Application will trigger TA installation by initiating 806 communication with a TAM. This is the step 4. The Client 807 Application will get messages from TAM, and interacts with device TEE 808 via an Agent. 810 The following diagram shows a system diagram about the entity 811 relationships between CAs, TAMs, SPs and devices. 813 ------- Message Protocol ----- 814 | | 815 | | 816 -------------------- --------------- ---------- 817 | REE | TEE | | TAM | | SP | 818 | --- | --- | | --- | | -- | 819 | | | | | | | 820 | Client | SD (TAs)| | SD / TA | | TA | 821 | Apps | | | Mgmt | | | 822 | | | | | | | | 823 | | | List of | | List of | | | 824 | | Trusted | | Trusted | | | 825 | Agent | TAM/SP | | FW/TEE | | | 826 | | CAs | | CAs | | | 827 | | | | | | | 828 | |TEE Key/ | | TAM Key/ | |SP Key/ | 829 | | Cert | | Cert | | Cert | 830 | | FW Key/ | | | | | 831 | | Cert | | | | | 832 -------------------- --------------- ---------- 833 | | | 834 | | | 835 ------------- ---------- --------- 836 | TEE CA | | TAM CA | | SP CA | 837 ------------- ---------- --------- 839 Figure 5: Keys 841 In the previous diagram, different CAs can be used for different 842 types of certificates. Messages are always signed, where the signer 843 key is the message originator's private key such as that of a TAM, 844 the private key of trusted firmware (TFW), or a TEE's private key. 846 The main components consist of a set of standard messages created by 847 a TAM to deliver device SD and TA management commands to a device, 848 and device attestation and response messages created by a TEE that 849 responds to a TAM's message. 851 It should be noted that network communication capability is generally 852 not available in TAs in today's TEE-powered devices. The networking 853 functionality must be delegated to a rich Client Application. Client 854 Applications will need to rely on an agent in the REE to interact 855 with a TEE for message exchanges. Consequently, a TAM generally 856 communicates with a Client Application about how it gets messages 857 that originate from a TEE inside a device. Similarly, a TA or TEE 858 generally gets messages from a TAM via some Client Application, 859 namely, an agent in this protocol architecture, not directly from the 860 network. 862 It is imperative to have an interoperable protocol to communicate 863 with different TAMs and different TEEs in different devices. This is 864 the role of the agent, which is a software component that bridges 865 communication between a TAM and a TEE. The agent does not need to 866 know the actual content of messages except for the TEE routing 867 information. 869 5.8. Trust Anchors in TEE 871 Each TEE comes with a trust store that contains a whitelist of Trust 872 Anchors that are used to validate a TAM's certificate. A TEE will 873 accept a TAM to create new Security Domains and install new TAs on 874 behalf of an SP only if the TAM's certificate is chained to one of 875 the root CA certificates in the TEE's trust store. 877 A TEE's trust store is typically preloaded at manufacturing time. It 878 is out of the scope in this document to specify how the trust anchors 879 should be updated when a new root certificate should be added or 880 existing one should be updated or removed. A device manufacturer is 881 expected to provide its TEE trust anchors live update or out-of-band 882 update to Device Administrators. 884 When trust anchor update is carried out, it is imperative that any 885 update must maintain integrity where only authentic trust anchor list 886 from a device manufacturer or a Device Administrator is accepted. 887 This calls for a complete lifecycle flow in authorizing who can make 888 trust anchor update and whether a given trust anchor list are non- 889 tampered from the original provider. The signing of a trust anchor 890 list for integrity check and update authorization methods are 891 desirable to be developed. This can be addressed outside of this 892 architecture document. 894 Before a TAM can begin operation in the marketplace to support a 895 device with a particular TEE, it must obtain a TAM certificate from a 896 CA that is listed in the trust store of the TEE. 898 5.9. Trust Anchors in TAM 900 The Trust Anchor store in a TAM consists of a list of CA certificates 901 that sign various device TEE certificates. A TAM will accept a 902 device for TA management if the TEE in the device uses a TEE 903 certificate that is chained to a CA that the TAM trusts. 905 5.10. Keys and Certificate Types 907 This architecture leverages the following credentials, which allow 908 delivering end-to-end security without relying on any transport 909 security. 911 +-------------+----------+--------+-------------------+-------------+ 912 | Key Entity | Location | Issuer | Checked Against | Cardinality | 913 | Name | | | | | 914 +-------------+----------+--------+-------------------+-------------+ 915 | 1. TFW key | Device | FW CA | A whitelist of | 1 per | 916 | pair and | secure | | FW root CA | device | 917 | certificate | storage | | trusted by TAMs | | 918 | | | | | | 919 | 2. TEE key | Device | TEE CA | A whitelist of | 1 per | 920 | pair and | TEE | under | TEE root CA | device | 921 | certificate | | a root | trusted by TAMs | | 922 | | | CA | | | 923 | | | | | | 924 | 3. TAM key | TAM | TAM CA | A whitelist of | 1 or | 925 | pair and | provider | under | TAM root CA | multiple | 926 | certificate | | a root | embedded in TEE | can be used | 927 | | | CA | | by a TAM | 928 | | | | | | 929 | 4. SP key | SP | SP | A SP uses a TAM. | 1 or | 930 | pair and | | signer | TA is signed by a | multiple | 931 | certificate | | CA | SP signer. TEE | can be used | 932 | | | | delegates trust | by a TAM | 933 | | | | of TA to TAM. SP | | 934 | | | | signer is | | 935 | | | | associated with a | | 936 | | | | SD as the owner. | | 937 +-------------+----------+--------+-------------------+-------------+ 939 Figure 6: Key and Certificate Types 941 1. TFW key pair and certificate: A key pair and certificate for 942 evidence of trustworthy firmware in a device. This key pair is 943 optional for TEEP architecture. Some TEE may present its trusted 944 attributes to a TAM using signed attestation with a TFW key. For 945 example, a platform that uses a hardware based TEE can have 946 attestation data signed by a hardware protected TFW key. 948 o Location: Device secure storage 950 o Supported Key Type: RSA and ECC 952 o Issuer: OEM CA 954 o Checked Against: A whitelist of FW root CA trusted by TAMs 956 o Cardinality: One per device 958 2. TEE key pair and certificate: It is used for device attestation 959 to a remote TAM and SP. 961 o This key pair is burned into the device by the device 962 manufacturer. The key pair and its certificate are valid for 963 the expected lifetime of the device. 965 o Location: Device TEE 967 o Supported Key Type: RSA and ECC 969 o Issuer: A CA that chains to a TEE root CA 971 o Checked Against: A whitelist of TEE root CAs trusted by TAMs 973 o Cardinality: One per device 975 3. TAM key pair and certificate: A TAM provider acquires a 976 certificate from a CA that a TEE trusts. 978 o Location: TAM provider 980 o Supported Key Type: RSA and ECC. 982 o Supported Key Size: RSA 2048-bit, ECC P-256 and P-384. Other 983 sizes should be anticipated in future. 985 o Issuer: TAM CA that chains to a root CA 987 o Checked Against: A whitelist of TAM root CAs embedded in a TEE 989 o Cardinality: One or multiple can be used by a TAM 991 4. SP key pair and certificate: An SP uses its own key pair and 992 certificate to sign a TA. 994 o Location: SP 996 o Supported Key Type: RSA and ECC 998 o Supported Key Size: RSA 2048-bit, ECC P-256 and P-384. Other 999 sizes should be anticipated in future. 1001 o Issuer: An SP signer CA that chains to a root CA 1003 o Checked Against: An SP uses a TAM. A TEE trusts an SP by 1004 validating trust against a TAM that the SP uses. A TEE trusts 1005 a TAM to ensure that a TA is trustworthy. 1007 o Cardinality: One or multiple can be used by an SP 1009 5.11. Scalability 1011 This architecture uses a PKI. Trust Anchors exist on the devices to 1012 enable the TEE to authenticate TAMs, and TAMs use Trust Anchors to 1013 authenticate TEEs. Since a PKI is used, many intermediate CA 1014 certificates can chain to a root certificate, each of which can issue 1015 many certificates. This makes the protocol highly scalable. New 1016 factories that produce TEEs can join the ecosystem. In this case, 1017 such a factory can get an intermediate CA certificate from one of the 1018 existing roots without requiring that TAMs are updated with 1019 information about the new device factory. Likewise, new TAMs can 1020 join the ecosystem, providing they are issued a TAM certificate that 1021 chains to an existing root whereby existing TEEs will be allowed to 1022 be personalized by the TAM without requiring changes to the TEE 1023 itself. This enables the ecosystem to scale, and avoids the need for 1024 centralized databases of all TEEs produced or all TAMs that exist. 1026 5.12. Message Security 1028 Messages created by a TAM are used to deliver device SD and TA 1029 management commands to a device, and device attestation and messages 1030 created by the device TEE to respond to TAM messages. 1032 These messages are signed end-to-end and are typically encrypted such 1033 that only the targeted device TEE or TAM is able to decrypt and view 1034 the actual content. 1036 5.13. Security Domain Hierarchy and Ownership 1038 The primary job of a TAM is to help an SP to manage its trusted 1039 applications. A TA is typically installed in an SD. An SD is 1040 commonly created for an SP. 1042 When an SP delegates its SD and TA management to a TAM, an SD is 1043 created on behalf of a TAM in a TEE and the owner of the SD is 1044 assigned to the TAM. An SD may be associated with an SP but the TAM 1045 has full privilege to manage the SD for the SP. 1047 Each SD for an SP is associated with only one TAM. When an SP 1048 changes TAM, a new SP SD must be created to associate with the new 1049 TAM. The TEE will maintain a registry of TAM ID and SP SD ID 1050 mapping. 1052 From an SD ownership perspective, the SD tree is flat and there is 1053 only one level. An SD is associated with its owner. It is up to the 1054 TEE implementation how it maintains SD binding information for a TAM 1055 and different SPs under the same TAM. 1057 It is an important decision in this architecture that a TEE doesn't 1058 need to know whether a TAM is authorized to manage the SD for an SP. 1059 This authorization is implicitly triggered by an SP Client 1060 Application, which instructs what TAM it wants to use. An SD is 1061 always associated with a TAM in addition to its SP ID. A rogue TAM 1062 isn't able to do anything on an unauthorized SP's SD managed by 1063 another TAM. 1065 Since a TAM may support multiple SPs, sharing the same SD name for 1066 different SPs creates a dependency in deleting an SD. An SD can be 1067 deleted only after all TAs associated with the SD are deleted. An SP 1068 cannot delete a Security Domain on its own with a TAM if a TAM 1069 decides to introduce such sharing. There are cases where multiple 1070 virtual SPs belong to the same organization, and a TAM chooses to use 1071 the same SD name for those SPs. This is totally up to the TAM 1072 implementation and out of scope of this specification. 1074 5.14. SD Owner Identification and TAM Certificate Requirements 1076 There is a need of cryptographically binding proof about the owner of 1077 an SD in a device. When an SD is created on behalf of a TAM, a 1078 future request from the TAM must present itself as a way that the TEE 1079 can verify it is the true owner. The certificate itself cannot 1080 reliably used as the owner because TAM may change its certificate. 1082 ** need to handle the normal key roll-over case, as well as the less 1083 frequent key compromise case 1085 To this end, each TAM will be associated with a trusted identifier 1086 defined as an attribute in the TAM certificate. This field is kept 1087 the same when the TAM renew its certificates. A TAM CA is 1088 responsible to vet the requested TAM attribute value. 1090 This identifier value must not collide among different TAM providers, 1091 and one TAM shouldn't be able to claim the identifier used by another 1092 TAM provider. 1094 The certificate extension name to carry the identifier can initially 1095 use SubjectAltName:registeredID. A dedicated new extension name may 1096 be registered later. 1098 One common choice of the identifier value is the TAM's service URL. 1099 A CA can verify the domain ownership of the URL with the TAM in the 1100 certificate enrollment process. 1102 A TEE can assign this certificate attribute value as the TAM owner ID 1103 for the SDs that are created for the TAM. 1105 An alternative way to represent an SD ownership by a TAM is to have a 1106 unique secret key upon SD creation such that only the creator TAM is 1107 able to produce a proof-of-possession (PoP) data with the secret. 1109 5.15. Service Provider Container 1111 A sample Security Domain hierarchy for the TEE is shown in Figure 7. 1113 ---------- 1114 | TEE | 1115 ---------- 1116 | 1117 | ---------- 1118 |----------| SP1 SD1 | 1119 | ---------- 1120 | ---------- 1121 |----------| SP1 SD2 | 1122 | ---------- 1123 | ---------- 1124 |----------| SP2 SD1 | 1125 ---------- 1127 Figure 7: Security Domain Hierarchy 1129 The architecture separates SDs and TAs such that a TAM can only 1130 manage or retrieve data for SDs and TAs that it previously created 1131 for the SPs it represents. 1133 5.16. A Sample Device Setup Flow 1135 Step 1: Prepare Images for Devices 1137 1. [TEE vendor] Deliver TEE Image (CODE Binary) to device OEM 1139 2. [CA] Deliver root CA Whitelist 1141 3. [Soc] Deliver TFW Image 1143 Step 2: Inject Key Pairs and Images to Devices 1145 1. [OEM] Generate TFW Key Pair (May be shared among multiple 1146 devices) 1148 2. [OEM] Flash signed TFW Image and signed TEE Image onto devices 1149 (signed by TFW Key) 1151 Step 3: Set up attestation key pairs in devices 1153 1. [OEM] Flash TFW Public Key and a bootloader key. 1155 2. [TFW/TEE] Generate a unique attestation key pair and get a 1156 certificate for the device. 1158 Step 4: Set up Trust Anchors in devices 1160 1. [TFW/TEE] Store the key and certificate encrypted with the 1161 bootloader key 1163 2. [TEE vendor or OEM] Store trusted CA certificate list into 1164 devices 1166 6. TEEP Broker 1168 A TEE and TAs do not generally have the capability to communicate to 1169 the outside of the hosting device. For example, GlobalPlatform 1170 [GPTEE] specifies one such architecture. This calls for a software 1171 module in the REE world to handle the network communication. Each 1172 Client Application in the REE might carry this communication 1173 functionality but such functionality must also interact with the TEE 1174 for the message exchange. 1175 The TEE interaction will vary according to different TEEs. In order 1176 for a Client Application to transparently support different TEEs, it 1177 is imperative to have a common interface for a Client Application to 1178 invoke for exchanging messages with TEEs. 1180 A shared agent comes to meet this need. An agent is an application 1181 running in the REE of the device or an SDK that facilitates 1182 communication between a TAM and a TEE. It also provides interfaces 1183 for Client Applications to query and trigger TA installation that the 1184 application needs to use. 1186 It isn't always that a Client Application directly calls such an 1187 agent to interact with a TEE. A REE Application Installer might 1188 carry out TEE and TAM interaction to install all required TAs that a 1189 Client Application depends. A Client Application may have a metadata 1190 file that describes the TAs it depends on and the associated TAM that 1191 each TA installation goes to use. The REE Application Installer can 1192 inspect the application metadata file and installs TAs on behalf of 1193 the Client Application without requiring the Client Application to 1194 run first. 1196 This interface for Client Applications or Application Installers may 1197 be commonly an OS service call for an REE OS. A Client Application 1198 or an Application Installer interacts with the device TEE and the 1199 TAMs. 1201 6.1. Role of the Agent 1203 An agent abstracts the message exchanges with the TEE in a device. 1204 The input data is originated from a TAM or the first initialization 1205 call to trigger a TA installation. 1207 The agent may internally process a message from a TAM. At least, it 1208 needs to know where to route a message, e.g., TEE instance. It does 1209 not need to process or verify message content. 1211 The agent returns TEE / TFW generated response messages to the 1212 caller. The agent is not expected to handle any network connection 1213 with an application or TAM. 1215 The agent only needs to return an agent error message if the TEE is 1216 not reachable for some reason. Other errors are represented as 1217 response messages returned from the TEE which will then be passed to 1218 the TAM. 1220 6.2. Agent Implementation Consideration 1222 A Provider should consider methods of distribution, scope and 1223 concurrency on devices and runtime options when implementing an 1224 agent. Several non-exhaustive options are discussed below. 1225 Providers are encouraged to take advantage of the latest 1226 communication and platform capabilities to offer the best user 1227 experience. 1229 6.2.1. Agent Distribution 1231 The agent installation is commonly carried out at OEM time. A user 1232 can dynamically download and install an agent on-demand. 1234 It is important to ensure a legitimate agent is installed and used. 1235 If an agent is compromised it may drop messages and thereby introduce 1236 a denial of service. 1238 6.2.2. Number of Agents 1240 We anticipate only one shared agent instance in a device. The 1241 device's TEE vendor will most probably supply one agent. 1243 With one shared agent, the agent provider is responsible to allow 1244 multiple TAMs and TEE providers to achieve interoperability. With a 1245 standard agent interface, each TAM can implement its own SDK for its 1246 SP Client Applications to work with this agent. 1248 Multiple independent agent providers can be used as long as they have 1249 standard interface to a Client Application or TAM SDK. Only one 1250 agent is expected in a device. 1252 TAM providers are generally expected to provide an SDK for SP 1253 applications to interact with an agent for the TAM and TEE 1254 interaction. 1256 7. Attestation 1258 Attestation is the process through which one entity (an attestor) 1259 presents a series of claims to another entity (a verifier), and 1260 provides sufficient proof that the claims are true. Different 1261 verifiers may have different standards for attestation proofs and not 1262 all attestations are acceptable to every verifier. TEEP attestations 1263 are based upon the use of an asymmetric key pair under the control of 1264 the TEE to create digital signatures across a well-defined claim set. 1266 In TEEP, the primary purpose of an attestation is to allow a device 1267 to prove to TAMs and SPs that a TEE in the device has particular 1268 properities, was built by a particular manufacturer, or is executing 1269 a particular TA. Other claims are possible; this architecture 1270 specification does not limit the attestation claims, but defines a 1271 minimal set of claims required for TEEP to operate properly. 1272 Extensions to these claims are possible, but are not defined in the 1273 TEEP specifications. Other standards or groups may define the format 1274 and semantics of extended claims. The TEEP specification defines the 1275 claims format such that these extended claims may be easily included 1276 in a TEEP attestation message. 1278 As of the writing of this specification, device and TEE attestations 1279 have not been standardized across the market. Different devices, 1280 manufacturers, and TEEs support different attestation algorithms and 1281 mechanisms. In order for TEEP to be inclusive, the attestation 1282 format shall allow for both proprietary attestation signatures, as 1283 well as a standardized form of attestation signature. Either form of 1284 attesation signature may be applied to a set of TEEP claims, and both 1285 forms of attestation shall be considered conformant with TEEP. 1286 However, it should be recognized that not all TAMs or SPs may be able 1287 to process all proprietary forms of attestations. All TAMs and SPs 1288 MUST be able to process the TEEP standard attestation format and 1289 attached signature. 1291 The attestation formats and mechanisms described and mandated by TEEP 1292 shall convey a particular set of cryptographic properties based on 1293 minimal assumptions. The cryptographic properties are conveyed by 1294 the attestation; however the assumptions are not conveyed within the 1295 attestation itself. 1297 The assumptions which may apply to an attestation have to do with the 1298 quality of the attestation and the quality and security provided by 1299 the TEE, the device, the manufacturer, or others involved in the 1300 device or TEE ecosystem. Some of the assumptions that might apply to 1301 an attestations include (this may not be a comprehensive list): 1303 - Assumptions regarding the security measures a manufacturer takes 1304 when provisioning keys into devices/TEEs; 1306 - Assumptions regarding what hardware and software components have 1307 access to the Attestation keys of the TEE; 1309 - Assumptions related to the source or local verification of claims 1310 within an attestation prior to a TEE signing a set of claims; 1312 - Assumptions regarding the level of protection afforded to 1313 attestation keys against exfiltration, modification, and side 1314 channel attacks; 1316 - Assumptions regarding the limitations of use applied to TEE 1317 Attestation keys; 1319 - Assumptions regarding the processes in place to discover or detect 1320 TEE breeches; and 1322 - Assumptions regarding the revocation and recovery process of TEE 1323 attestation keys. 1325 TAMs and SPs must be comfortable with the assumptions that are 1326 inherently part of any attestation they accept. Alternatively, any 1327 TAM or SP may choose not to accept an attestation generated from a 1328 particular manufacturer or device's TEE based on the inherent 1329 assumptions. The choice and policy decisions are left up to the 1330 particular TAM/SP. 1332 Some TAMs or SPs may require additional claims in order to properly 1333 authorize a device or TEE. These additional claims may help clear up 1334 any assumptions for which the TAM/SP wants to alleviate. The 1335 specific format for these additional claims are outside the scope of 1336 this specification, but the OTrP protocol SHALL allow these 1337 additional claims to be included in the attestation messages. 1339 The following sub-sections define the cryptographic properties 1340 conveyed by the TEEP attestation, the basic set of TEEP claims 1341 required in a TEEP attestation, the TEEP attestation flow between the 1342 TAM the device TEE, and some implementation examples of how an 1343 attestation key may be realized in a real TEEP device. 1345 7.1. Attestation Cryptographic Properties 1347 The attestation constructed by TEEP must convey certain cryptographic 1348 properties from the attestor to the verifier; in the case of TEEP, 1349 the attestation must convey properties from the device to the TAM 1350 and/or SP. The properties required by TEEP include: 1352 - Non-repudiation, Unique Proof of Source - the cryptographic 1353 digital signature across the attestation, and optionally along 1354 with information in the attestion itself SHALL uniquely identify a 1355 specific TEE in a specific device. 1357 - Integrity of claims - the cryptographic digital signature across 1358 the attestation SHALL cover the entire attesation including all 1359 meta data and all the claims in the attestation, ensuring that the 1360 attestation has not be modified since the TEE signed the 1361 attestation. 1363 Standard public key algorithms such as RSA and ECDSA digital 1364 signatures convey these properties. Group public key algorithms such 1365 as EPID can also convey these properties, if the attestation includes 1366 a unique device identifier and an identifier for the TEE. Other 1367 cryptographic operations used in other attestation schemes may also 1368 convey these properties. 1370 The TEEP standard attestation format SHALL use one of the following 1371 digital signature formats: 1373 - RSA-2048 with SHA-256 or SHA-384 in RSASSA-PKCS1-v1_5 or PSS 1374 format 1376 - RSA-3072 with SHA-256 or SHA-384 in RSASSA-PKCS1-v1_5 or PSS 1377 format 1379 - ECDSA-256 using NIST P256 curve using SHA-256 1381 - ECDSA-384 using NIST P384 curve using SHA-384 1383 - HashEdDSA using Ed25519 with SHA-512 (Ed25519ph in RFC8032) and 1384 context="TEEP Attestation" 1386 - EdDSA using Ed448 with SHAK256 (Ed448ph in RFC8032) and 1387 context="TEEP Attestation" 1389 All TAMs and SPs MUST be able to accept attestations using these 1390 algorithms, contingent on their acceptance of the assumptions implied 1391 by the attestations. 1393 7.2. TEEP Attestation Structure 1395 For a TEEP attestation to be useful, it must contain an information 1396 set allowing the TAM and/or SP to assess the attestation and make a 1397 related security policy decision. The structure of the TEEP 1398 attestation is shown in the diagram below. 1400 +------(Signed By)-----------+ 1401 | | 1402 /--------------------------\ V 1403 +---------------+-------------+--------------------------+ 1404 | Attestation | The | The | 1405 | Header | Claims | Attestation Signature(s) | 1406 +---------------+-------------+--------------------------+ 1407 | 1408 | 1409 +------------+--(Contains)------+-----------------+--------------+ 1410 | | | | | 1411 V V V V V 1412 +-------------+ +-------------+ +----------+ +-----------------+ +------------+ 1413 | Device | | TEE | | | | Action or | | Additional | 1414 | Identifying | | Identifying | | Liveness | | Operation | | or optional| 1415 | Info | | Info | | Proof | | Specific claims | | Claims | 1416 +-------------+ +-------------+ +----------+ +-----------------+ +------------+ 1418 Figure 8: Structure of TEEP Attestation 1420 The Attestation Header SHALL identify the "Attestation Type" and the 1421 "Attestation Signature Type" along with an "Attestation Format 1422 Version Number." The "Attestation Type" identifies the minimal set 1423 of claims that MUST be included in the attestation; this is an 1424 identifier for a profile that defines the claims that should be 1425 included in the attestation as part of the "Action or Operation 1426 Specific Claims." The "Attestation Signature Type" identifies the 1427 type of attestation signature that is attached. The type of 1428 attestation signature SHALL be one of the standard signatures types 1429 identified by an IANA number, a proprietary signature type identified 1430 by an IANA number, or the generic "Proprietary Signature" with an 1431 accompanying proprietary identifier. Not all TAMs may be able to 1432 process proprietary signatures. 1434 The claims in the attestation are set of mandatory and optional 1435 claims. The claims themselves SHALL be defined in an attestation 1436 claims dictionary. See the next section on TEEP Attestation Claims. 1438 Claims are grouped in profiles under an identifier (Attestation 1439 Type), however all attestations require a minimal set of claims which 1440 includes: 1442 - Device Identifying Info: TEEP attestations must uniquely identify 1443 a device to the TAM and SP. This identifier allows the TAM/SP to 1444 provide services unique to the device, such as managing installed 1445 TAs, and providing subscriptions to services, and locating device- 1446 specific keying material to communicate wiht or authenticate the 1447 device. Additionally, device manufacturer information must be 1448 provided to provide better universal uniqueness qualities without 1449 requiring globally unique identifiers for all devices. 1451 - TEE Identifying info: The type of TEE that generated this 1452 attestation must be identified. Standard TEE types are identified 1453 by an IANA number, but also must include version identification 1454 information such as the hardware, firmware, and software version 1455 of the TEE, as applicable by the TEE type. Structure to the 1456 version number is required.TEE manufacturer information for the 1457 TEE is required in order to disambiguate the same TEE type created 1458 by different manufacturers and resolve potential assumptions 1459 around manufacturer provisioning, keying and support for the TEE. 1461 - Liveness Proof: a claim that includes liveness information SHALL 1462 be included which may be a large nonce or may be a timestamp and 1463 short nonce. 1465 - Action Specific Claims: Certain attestation types shall include 1466 specific claims. For example an attestation from a specific TA 1467 shall include a measurement, version and signing public key for 1468 the TA. 1470 - Additional Claims: (Optional - May be empty set) A TAM or SP may 1471 require specific additional claims in order to address potential 1472 assumptions, such as the requirement that a device's REE performed 1473 a secure boot, or that the device is not currenlty in a debug or 1474 non-productions state. A TAM may require a device to provide a 1475 device health attestation that may include some claims or 1476 measurements about the REE. These claims are TAM specific. 1478 7.3. TEEP Attestation Claims 1480 TEEP requires a set of attestation claims that provide sufficient 1481 evidence to the TAM and/or SP that the device and its TEE meet 1482 certain minimal requirements. Because attestation formats are not 1483 yet broadly standardized across the industry, standardization work is 1484 currently ongoing, and it is expected that extensions to the 1485 attestation claims will be required as new TEEs and devices are 1486 created, the set of attestation claims required by TEEP SHALL be 1487 defined in an IANA registry. That registry SHALL be defined in the 1488 OTrP protocol with sufficient elements to address basic TEEP claims, 1489 expected new standard claims (for example from 1490 https://www.ietf.org/id/draft-mandyam-eat-01.txt), and proprietary 1491 claim sets. 1493 7.4. TEEP Attestation Flow 1495 Attesations are required in TEEP under the following flows: 1497 - When a TEE responds with device state information (dsi) to the TAM 1498 or SP, including a "GetDeviceState" response, "InstallTA" 1499 response, etc. 1501 - When a new key pair is generated for a TA-to-TAM or TA-to-SP 1502 communication, the keypair must be covered by an attestation, 1503 including "CreateSecurityDomain" response, "UpdateSecurityDomain" 1504 response, etc. 1506 7.5. Attestation Key Example 1508 The attestation hierarchy and seed required for TAM protocol 1509 operation must be built into the device at manufacture. Additional 1510 TEEs can be added post-manufacture using the scheme proposed, but it 1511 is outside of the current scope of this document to detail that. 1513 It should be noted that the attestation scheme described is based on 1514 signatures. The only decryption that may take place is through the 1515 use of a bootloader key. 1517 A boot module generated attestation can be optional where the 1518 starting point of device attestation can be at TEE certificates. A 1519 TAM can define its policies on what kinds of TEE it trusts if TFW 1520 attestation is not included during the TEE attestation. 1522 7.5.1. Attestation Hierarchy Establishment: Manufacture 1524 During manufacture the following steps are required: 1526 1. A device-specific TFW key pair and certificate are burnt into the 1527 device. This key pair will be used for signing operations 1528 performed by the boot module. 1530 2. TEE images are loaded and include a TEE instance-specific key 1531 pair and certificate. The key pair and certificate are included 1532 in the image and covered by the code signing hash. 1534 3. The process for TEE images is repeated for any subordinate TEEs, 1535 which are additional TEEs after the root TEE that some devices 1536 have. 1538 7.5.2. Attestation Hierarchy Establishment: Device Boot 1540 During device boot the following steps are required: 1542 1. The boot module releases the TFW private key by decrypting it 1543 with the bootloader key. 1545 2. The boot module verifies the code-signing signature of the active 1546 TEE and places its TEE public key into a signing buffer, along 1547 with its identifier for later access. For a TEE non-compliant to 1548 this architecture, the boot module leaves the TEE public key 1549 field blank. 1551 3. The boot module signs the signing buffer with the TFW private 1552 key. 1554 4. Each active TEE performs the same operation as the boot module, 1555 building up their own signed buffer containing subordinate TEE 1556 information. 1558 7.5.3. Attestation Hierarchy Establishment: TAM 1560 Before a TAM can begin operation in the marketplace, it must obtain a 1561 TAM certificate from a CA that is registered in the trust store of 1562 devices. In this way, the TEE can check the intermediate and root CA 1563 and verify that it trusts this TAM to perform operations on the TEE. 1565 8. Algorithm and Attestation Agility 1567 RFC 7696 [RFC7696] outlines the requirements to migrate from one 1568 mandatory-to-implement algorithm suite to another over time. This 1569 feature is also known as crypto agility. Protocol evolution is 1570 greatly simplified when crypto agility is already considered during 1571 the design of the protocol. In the case of the Open Trust Protocol 1572 (OTrP) the diverse range of use cases, from trusted app updates for 1573 smart phones and tablets to updates of code on higher-end IoT 1574 devices, creates the need for different mandatory-to-implement 1575 algorithms already from the start. 1577 Crypto agility in the OTrP concerns the use of symmetric as well as 1578 asymmetric algorithms. Symmetric algorithms are used for encryption 1579 of content whereas the asymmetric algorithms are mostly used for 1580 signing messages. 1582 In addition to the use of cryptographic algorithms in OTrP there is 1583 also the need to make use of different attestation technologies. A 1584 Device must provide techniques to inform a TAM about the attestation 1585 technology it supports. For many deployment cases it is more likely 1586 for the TAM to support one or more attestation techniques whereas the 1587 Device may only support one. 1589 9. Security Considerations 1591 9.1. TA Trust Check at TEE 1593 A TA binary is signed by a TA signer certificate. This TA signing 1594 certificate/private key belongs to the SP, and may be self-signed 1595 (i.e., it need not participate in a trust hierarchy). It is the 1596 responsibility of the TAM to only allow verified TAs from trusted SPs 1597 into the system. Delivery of that TA to the TEE is then the 1598 responsibility of the TEE, using the security mechanisms provided by 1599 the protocol. 1601 We allow a way for an (untrusted) application to check the 1602 trustworthiness of a TA. An agent has a function to allow an 1603 application to query the information about a TA. 1605 An application in the Rich O/S may perform verification of the TA by 1606 verifying the signature of the TA. The GetTAInformation function is 1607 available to return the TEE supplied TA signer and TAM signer 1608 information to the application. An application can do additional 1609 trust checks on the certificate returned for this TA. It might trust 1610 the TAM, or require additional SP signer trust chaining. 1612 9.2. One TA Multiple SP Case 1614 A TA for multiple SPs must have a different identifier per SP. A TA 1615 will be installed in a different SD for each respective SP. 1617 9.3. Agent Trust Model 1619 An agent could be malware in the vulnerable REE. A Client 1620 Application will connect its TAM provider for required TA 1621 installation. It gets command messages from the TAM, and passes the 1622 message to the agent. 1624 The architecture enables the TAM to communicate with the device's TEE 1625 to manage SDs and TAs. All TAM messages are signed and sensitive 1626 data is encrypted such that the agent cannot modify or capture 1627 sensitive data. 1629 9.4. Data Protection at TAM and TEE 1631 The TEE implementation provides protection of data on the device. It 1632 is the responsibility of the TAM to protect data on its servers. 1634 9.5. Compromised CA 1636 A root CA for TAM certificates might get compromised. Some TEE trust 1637 anchor update mechanism is expected from device OEMs. A compromised 1638 intermediate CA is covered by OCSP stapling and OCSP validation check 1639 in the protocol. A TEE should validate certificate revocation about 1640 a TAM certificate chain. 1642 If the root CA of some TEE device certificates is compromised, these 1643 devices might be rejected by a TAM, which is a decision of the TAM 1644 implementation and policy choice. Any intermediate CA for TEE device 1645 certificates SHOULD be validated by TAM with a Certificate Revocation 1646 List (CRL) or Online Certificate Status Protocol (OCSP) method. 1648 9.6. Compromised TAM 1650 The TEE SHOULD use validation of the supplied TAM certificates and 1651 OCSP stapled data to validate that the TAM is trustworthy. 1653 Since PKI is used, the integrity of the clock within the TEE 1654 determines the ability of the TEE to reject an expired TAM 1655 certificate, or revoked TAM certificate. Since OCSP stapling 1656 includes signature generation time, certificate validity dates are 1657 compared to the current time. 1659 9.7. Certificate Renewal 1661 TFW and TEE device certificates are expected to be long lived, longer 1662 than the lifetime of a device. A TAM certificate usually has a 1663 moderate lifetime of 2 to 5 years. A TAM should get renewed or 1664 rekeyed certificates. The root CA certificates for a TAM, which are 1665 embedded into the Trust Anchor store in a device, should have long 1666 lifetimes that don't require device Trust Anchor update. On the 1667 other hand, it is imperative that OEMs or device providers plan for 1668 support of Trust Anchor update in their shipped devices. 1670 10. IANA Considerations 1672 This document does not require actions by IANA. 1674 11. Acknowledgements 1676 The authors thank Dave Thaler for his very thorough review and many 1677 important suggestions. Most content of this document is split from a 1678 previously combined OTrP protocol document 1679 [I-D.ietf-teep-opentrustprotocol]. We thank the former co-authors 1680 Nick Cook and Minho Yoo for the initial document content, and 1681 contributors Brian Witten, Tyler Kim, and Alin Mutu. 1683 12. References 1685 12.1. Normative References 1687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1688 Requirement Levels", BCP 14, RFC 2119, 1689 DOI 10.17487/RFC2119, March 1997, 1690 . 1692 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1693 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1694 May 2017, . 1696 12.2. Informative References 1698 [GPTEE] Global Platform, "GlobalPlatform Device Technology: TEE 1699 System Architecture, v1.1", Global Platform GPD_SPE_009, 1700 January 2017, . 1703 [I-D.ietf-teep-opentrustprotocol] 1704 Pei, M., Atyeo, A., Cook, N., Yoo, M., and H. Tschofenig, 1705 "The Open Trust Protocol (OTrP)", draft-ietf-teep- 1706 opentrustprotocol-02 (work in progress), October 2018. 1708 [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management 1709 Requirements", RFC 6024, DOI 10.17487/RFC6024, October 1710 2010, . 1712 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 1713 Agility and Selecting Mandatory-to-Implement Algorithms", 1714 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 1715 . 1717 Appendix A. History 1719 RFC EDITOR: PLEASE REMOVE THIS SECTION 1721 IETF Drafts 1723 draft-00: - Initial working group document 1725 Authors' Addresses 1727 Mingliang Pei 1728 Symantec 1730 EMail: mingliang_pei@symantec.com 1732 Hannes Tschofenig 1733 Arm Limited 1735 EMail: hannes.tschofenig@arm.com 1737 David Wheeler 1738 Intel 1740 EMail: david.m.wheeler@intel.com 1742 Andrew Atyeo 1743 Intercede 1745 EMail: andrew.atyeo@intercede.com 1747 Liu Dapeng 1748 Alibaba Group 1750 EMail: maxpassion@gmail.com