idnits 2.17.1 draft-ietf-teep-architecture-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 (November 02, 2020) is 1269 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-07 == Outdated reference: A later version (-25) exists of draft-ietf-suit-manifest-09 == Outdated reference: A later version (-15) exists of draft-ietf-teep-otrp-over-http-08 == Outdated reference: A later version (-18) exists of draft-ietf-teep-protocol-03 Summary: 0 errors (**), 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 Broadcom 4 Intended status: Informational H. Tschofenig 5 Expires: May 6, 2021 Arm Limited 6 D. Thaler 7 Microsoft 8 D. Wheeler 9 Intel 10 November 02, 2020 12 Trusted Execution Environment Provisioning (TEEP) Architecture 13 draft-ietf-teep-architecture-13 15 Abstract 17 A Trusted Execution Environment (TEE) is an environment that enforces 18 that any code within that environment cannot be tampered with, and 19 that any data used by such code cannot be read or tampered with by 20 any code outside that environment. This architecture document 21 motivates the design and standardization of a protocol for managing 22 the lifecycle of trusted applications running inside such a TEE. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 6, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 8 75 3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 8 76 3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 8 77 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8 78 4.1. System Components . . . . . . . . . . . . . . . . . . . . 8 79 4.2. Multiple TEEs in a Device . . . . . . . . . . . . . . . . 11 80 4.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 13 81 4.4. Untrusted Apps, Trusted Apps, and Personalization Data . 14 82 4.4.1. Example: Application Delivery Mechanisms in Intel SGX 16 83 4.4.2. Example: Application Delivery Mechanisms in Arm 84 TrustZone . . . . . . . . . . . . . . . . . . . . . . 16 85 4.5. Entity Relations . . . . . . . . . . . . . . . . . . . . 17 86 5. Keys and Certificate Types . . . . . . . . . . . . . . . . . 18 87 5.1. Trust Anchors in a TEEP Agent . . . . . . . . . . . . . . 20 88 5.2. Trust Anchors in a TEE . . . . . . . . . . . . . . . . . 20 89 5.3. Trust Anchors in a TAM . . . . . . . . . . . . . . . . . 20 90 5.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 20 91 5.5. Message Security . . . . . . . . . . . . . . . . . . . . 21 92 6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 21 93 6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 22 94 6.2. TEEP Broker Implementation Consideration . . . . . . . . 22 95 6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 23 96 6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 24 98 7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 24 99 8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 26 100 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 101 9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 27 102 9.2. Data Protection . . . . . . . . . . . . . . . . . . . . . 27 103 9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 28 104 9.4. CA Compromise or Expiry of CA Certificate . . . . . . . . 29 105 9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 29 106 9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 29 107 9.7. Certificate Expiry and Renewal . . . . . . . . . . . . . 30 108 9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 31 109 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 110 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 111 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 112 13. Informative References . . . . . . . . . . . . . . . . . . . 31 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 115 1. Introduction 117 Applications executing in a device are exposed to many different 118 attacks intended to compromise the execution of the application or 119 reveal the data upon which those applications are operating. These 120 attacks increase with the number of other applications on the device, 121 with such other applications coming from potentially untrustworthy 122 sources. The potential for attacks further increases with the 123 complexity of features and applications on devices, and the 124 unintended interactions among those features and applications. The 125 danger of attacks on a system increases as the sensitivity of the 126 applications or data on the device increases. As an example, 127 exposure of emails from a mail client is likely to be of concern to 128 its owner, but a compromise of a banking application raises even 129 greater concerns. 131 The Trusted Execution Environment (TEE) concept is designed to 132 execute applications in a protected environment that enforces that 133 any code within that environment cannot be tampered with, and that 134 any data used by such code cannot be read or tampered with by any 135 code outside that environment, including by a commodity operating 136 system (if present). In a system with multiple TEEs, this also means 137 that code in one TEE cannot be read or tampered with by code in the 138 other TEE. 140 This separation reduces the possibility of a successful attack on 141 application components and the data contained inside the TEE. 142 Typically, application components are chosen to execute inside a TEE 143 because those application components perform security sensitive 144 operations or operate on sensitive data. An application component 145 running inside a TEE is referred to as a Trusted Application (TA), 146 while an application running outside any TEE, i.e., in the Rich 147 Execution Environment (REE), is referred to as an Untrusted 148 Application. In the example of a banking application, code that 149 relates to the authentication protocol could reside in a TA while the 150 application logic including HTTP protocol parsing could be contained 151 in the Untrusted Application. In addition, processing of credit card 152 numbers or account balances could be done in a TA as it is sensitive 153 data. The precise code split is ultimately a decision of the 154 developer based on the assets he or she wants to protect according to 155 the threat model. 157 TEEs use hardware enforcement combined with software protection to 158 secure TAs and its data. TEEs typically offer a more limited set of 159 services to TAs than is normally available to Untrusted Applications. 161 Not all TEEs are the same, however, and different vendors may have 162 different implementations of TEEs with different security properties, 163 different features, and different control mechanisms to operate on 164 TAs. Some vendors may themselves market multiple different TEEs with 165 different properties attuned to different markets. A device vendor 166 may integrate one or more TEEs into their devices depending on market 167 needs. 169 To simplify the life of TA developers interacting with TAs in a TEE, 170 an interoperable protocol for managing TAs running in different TEEs 171 of various devices is needed. This software update protocol needs to 172 make sure that compatible trusted and untrusted components (if any) 173 of an application are installed on the correct device. In this TEE 174 ecosystem, there often arises a need for an external trusted party to 175 verify the identity, claims, and rights of TA developers, devices, 176 and their TEEs. This trusted third party is the Trusted Application 177 Manager (TAM). 179 The Trusted Execution Environment Provisioning (TEEP) protocol 180 addresses the following problems: 182 - An installer of an Untrusted Application that depends on a given 183 TA wants to request installation of that TA in the device's TEE so 184 that the Untrusted Application can complete, but the TEE needs to 185 verify whether such a TA is actually authorized to run in the TEE 186 and consume potentially scarce TEE resources. 188 - A TA developer providing a TA whose code itself is considered 189 confidential wants to determine security-relevant information of a 190 device before allowing their TA to be provisioned to the TEE 191 within the device. An example is the verification of the type of 192 TEE included in a device and that it is capable of providing the 193 security protections required. 195 - A TEE in a device wants to determine whether an entity that wants 196 to manage a TA in the device is authorized to manage TAs in the 197 TEE, and what TAs the entity is permitted to manage. 199 - A Device Administrator wants to determine if a TA exists (is 200 installed) on a device (in the TEE), and if not, install the TA in 201 the TEE. 203 - A Device Administrator wants to check whether a TA in a device's 204 TEE is the most up-to-date version, and if not, update the TA in 205 the TEE. 207 - A Device Administrator wants to remove a TA from a device's TEE if 208 the TA developer is no longer maintaining that TA, when the TA has 209 been revoked or is not used for other reasons anymore (e.g., due 210 to an expired subscription). 212 - A TA developer wants to define the relationship between 213 cooperating TAs under the TA developer's control, and specify 214 whether the TAs can communicate, share data, and/or share key 215 material. 217 2. Terminology 219 The following terms are used: 221 - Device: A physical piece of hardware that hosts one or more TEEs, 222 often along with an REE. 224 - Device Administrator: An entity that is responsible for 225 administration of a device, which could be the Device Owner. A 226 Device Administrator has privileges on the device to install and 227 remove Untrusted Applications and TAs, approve or reject Trust 228 Anchors, and approve or reject TA developers, among possibly other 229 privileges on the device. A Device Administrator can manage the 230 list of allowed TAMs by modifying the list of Trust Anchors on the 231 device. Although a Device Administrator may have privileges and 232 device-specific controls to locally administer a device, the 233 Device Administrator may choose to remotely administer a device 234 through a TAM. 236 - Device Owner: A device is always owned by someone. In some cases, 237 it is common for the (primary) device user to also own the device, 238 making the device user/owner also the Device Administrator. In 239 enterprise environments it is more common for the enterprise to 240 own the device, and any device user has no or limited 241 administration rights. In this case, the enterprise appoints a 242 Device Administrator that is not the device owner. 244 - Device User: A human being that uses a device. Many devices have 245 a single device user. Some devices have a primary device user 246 with other human beings as secondary device users (e.g., parent 247 allowing children to use their tablet or laptop). Other devices 248 are not used by a human being and hence have no device user. 249 Relates to Device Owner and Device Administrator. 251 - Personalization Data: A set of configuration data that is specific 252 to the device or user. The Personalization Data may depend on the 253 type of TEE, a particular TEE instance, the TA, and even the user 254 of the device; an example of Personalization Data might be a 255 secret symmetric key used by a TA to communicate with some 256 service. 258 - Raw Public Key: The raw public key only consists of the 259 SubjectPublicKeyInfo structure of a PKIX certificate [RFC5280] 260 that carries the parameters necessary to describe the public key. 261 Other serialization formats that do not rely on ASN.1 may also be 262 used. 264 - Rich Execution Environment (REE): An environment that is provided 265 and governed by a typical OS (e.g., Linux, Windows, Android, iOS), 266 potentially in conjunction with other supporting operating systems 267 and hypervisors; it is outside of any TEE. This environment and 268 applications running on it are considered untrusted (or more 269 precisely, less trusted than a TEE). 271 - Trust Anchor: As defined in [RFC6024] and 272 [I-D.ietf-suit-manifest], "A trust anchor represents an 273 authoritative entity via a public key and associated data. The 274 public key is used to verify digital signatures, and the 275 associated data is used to constrain the types of information for 276 which the trust anchor is authoritative." The Trust Anchor may be 277 a certificate or it may be a raw public key along with additional 278 data if necessary such as its public key algorithm and parameters. 280 - Trust Anchor Store: As defined in [RFC6024], "A trust anchor store 281 is a set of one or more trust anchors stored in a device. A 282 device may have more than one trust anchor store, each of which 283 may be used by one or more applications." As noted in 284 [I-D.ietf-suit-manifest], a Trust Anchor Store must resist 285 modification against unauthorized insertion, deletion, and 286 modification. 288 - Trusted Application (TA): An application (or, in some 289 implementations, an application component) that runs in a TEE. 291 - Trusted Application (TA) Developer: An entity that develops one or 292 more TAs. 294 - Trusted Component (TA) Signer: An entity that signs a Trusted 295 Component with a key that a TEE will trust. The signer might or 296 might not be the same entity as the TA Developer. For example, a 297 TA might be signed (or re-signed) by a Device Administrator if the 298 TEE will only trust the Device Administrator. A TA might also be 299 encrypted, if the code is considered confidential. 301 - Trusted Application Manager (TAM): An entity that manages Trusted 302 Components running in TEEs of various devices. 304 - Trusted Component: A set of code and/or data in a TEE managed as a 305 unit by a Trusted Application Manager. Trusted Applications and 306 Personalization Data are thus managed by being included in Trusted 307 Components. Trusted OS code or trusted firmware can also be 308 expressed as Trusted Components that a TA depends on. 310 - Trusted Execution Environment (TEE): An execution environment that 311 enforces that only authorized code can execute within the TEE, and 312 data used by that code cannot be read or tampered with by code 313 outside the TEE. A TEE also generally has a device unique 314 credential that cannot be cloned. There are multiple technologies 315 that can be used to implement a TEE, and the level of security 316 achieved varies accordingly. In addition, TEEs typically use an 317 isolation mechanism between Trusted Applications to ensure that 318 one TA cannot read, modify or delete the data and code of another 319 TA. 321 - Untrusted Application: An application running in an REE. An 322 Untrusted Application might depend on one or more TAs. 324 3. Use Cases 326 3.1. Payment 328 A payment application in a mobile device requires high security and 329 trust in the hosting device. Payments initiated from a mobile device 330 can use a Trusted Application to provide strong identification and 331 proof of transaction. 333 For a mobile payment application, some biometric identification 334 information could also be stored in a TEE. The mobile payment 335 application can use such information for unlocking the device and for 336 local identification of the user. 338 A trusted user interface (UI) may be used in a mobile device to 339 prevent malicious software from stealing sensitive user input data. 340 Such an implementation often relies on a TEE for providing access to 341 peripherals, such as PIN input or a trusted display, so that the REE 342 cannot observe or tamper with the user input or output. 344 3.2. Authentication 346 For better security of authentication, a device may store its keys 347 and cryptographic libraries inside a TEE limiting access to 348 cryptographic functions via a well-defined interface and thereby 349 reducing access to keying material. 351 3.3. Internet of Things 353 The Internet of Things (IoT) has been posing threats to critical 354 infrastructure because of weak security in devices. It is desirable 355 that IoT devices can prevent malware from manipulating actuators 356 (e.g., unlocking a door), or stealing or modifying sensitive data, 357 such as authentication credentials in the device. A TEE can be the 358 best way to implement such IoT security functions. 360 3.4. Confidential Cloud Computing 362 A tenant can store sensitive data, such as customer details or credit 363 card numbers, in a TEE in a cloud computing server such that only the 364 tenant can access the data, preventing the cloud hosting provider 365 from accessing the data. A tenant can run TAs inside a server TEE 366 for secure operation and enhanced data security. This provides 367 benefits not only to tenants with better data security but also to 368 cloud hosting providers for reduced liability and increased cloud 369 adoption. 371 4. Architecture 373 4.1. System Components 375 Figure 1 shows the main components in a typical device with an REE. 376 Full descriptions of components not previously defined are provided 377 below. Interactions of all components are further explained in the 378 following paragraphs. 380 +-------------------------------------------+ 381 | Device | Trusted Component 382 | +--------+ | Signer 383 | +-------------+ | |-----------+ | 384 | | TEE-1 | | TEEP |---------+ | | 385 | | +--------+ | +----| Broker | | | | +--------+ | 386 | | | TEEP | | | | |<---+ | | +->| |<-+ 387 | | | Agent |<----+ | | | | | +-| TAM-1 | 388 | | +--------+ | | |<-+ | | +->| | |<-+ 389 | | | +--------+ | | | | +--------+ | 390 | | +---+ +---+ | | | | | TAM-2 | | 391 | +-->|TA1| |TA2| | +-------+ | | | +--------+ | 392 | | | | | | |<---------| App-2 |--+ | | | 393 | | | +---+ +---+ | +-------+ | | | Device Administrator 394 | | +-------------+ | App-1 | | | | 395 | | | | | | | 396 | +--------------------| |---+ | | 397 | | |--------+ | 398 | +-------+ | 399 +-------------------------------------------+ 401 Figure 1: Notional Architecture of TEEP 403 - Trusted Component Signers and Device Administrators utilize the 404 services of a TAM to manage TAs on devices. Trusted Component 405 Signers do not directly interact with devices. Device 406 Administators may elect to use a TAM for remote administration of 407 TAs instead of managing each device directly. 409 - Trusted Application Manager (TAM): A TAM is responsible for 410 performing lifecycle management activity on Trusted Components on 411 behalf of Trusted Component Signers and Device Administrators. 412 This includes installation and deletion of Trusted Components, and 413 may include, for example, over-the-air updates to keep Trusted 414 Components up-to-date and clean up when one should be removed. 415 TAMs may provide services that make it easier for Trusted 416 Component Signers or Device Administators to use the TAM's service 417 to manage multiple devices, although that is not required of a 418 TAM. 420 The TAM performs its management of Trusted Components on the 421 device through interactions with a device's TEEP Broker, which 422 relays messages between a TAM and a TEEP Agent running inside the 423 TEE. TEEP authentication is performed between a TAM and a TEEP 424 Agent. 426 As shown in Figure 1, the TAM cannot directly contact a TEEP 427 Agent, but must wait for the TEEP Broker to contact the TAM 428 requesting a particular service. This architecture is intentional 429 in order to accommodate network and application firewalls that 430 normally protect user and enterprise devices from arbitrary 431 connections from external network entities. 433 A TAM may be publicly available for use by many Trusted Component 434 Signers, or a TAM may be private, and accessible by only one or a 435 limited number of Trusted Component Signers. It is expected that 436 many manufacturers and network carriers will run their own private 437 TAM. 439 A Trusted Component Signer or Device Administrator chooses a 440 particular TAM based on whether the TAM is trusted by a device or 441 set of devices. The TAM is trusted by a device if the TAM's 442 public key is, or chains up to, an authorized Trust Anchor in the 443 device. A Trusted Component Signer or Device Administrator may 444 run their own TAM, but the devices they wish to manage must 445 include this TAM's public key or certificate, or a certificate it 446 chains up to, in the Trust Anchor Store. 448 A Trusted Component Signer or Device Administrator is free to 449 utilize multiple TAMs. This may be required for managing Trusted 450 Components on multiple different types of devices from different 451 manufacturers, or mobile devices on different network carriers, 452 since the Trust Anchor Store on these different devices may 453 contain different TAMs. A Device Administrator may be able to add 454 their own TAM's public key or certificate to the Trust Anchor 455 Store on all their devices, overcoming this limitation. 457 Any entity is free to operate a TAM. For a TAM to be successful, 458 it must have its public key or certificate installed in a device's 459 Trust Anchor Store. A TAM may set up a relationship with device 460 manufacturers or network carriers to have them install the TAM's 461 keys in their device's Trust Anchor Store. Alternatively, a TAM 462 may publish its certificate and allow Device Administrators to 463 install the TAM's certificate in their devices as an after-market- 464 action. 466 - TEEP Broker: A TEEP Broker is an application component running in 467 a Rich Execution Environment (REE) that enables the message 468 protocol exchange between a TAM and a TEE in a device. A TEEP 469 Broker does not process messages on behalf of a TEE, but merely is 470 responsible for relaying messages from the TAM to the TEE, and for 471 returning the TEE's responses to the TAM. In devices with no REE 472 (e.g., a microcontroller where all code runs in an environment 473 that meets the definition of a Trusted Execution Environment in 474 Section 2), the TEEP Broker would be absent and instead the TEEP 475 protocol transport would be implemented inside the TEE itself. 477 - TEEP Agent: The TEEP Agent is a processing module running inside a 478 TEE that receives TAM requests (typically relayed via a TEEP 479 Broker that runs in an REE). A TEEP Agent in the TEE may parse 480 requests or forward requests to other processing modules in a TEE, 481 which is up to a TEE provider's implementation. A response 482 message corresponding to a TAM request is sent back to the TAM, 483 again typically relayed via a TEEP Broker. 485 - Certification Authority (CA): A CA is an entity that issues 486 digital certificates (especially X.509 certificates) and vouches 487 for the binding between the data items in a certificate [RFC4949]. 488 Certificates are then used for authenticating a device, a TAM, or 489 a Trusted Component Signer, as discussed in Section 5. The CAs do 490 not need to be the same; different CAs can be chosen by each TAM, 491 and different device CAs can be used by different device 492 manufacturers. 494 4.2. Multiple TEEs in a Device 496 Some devices might implement multiple TEEs. In these cases, there 497 might be one shared TEEP Broker that interacts with all the TEEs in 498 the device. However, some TEEs (for example, SGX [SGX]) present 499 themselves as separate containers within memory without a controlling 500 manager within the TEE. As such, there might be multiple TEEP 501 Brokers in the REE, where each TEEP Broker communicates with one or 502 more TEEs associated with it. 504 It is up to the REE and the Untrusted Applications how they select 505 the correct TEEP Broker. Verification that the correct TA has been 506 reached then becomes a matter of properly verifying TA attestations, 507 which are unforgeable. 509 The multiple TEEP Broker approach is shown in the diagram below. For 510 brevity, TEEP Broker 2 is shown interacting with only one TAM and 511 Untrusted Application and only one TEE, but no such limitations are 512 intended to be implied in the architecture. 514 +-------------------------------------------+ Trusted 515 | Device | Component 516 | | Signer 517 | +-------------+ | | 518 | | TEE-1 | | | 519 | | +-------+ | +--------+ | +--------+ | 520 | | | TEEP | | | TEEP |------------->| |<-+ 521 | | | Agent |<----------| Broker | | | | TA 522 | | | 1 | | | 1 |---------+ | | 523 | | +-------+ | | | | | | | 524 | | | | |<---+ | | | | 525 | | +---+ +---+ | | | | | | +-| TAM-1 |Policy 526 | | |TA1| |TA2| | | |<-+ | | +->| | |<-+ 527 | +-->| | | |<---+ +--------+ | | | | +--------+ | 528 | | | +---+ +---+ | | | | | | TAM-2 | | 529 | | | | | +-------+ | | | +--------+ | 530 | | +-------------+ +-----| App-2 |--+ | | ^ | 531 | | +-------+ | | | | Device 532 | +--------------------| App-1 | | | | | Administrator 533 | +------| | | | | | 534 | +-----------|-+ | |---+ | | | 535 | | TEE-2 | | | |--------+ | | 536 | | +------+ | | | |------+ | | 537 | | | TEEP | | | +-------+ | | | 538 | | | Agent|<-----+ | | | 539 | | | 2 | | | | | | | 540 | | +------+ | | | | | | 541 | | | | | | | | 542 | | +---+ | | | | | | 543 | | |TA3|<----+ | | +----------+ | | | 544 | | | | | | | TEEP |<--+ | | 545 | | +---+ | +--| Broker | | | 546 | | | | 2 |----------------+ 547 | +-------------+ +----------+ | 548 | | 549 +-------------------------------------------+ 551 Figure 2: Notional Architecture of TEEP with multiple TEEs 553 In the diagram above, TEEP Broker 1 controls interactions with the 554 TAs in TEE-1, and TEEP Broker 2 controls interactions with the TAs in 555 TEE-2. This presents some challenges for a TAM in completely 556 managing the device, since a TAM may not interact with all the TEEP 557 Brokers on a particular platform. In addition, since TEEs may be 558 physically separated, with wholly different resources, there may be 559 no need for TEEP Brokers to share information on installed Trusted 560 Components or resource usage. 562 4.3. Multiple TAMs and Relationship to TAs 564 As shown in Figure 2, a TEEP Broker provides communication between 565 one or more TEEP Agents and one or more TAMs. The selection of which 566 TAM to communicate with might be made with or without input from an 567 Untrusted Application, but is ultimately the decision of a TEEP 568 Agent. 570 A TEEP Agent is assumed to be able to determine, for any given 571 Trusted Component, whether that Trusted Component is installed (or 572 minimally, is running) in a TEE with which the TEEP Agent is 573 associated. 575 Each Trusted Component is digitally signed, protecting its integrity, 576 and linking the Trusted Component back to the Trusted Component 577 Signer. The Trusted Component Signer is often the TA Developer, but 578 in some cases might be another party such as a Device Administrator 579 or other party to whom the code has been licensed (in which case the 580 same code might be signed by multiple licensees and distributed as if 581 it were different TAs). 583 A Trusted Component Signer selects one or more TAMs and communicates 584 the Trusted Component(s) to the TAM. For example, the Trusted 585 Component Signer might choose TAMs based upon the markets into which 586 the TAM can provide access. There may be TAMs that provide services 587 to specific types of devices, or device operating systems, or 588 specific geographical regions or network carriers. A Trusted 589 Component Signer may be motivated to utilize multiple TAMs in order 590 to maximize market penetration and availability on multiple types of 591 devices. This means that the same Trusted Component will often be 592 available through multiple TAMs. 594 When the developer of an Untrusted Application that depends on a 595 Trusted Component publishes the Untrusted Application to an app store 596 or other app repository, the developer optionally binds the Untrusted 597 Application with a manifest that identifies what TAMs can be 598 contacted for the Trusted Component. In some situations, a Trusted 599 Component may only be available via a single TAM - this is likely the 600 case for enterprise applications or Trusted Component Signers serving 601 a closed community. For broad public apps, there will likely be 602 multiple TAMs in the Untrusted Application's manifest - one servicing 603 one brand of mobile device and another servicing a different 604 manufacturer, etc. Because different devices and different 605 manufacturers trust different TAMs, the manifest can include multiple 606 TAMs that support the required Trusted Component. 608 When a TEEP Broker receives a request (see the RequestTA API in 609 Section 6.2.1) from an Untrusted Application to install a Trusted 610 Component, a list of TAM URIs may be provided for that Trusted 611 Component, and the request is passed to the TEEP Agent. If the TEEP 612 Agent decides that the Trusted Component needs to be installed, the 613 TEEP Agent selects a single TAM URI that is consistent with the list 614 of trusted TAMs provisioned in the TEEP Agent, invokes the HTTP 615 transport for TEEP to connect to the TAM URI, and begins a TEEP 616 protocol exchange. When the TEEP Agent subsequently receives the 617 Trusted Component to install and the Trusted Component's manifest 618 indicates dependencies on any other trusted components, each 619 dependency can include a list of TAM URIs for the relevant 620 dependency. If such dependencies exist that are prerequisites to 621 install the Trusted Component, then the TEEP Agent recursively 622 follows the same procedure for each dependency that needs to be 623 installed or updated, including selecting a TAM URI that is 624 consistent with the list of trusted TAMs provisioned on the device, 625 and beginning a TEEP exchange. If multiple TAM URIs are considered 626 trusted, only one needs to be contacted and they can be attempted in 627 some order until one responds. 629 Separate from the Untrusted Application's manifest, this framework 630 relies on the use of the manifest format in [I-D.ietf-suit-manifest] 631 for expressing how to install a Trusted Component, as well as any 632 dependencies on other TEE components and versions. That is, 633 dependencies from Trusted Components on other Trusted Components can 634 be expressed in a SUIT manifest, including dependencies on any other 635 TAs, or trusted OS code (if any), or trusted firmware. Installation 636 steps can also be expressed in a SUIT manifest. 638 For example, TEEs compliant with GlobalPlatform may have a notion of 639 a "security domain" (which is a grouping of one or more TAs installed 640 on a device, that can share information within such a group) that 641 must be created and into which one or more TAs can then be installed. 642 It is thus up to the SUIT manifest to express a dependency on having 643 such a security domain existing or being created first, as 644 appropriate. 646 Updating a Trusted Component may cause compatibility issues with any 647 Untrusted Applications or other components that depend on the updated 648 Trusted Component, just like updating the OS or a shared library 649 could impact an Untrusted Application. Thus, an implementation needs 650 to take into account such issues. 652 4.4. Untrusted Apps, Trusted Apps, and Personalization Data 654 In TEEP, there is an explicit relationship and dependence between an 655 Untrusted Application in an REE and one or more TAs in a TEE, as 656 shown in Figure 2. For most purposes, an Untrusted Application that 657 uses one or more TAs in a TEE appears no different from any other 658 Untrusted Application in the REE. However, the way the Untrusted 659 Application and its corresponding TAs are packaged, delivered, and 660 installed on the device can vary. The variations depend on whether 661 the Untrusted Application and TA are bundled together or are provided 662 separately, and this has implications to the management of the TAs in 663 a TEE. In addition to the Untrusted Application and TA(s), the TA(s) 664 and/or TEE may also require additional data to personalize the TA to 665 the device or a user. Implementations must support encryption of 666 such Personalization Data to preserve the confidentiality of 667 potentially sensitive data contained within it and support integrity 668 protection of the Personalization Data. Other than the requirement 669 to support confidentiality and integrity protection, the TEEP 670 architecture places no limitations or requirements on the 671 Personalization Data. 673 There are three possible cases for bundling of an Untrusted 674 Application, TA(s), and Personalization Data: 676 1. The Untrusted Application, TA(s), and Personalization Data are 677 all bundled together in a single package by a Trusted Component 678 Signer and either provided to the TEEP Broker through the TAM, or 679 provided separately (with encrypted Personalization Data), with 680 key material needed to decrypt and install the Personalization 681 Data and TA provided by a TAM. 683 2. The Untrusted Application and the TA(s) are bundled together in a 684 single package, which a TAM or a publicly accessible app store 685 maintains, and the Personalization Data is separately provided by 686 the Trusted Component Signer's TAM. 688 3. All components are independent. The Untrusted Application is 689 installed through some independent or device-specific mechanism, 690 and the TAM provides the TA and Personalization Data from the 691 Trusted Component Signer. Delivery of the TA and Personalization 692 Data may be combined or separate. 694 The TEEP protocol can treat each TA, any dependencies the TA has, and 695 Personalization Data as separate Trusted Components with separate 696 installation steps that are expressed in SUIT manifests, and a SUIT 697 manifest might contain or reference multiple binaries (see 698 [I-D.ietf-suit-manifest] for more details). The TEEP Agent is 699 responsible for handling any installation steps that need to be 700 performed inside the TEE, such as decryption of private TA binaries 701 or Personalization Data. 703 In order to better understand these cases, it is helpful to review 704 actual implementations of TEEs and their application delivery 705 mechanisms. 707 4.4.1. Example: Application Delivery Mechanisms in Intel SGX 709 In Intel Software Guard Extensions (SGX), the Untrusted Application 710 and TA are typically bundled into the same package (Case 2). The TA 711 exists in the package as a shared library (.so or .dll). The 712 Untrusted Application loads the TA into an SGX enclave when the 713 Untrusted Application needs the TA. This organization makes it easy 714 to maintain compatibility between the Untrusted Application and the 715 TA, since they are updated together. It is entirely possible to 716 create an Untrusted Application that loads an external TA into an SGX 717 enclave, and use that TA (Case 3). In this case, the Untrusted 718 Application would require a reference to an external file or download 719 such a file dynamically, place the contents of the file into memory, 720 and load that as a TA. Obviously, such file or downloaded content 721 must be properly formatted and signed for it to be accepted by the 722 SGX TEE. In SGX, for Case 2 and Case 3, the Personalization Data is 723 normally loaded into the SGX enclave (the TA) after the TA has 724 started. Although Case 1 is possible with SGX, there are no 725 instances of this known to be in use at this time, since such a 726 construction would require a special installation program and SGX TA 727 to receive the encrypted binary, decrypt it, separate it into the 728 three different elements, and then install all three. This 729 installation is complex because the Untrusted Application decrypted 730 inside the TEE must be passed out of the TEE to an installer in the 731 REE which would install the Untrusted Application; this assumes that 732 the Untrusted Application package includes the TA code also, since 733 otherwise there is a significant problem in getting the SGX enclave 734 code (the TA) from the TEE, through the installer, and into the 735 Untrusted Application in a trusted fashion. Finally, the 736 Personalization Data would need to be sent out of the TEE (encrypted 737 in an SGX enclave-to-enclave manner) to the REE's installation app, 738 which would pass this data to the installed Untrusted Application, 739 which would in turn send this data to the SGX enclave (TA). This 740 complexity is due to the fact that each SGX enclave is separate and 741 does not have direct communication to other SGX enclaves. 743 4.4.2. Example: Application Delivery Mechanisms in Arm TrustZone 745 In Arm TrustZone [TrustZone] for A-class devices, the Untrusted 746 Application and TA may or may not be bundled together. This differs 747 from SGX since in TrustZone the TA lifetime is not inherently tied to 748 a specific Untrused Application process lifetime as occurs in SGX. A 749 TA is loaded by a trusted OS running in the TEE such as a 750 GlobalPlatform compliant TEE, where the trusted OS is separate from 751 the OS in the REE. Thus Cases 2 and 3 are equally applicable. In 752 addition, it is possible for TAs to communicate with each other 753 without involving any Untrusted Application, and so the complexity of 754 Case 1 is lower than in the SGX example. Thus, Case 1 is possible as 755 well, though still more complex than Cases 2 and 3. 757 4.5. Entity Relations 759 This architecture leverages asymmetric cryptography to authenticate a 760 device to a TAM. Additionally, a TEEP Agent in a device 761 authenticates a TAM. The provisioning of Trust Anchors to a device 762 may be different from one use case to the other. A Device 763 Administrator may want to have the capability to control what TAs are 764 allowed. A device manufacturer enables verification by one or more 765 TAMs and by Trusted Component Signers; it may embed a list of default 766 Trust Anchors into the TEEP Agent and TEE for TAM trust verification 767 and TA signature verification. 769 (App Developers) (App Store) (TAM) (Device with TEE) (CAs) 770 | | | | | 771 | | | (Embedded TEE cert) <--| 772 | | | | | 773 | <--- Get an app cert -----------------------------------| 774 | | | | | 775 | | | <-- Get a TAM cert ---------| 776 | | | | | 777 1. Build two apps: | | | | 778 | | | | 779 (a) Untrusted | | | | 780 App - 2a. Supply --> | --- 3. Install ------> | | 781 | | | | 782 (b) TA -- 2b. Supply ----------> | 4. Messaging-->| | 783 | | | | 785 Figure 3: Example Developer Experience 787 Figure 3 shows an example where the same developer builds and signs 788 two applications: (a) an Untrusted Application; (b) a TA that 789 provides some security functions to be run inside a TEE. This 790 example assumes that the developer, the TEE, and the TAM have 791 previously been provisioned with certificates. 793 At step 1, the developer authors the two applications. 795 At step 2, the developer uploads the Untrusted Application (2a) to an 796 Application Store. In this example, the developer is also the 797 Trusted Component Signer, and so generates a signed TA. The 798 developer can then either bundle the signed TA with the Untrusted 799 Application, or the developer can provide a signed Trusted Component 800 containing the TA to a TAM that will be managing the TA in various 801 devices. 803 At step 3, a user will go to an Application Store to download the 804 Untrusted Application (where the arrow indicates the direction of 805 data transfer). 807 At step 4, since the Untrusted Application depends on the TA, 808 installing the Untrusted Application will trigger TA installation by 809 initiating communication with a TAM. The TEEP Agent will interact 810 with TAM via a TEEP Broker that faciliates communications between a 811 TAM and the TEEP Agent in TEE. 813 Some Trusted Component installation implementations might ask for a 814 user's consent. In other implementations, a Device Administrator 815 might choose what Untrusted Applications and related Trusted 816 Components to be installed. A user consent flow is out of scope of 817 the TEEP architecture. 819 The main components consist of a set of standard messages created by 820 a TAM to deliver Trusted Component management commands to a device, 821 and device attestation and response messages created by a TEE that 822 responds to a TAM's message. 824 It should be noted that network communication capability is generally 825 not available in TAs in today's TEE-powered devices. Consequently, 826 Trusted Applications generally rely on broker in the REE to provide 827 access to network functionality in the REE. A broker does not need 828 to know the actual content of messages to facilitate such access. 830 Similarly, since the TEEP Agent runs inside a TEE, the TEEP Agent 831 generally relies on a TEEP Broker in the REE to provide network 832 access, and relay TAM requests to the TEEP Agent and relay the 833 responses back to the TAM. 835 5. Keys and Certificate Types 837 This architecture leverages the following credentials, which allow 838 delivering end-to-end security between a TAM and a TEEP Agent. 840 Figure 4 summarizes the relationships between various keys and where 841 they are stored. Each public/private key identifies a Trusted 842 Component Signer, TAM, or TEE, and gets a certificate that chains up 843 to some trust anchor. A list of trusted certificates is then used to 844 check a presented certificate against. 846 Different CAs can be used for different types of certificates. TEEP 847 messages are always signed, where the signer key is the message 848 originator's private key, such as that of a TAM or a TEE. In 849 addition to the keys shown in Figure 4, there may be additional keys 850 used for attestation. Refer to the RATS Architecture 851 [I-D.ietf-rats-architecture] for more discussion. 853 Cardinality & Location of 854 Location of Private Key Trust Anchor 855 Purpose Private Key Signs Store 856 ------------------ ----------- ------------- ------------- 857 Authenticating TEE 1 per TEE TEEP responses TAM 859 Authenticating TAM 1 per TAM TEEP requests TEEP Agent 861 Code Signing 1 per Trusted TA binary TEE 862 Component 863 Signer 865 Figure 4: Signature Keys 867 Note that Personalization Data is not included in the table above. 868 The use of Personalization Data is dependent on how TAs are used and 869 what their security requirements are. 871 TEEP requests from a TAM to a TEEP Agent are signed with the TAM 872 private key (for authentication and integrity protection). 873 Personalization Data and TA binaries can be encrypted with a key that 874 is established with a content-encryption key established with the TEE 875 public key (to provide confidentiality). Conversely, TEEP responses 876 from a TEEP Agent to a TAM can be signed with the TEE private key. 878 The TEE key pair and certificate are thus used for authenticating the 879 TEE to a remote TAM, and for sending private data to the TEE. Often, 880 the key pair is burned into the TEE by the TEE manufacturer and the 881 key pair and its certificate are valid for the expected lifetime of 882 the TEE. A TAM provider is responsible for configuring the TAM's 883 Trust Anchor Store with the manufacturer certificates or CAs that are 884 used to sign TEE keys. This is discussed further in Section 5.3 885 below. 887 The TAM key pair and certificate are used for authenticating a TAM to 888 a remote TEE, and for sending private data to the TAM. A TAM 889 provider is responsible for acquiring a certificate from a CA that is 890 trusted by the TEEs it manages. This is discussed further in 891 Section 5.1 below. 893 The Trusted Component Signer key pair and certificate are used to 894 sign Trusted Components that the TEE will consider authorized to 895 execute. TEEs must be configured with the certificates or keys that 896 it considers authorized to sign TAs that it will execute. This is 897 discussed further in Section 5.2 below. 899 5.1. Trust Anchors in a TEEP Agent 901 A TEEP Agent's Trust Anchor Store contains a list of Trust Anchors, 902 which are CA certificates that sign various TAM certificates. The 903 list is typically preloaded at manufacturing time, and can be updated 904 using the TEEP protocol if the TEE has some form of "Trust Anchor 905 Manager TA" that has Trust Anchors in its configuration data. Thus, 906 Trust Anchors can be updated similar to updating the Personalization 907 Data for any other TA. 909 When Trust Anchor update is carried out, it is imperative that any 910 update must maintain integrity where only an authentic Trust Anchor 911 list from a device manufacturer or a Device Administrator is 912 accepted. Details are out of scope of the architecture and can be 913 addressed in a protocol document. 915 Before a TAM can begin operation in the marketplace to support a 916 device with a particular TEE, it must obtain a TAM certificate from a 917 CA or the raw public key of a TAM that is listed in the Trust Anchor 918 Store of the TEEP Agent. 920 5.2. Trust Anchors in a TEE 922 A TEE determines whether TA binaries are allowed to execute by 923 verifying whether their signature can be verified using 924 certificate(s) or raw public key(s) in the TEE's Trust Anchor Store. 925 The list is typically preloaded at manufacturing time, and can be 926 updated using the TEEP protocol if the TEE has some form of "Trust 927 Anchor Manager TA" that has Trust Anchors in its configuration data. 928 Thus, Trust Anchors can be updated similar to updating the 929 Personalization Data for any other TA, as discussed in Section 5.1. 931 5.3. Trust Anchors in a TAM 933 The Trust Anchor Store in a TAM consists of a list of Trust Anchors, 934 which are certificates that sign various device TEE certificates. A 935 TAM will accept a device for Trusted Component management if the TEE 936 in the device uses a TEE certificate that is chained to a certificate 937 or raw public key that the TAM trusts, is contained in an allow list, 938 is not found on a block list, and/or fulfills any other policy 939 criteria. 941 5.4. Scalability 943 This architecture uses a PKI (including self-signed certificates). 944 Trust Anchors exist on the devices to enable the TEE to authenticate 945 TAMs and Trusted Component Signers, and TAMs use Trust Anchors to 946 authenticate TEEs. When a PKI is used, many intermediate CA 947 certificates can chain to a root certificate, each of which can issue 948 many certificates. This makes the protocol highly scalable. New 949 factories that produce TEEs can join the ecosystem. In this case, 950 such a factory can get an intermediate CA certificate from one of the 951 existing roots without requiring that TAMs are updated with 952 information about the new device factory. Likewise, new TAMs can 953 join the ecosystem, providing they are issued a TAM certificate that 954 chains to an existing root whereby existing TEEs will be allowed to 955 be personalized by the TAM without requiring changes to the TEE 956 itself. This enables the ecosystem to scale, and avoids the need for 957 centralized databases of all TEEs produced or all TAMs that exist or 958 all Trusted Component Signers that exist. 960 5.5. Message Security 962 Messages created by a TAM are used to deliver Trusted Component 963 management commands to a device, and device attestation and messages 964 created by the device TEE to respond to TAM messages. 966 These messages are signed end-to-end between a TEEP Agent and a TAM. 967 Confidentiality is provided by encrypting sensitive payloads (such as 968 Personalization Data and attestation evidence), rather than 969 encrypting the messages themselves. Using encrypted payloads is 970 important to ensure that only the targeted device TEE or TAM is able 971 to decrypt and view the actual content. 973 6. TEEP Broker 975 A TEE and TAs often do not have the capability to directly 976 communicate outside of the hosting device. For example, 977 GlobalPlatform [GPTEE] specifies one such architecture. This calls 978 for a software module in the REE world to handle network 979 communication with a TAM. 981 A TEEP Broker is an application component running in the REE of the 982 device or an SDK that facilitates communication between a TAM and a 983 TEE. It also provides interfaces for Untrusted Applications to query 984 and trigger installation of Trusted Components that the application 985 needs to use. 987 An Untrusted Application might communicate with a TEEP Broker at 988 runtime to trigger Trusted Component installation itself, or an 989 Untrusted Application might simply have a metadata file that 990 describes the Trusted Components it depends on and the associated 991 TAM(s) for each Trusted Component, and an REE Application Installer 992 can inspect this application metadata file and invoke the TEEP Broker 993 to trigger Trusted Component installation on behalf of the Untrusted 994 Application without requiring the Untrusted Application to run first. 996 6.1. Role of the TEEP Broker 998 A TEEP Broker abstracts the message exchanges with a TEE in a device. 999 The input data is originated from a TAM or the first initialization 1000 call to trigger a Trusted Component installation. 1002 The Broker doesn't need to parse a message content received from a 1003 TAM that should be processed by a TEE (see the ProcessTeepMessage API 1004 in Section 6.2.1). When a device has more than one TEE, one TEEP 1005 Broker per TEE could be present in the REE. A TEEP Broker interacts 1006 with a TEEP Agent inside a TEE. 1008 A TAM message may indicate the target TEE where a Trusted Component 1009 should be installed. A compliant TEEP protocol should include a 1010 target TEE identifier for a TEEP Broker when multiple TEEs are 1011 present. 1013 The Broker relays the response messages generated from a TEEP Agent 1014 in a TEE to the TAM. 1016 The Broker only needs to return a (transport) error message if the 1017 TEE is not reachable for some reason. Other errors are represented 1018 as response messages returned from the TEE which will then be passed 1019 to the TAM. 1021 6.2. TEEP Broker Implementation Consideration 1023 As depicted in Figure 5, there are multiple ways in which a TEEP 1024 Broker can be implemented, with more or fewer layers being inside the 1025 TEE. For example, in model A, the model with the smallest TEE 1026 footprint, only the TEEP implementation is inside the TEE, whereas 1027 the TEEP/HTTP implementation is in the TEEP Broker outside the TEE. 1029 Model: A B C ... 1031 TEE TEE TEE 1032 +----------------+ | | | 1033 | TEEP | Agent | | | Agent 1034 | implementation | | | | 1035 +----------------+ v | | 1036 | | | 1037 +----------------+ ^ | | 1038 | TEEP/HTTP | Broker | | | 1039 | implementation | | | | 1040 +----------------+ | v | 1041 | | | 1042 +----------------+ | ^ | 1043 | HTTP | | | | 1044 | implementation | | | | 1045 +----------------+ | | v 1046 | | | 1047 +----------------+ | | ^ 1048 | TCP or QUIC | | | | Broker 1049 | implementation | | | | 1050 +----------------+ | | | 1051 REE REE REE 1053 Figure 5: TEEP Broker Models 1055 In other models, additional layers are moved into the TEE, increasing 1056 the TEE footprint, with the Broker either containing or calling the 1057 topmost protocol layer outside of the TEE. An implementation is free 1058 to choose any of these models. 1060 TEEP Broker implementers should consider methods of distribution, 1061 scope and concurrency on devices and runtime options. 1063 6.2.1. TEEP Broker APIs 1065 The following conceptual APIs exist from a TEEP Broker to a TEEP 1066 Agent: 1068 1. RequestTA: A notification from an REE application (e.g., an 1069 installer, or an Untrusted Application) that it depends on a 1070 given Trusted Component, which may or may not already be 1071 installed in the TEE. 1073 2. ProcessTeepMessage: A message arriving from the network, to be 1074 delivered to the TEEP Agent for processing. 1076 3. RequestPolicyCheck: A hint (e.g., based on a timer) that the TEEP 1077 Agent may wish to contact the TAM for any changes, without the 1078 device itself needing any particular change. 1080 4. ProcessError: A notification that the TEEP Broker could not 1081 deliver an outbound TEEP message to a TAM. 1083 For comparison, similar APIs may exist on the TAM side, where a 1084 Broker may or may not exist, depending on whether the TAM uses a TEE 1085 or not: 1087 1. ProcessConnect: A notification that an incoming TEEP session is 1088 being requested by a TEEP Agent. 1090 2. ProcessTeepMessage: A message arriving from the network, to be 1091 delivered to the TAM for processing. 1093 For further discussion on these APIs, see 1094 [I-D.ietf-teep-otrp-over-http]. 1096 6.2.2. TEEP Broker Distribution 1098 The Broker installation is commonly carried out at OEM time. A user 1099 can dynamically download and install a Broker on-demand. 1101 7. Attestation 1103 Attestation is the process through which one entity (an Attester) 1104 presents "evidence", in the form of a series of claims, to another 1105 entity (a Verifier), and provides sufficient proof that the claims 1106 are true. Different Verifiers may require different degrees of 1107 confidence in attestation proofs and not all attestations are 1108 acceptable to every verifier. A third entity (a Relying Party) can 1109 then use "attestation results", in the form of another series of 1110 claims, from a Verifier to make authorization decisions. (See 1111 [I-D.ietf-rats-architecture] for more discussion.) 1113 In TEEP, as depicted in Figure 6, the primary purpose of an 1114 attestation is to allow a device (the Attester) to prove to a TAM 1115 (the Relying Party) that a TEE in the device has particular 1116 properties, was built by a particular manufacturer, and/or is 1117 executing a particular TA. Other claims are possible; TEEP does not 1118 limit the claims that may appear in evidence or attestation results, 1119 but defines a minimal set of attestation result claims required for 1120 TEEP to operate properly. Extensions to these claims are possible. 1121 Other standards or groups may define the format and semantics of 1122 extended claims. 1124 +----------------+ 1125 | Device | +----------+ 1126 | +------------+ | Evidence | TAM | Evidence +----------+ 1127 | | TEE |------------->| (Relying |-------------->| Verifier | 1128 | | (Attester) | | | Party) |<--------------| | 1129 | +------------+ | +----------+ Attestation +----------+ 1130 +----------------+ Result 1132 Figure 6: TEEP Attestation Roles 1134 As of the writing of this specification, device and TEE attestations 1135 have not been standardized across the market. Different devices, 1136 manufacturers, and TEEs support different attestation protocols. In 1137 order for TEEP to be inclusive, it is agnostic to the format of 1138 evidence, allowing proprietary or standardized formats to be used 1139 between a TEE and a verifier (which may or may not be colocated in 1140 the TAM), as long as the format supports encryption of any 1141 information that is considered sensitive. 1143 However, it should be recognized that not all Verifiers may be able 1144 to process all proprietary forms of attestation evidence. Similarly, 1145 the TEEP protocol is agnostic as to the format of attestation 1146 results, and the protocol (if any) used between the TAM and a 1147 verifier, as long as they convey at least the required set of claims 1148 in some format. Note that the respective attestation algorithms are 1149 not defined in the TEEP protocol itself; see 1150 [I-D.ietf-rats-architecture] and [I-D.ietf-teep-protocol] for more 1151 discussion. 1153 There are a number of considerations that need to be considered when 1154 appraising evidence provided by a TEE, including: 1156 - What security measures a manufacturer takes when provisioning keys 1157 into devices/TEEs; 1159 - What hardware and software components have access to the 1160 attestation keys of the TEE; 1162 - The source or local verification of claims within an attestation 1163 prior to a TEE signing a set of claims; 1165 - The level of protection afforded to attestation keys against 1166 exfiltration, modification, and side channel attacks; 1168 - The limitations of use applied to TEE attestation keys; 1170 - The processes in place to discover or detect TEE breaches; and 1171 - The revocation and recovery process of TEE attestation keys. 1173 Some TAMs may require additional claims in order to properly 1174 authorize a device or TEE. The specific format for these additional 1175 claims are outside the scope of this specification, but the TEEP 1176 protocol allows these additional claims to be included in the 1177 attestation messages. 1179 For more discussion of the attestation and appraisal process, see the 1180 RATS Architecture [I-D.ietf-rats-architecture]. 1182 The following information is required for TEEP attestation: 1184 - Device Identifying Information: Attestation information may need 1185 to uniquely identify a device to the TAM. Unique device 1186 identification allows the TAM to provide services to the device, 1187 such as managing installed TAs, and providing subscriptions to 1188 services, and locating device-specific keying material to 1189 communicate with or authenticate the device. In some use cases it 1190 may be sufficient to identify only the class of the device. The 1191 security and privacy requirements regarding device identification 1192 will vary with the type of TA provisioned to the TEE. 1194 - TEE Identifying Information: The type of TEE that generated this 1195 attestation must be identified. This includes version 1196 identification information for hardware, firmware, and software 1197 version of the TEE, as applicable by the TEE type. TEE 1198 manufacturer information for the TEE is required in order to 1199 disambiguate the same TEE type created by different manufacturers 1200 and address considerations around manufacturer provisioning, 1201 keying and support for the TEE. 1203 - Freshness Proof: A claim that includes freshness information must 1204 be included, such as a nonce or timestamp. 1206 8. Algorithm and Attestation Agility 1208 RFC 7696 [RFC7696] outlines the requirements to migrate from one 1209 mandatory-to-implement cryptographic algorithm suite to another over 1210 time. This feature is also known as crypto agility. Protocol 1211 evolution is greatly simplified when crypto agility is considered 1212 during the design of the protocol. In the case of the TEEP protocol 1213 the diverse range of use cases, from trusted app updates for smart 1214 phones and tablets to updates of code on higher-end IoT devices, 1215 creates the need for different mandatory-to-implement algorithms 1216 already from the start. 1218 Crypto agility in TEEP concerns the use of symmetric as well as 1219 asymmetric algorithms. In the context of TEEP, symmetric algorithms 1220 are used for encryption and integrity protection of TA binaries and 1221 Personalization Data whereas the asymmetric algorithms are used for 1222 signing messages and managing symmetric keys. 1224 In addition to the use of cryptographic algorithms in TEEP, there is 1225 also the need to make use of different attestation technologies. A 1226 device must provide techniques to inform a TAM about the attestation 1227 technology it supports. For many deployment cases it is more likely 1228 for the TAM to support one or more attestation techniques whereas the 1229 device may only support one. 1231 9. Security Considerations 1233 9.1. Broker Trust Model 1235 The architecture enables the TAM to communicate, via a TEEP Broker, 1236 with the device's TEE to manage Trusted Components. Since the TEEP 1237 Broker runs in a potentially vulnerable REE, the TEEP Broker could, 1238 however, be (or be infected by) malware. As such, all TAM messages 1239 are signed and sensitive data is encrypted such that the TEEP Broker 1240 cannot modify or capture sensitive data, but the TEEP Broker can 1241 still conduct DoS attacks as discussed in Section 9.3. 1243 A TEEP Agent in a TEE is responsible for protecting against potential 1244 attacks from a compromised TEEP Broker or rogue malware in the REE. 1245 A rogue TEEP Broker might send corrupted data to the TEEP Agent, or 1246 launch a DoS attack by sending a flood of TEEP protocol requests. 1247 The TEEP Agent validates the signature of each TEEP protocol request 1248 and checks the signing certificate against its Trust Anchors. To 1249 mitigate DoS attacks, it might also add some protection scheme such 1250 as a threshold on repeated requests or number of TAs that can be 1251 installed. 1253 9.2. Data Protection 1255 It is the responsibility of the TAM to protect data on its servers. 1256 Similarly, it is the responsibility of the TEE implementation to 1257 provide protection of data against integrity and confidentiality 1258 attacks from outside the TEE. TEEs that provide isolation among TAs 1259 within the TEE are likewise responsible for protecting TA data 1260 against the REE and other TAs. For example, this can be used to 1261 protect one user's or tenant's data from compromise by another user 1262 or tenant, even if the attacker has TAs. 1264 The protocol between TEEP Agents and TAMs similarly is responsible 1265 for securely providing integrity and confidentiality protection 1266 against adversaries between them. Since the transport protocol under 1267 the TEEP protocol might be implemented outside a TEE, as discussed in 1268 Section 6, it cannot be relied upon for sufficient protection. The 1269 TEEP protocol provides integrity protection, but confidentiality must 1270 be provided by payload encryption, i.e., using encrypted TA binaries 1271 and encrypted attestation information. See [I-D.ietf-teep-protocol] 1272 for more discussion. 1274 9.3. Compromised REE 1276 It is possible that the REE of a device is compromised. We have 1277 already seen examples of attacks on the public Internet of billions 1278 of compromised devices being used to mount DDoS attacks. A 1279 compromised REE can be used for such an attack but it cannot tamper 1280 with the TEE's code or data in doing so. A compromised REE can, 1281 however, launch DoS attacks against the TEE. 1283 The compromised REE may terminate the TEEP Broker such that TEEP 1284 transactions cannot reach the TEE, or might drop or delay messages 1285 between a TAM and a TEEP Agent. However, while a DoS attack cannot 1286 be prevented, the REE cannot access anything in the TEE if it is 1287 implemented correctly. Some TEEs may have some watchdog scheme to 1288 observe REE state and mitigate DoS attacks against it but most TEEs 1289 don't have such a capability. 1291 In some other scenarios, the compromised REE may ask a TEEP Broker to 1292 make repeated requests to a TEEP Agent in a TEE to install or 1293 uninstall a Trusted Component. An installation or uninstallation 1294 request constructed by the TEEP Broker or REE will be rejected by the 1295 TEEP Agent because the request won't have the correct signature from 1296 a TAM to pass the request signature validation. 1298 This can become a DoS attack by exhausting resources in a TEE with 1299 repeated requests. In general, a DoS attack threat exists when the 1300 REE is compromised, and a DoS attack can happen to other resources. 1301 The TEEP architecture doesn't change this. 1303 A compromised REE might also request initiating the full flow of 1304 installation of Trusted Components that are not necessary. It may 1305 also repeat a prior legitimate Trusted Component installation 1306 request. A TEEP Agent implementation is responsible for ensuring 1307 that it can recognize and decline such repeated requests. It is also 1308 responsible for protecting the resource usage allocated for Trusted 1309 Component management. 1311 9.4. CA Compromise or Expiry of CA Certificate 1313 A root CA for TAM certificates might get compromised or its 1314 certificate might expire, or a Trust Anchor other than a root CA 1315 certificate may also expire or be compromised. TEEs are responsible 1316 for validating the entire TAM certificate chain, including the TAM 1317 certificate and any intermediate certificates up to the root 1318 certificate. Such validation includes checking for certificate 1319 revocation. 1321 If a TAM certificate chain validation fails, the TAM might be 1322 rejected by a TEEP Agent. To address this, some certificate chain 1323 update mechanism is expected from TAM operators, so that the TAM can 1324 get a new certificate chain that can be validated by a TEEP Agent. 1325 In addition, the Trust Anchor in the TEEP Agent's Trust Anchor Store 1326 may need to be updated. To address this, some TEE Trust Anchor 1327 update mechanism is expected from device OEMs. 1329 Similarly, a root CA for TEE certificates might get compromised or 1330 its certificate might expire, or a Trust Anchor other than a root CA 1331 certificate may also expire or be compromised. TAMs are responsible 1332 for validating the entire TEE certificate chain, including the TEE 1333 certificate and any intermediate certificates up to the root 1334 certificate. Such validation includes checking for certificate 1335 revocation. 1337 If a TEE certificate chain validation fails, the TEE might be 1338 rejected by a TAM, subject to the TAM's policy. To address this, 1339 some certificate chain update mechanism is expected from device OEMs, 1340 so that the TEE can get a new certificate chain that can be validated 1341 by a TAM. In addition, the Trust Anchor in the TAM's Trust Anchor 1342 Store may need to be updated. 1344 9.5. Compromised TAM 1346 Device TEEs are responsible for validating the supplied TAM 1347 certificates to determine that the TAM is trustworthy. 1349 9.6. Malicious TA Removal 1351 It is possible that a rogue developer distributes a malicious 1352 Untrusted Application and intends to get a malicious TA installed. 1353 Such a TA might be able to escape from malware detection by the REE, 1354 or access trusted resources within the TEE (but could not access 1355 other TEEs, or access other TA's if the TEE provides isolation 1356 between TAs). 1358 It is the responsibility of the TAM to not install malicious TAs in 1359 the first place. The TEEP architecture allows a TEEP Agent to decide 1360 which TAMs it trusts via Trust Anchors, and delegates the TA 1361 authenticity check to the TAMs it trusts. 1363 It may happen that a TA was previously considered trustworthy but is 1364 later found to be buggy or compromised. In this case, the TAM can 1365 initiate the removal of the TA by notifying devices to remove the TA 1366 (and potentially the REE or Device Owner to remove any Untrusted 1367 Application that depend on the TA). If the TAM does not currently 1368 have a connection to the TEEP Agent on a device, such a notification 1369 would occur the next time connectivity does exist. That is, to 1370 recover, the TEEP Agent must be able to reach out to the TAM, for 1371 example whenever the RequestPolicyCheck API (Section 6.2.1) is 1372 invoked by a timer or other event. 1374 Furthermore the policy in the Verifier in an attestation process can 1375 be updated so that any evidence that includes the malicious TA would 1376 result in an attestation failure. There is, however, a time window 1377 during which a malicious TA might be able to operate successfully, 1378 which is the validity time of the previous attestation result. For 1379 example, if the Verifier in Figure 6 is updated to treat a previously 1380 valid TA as no longer trustworthy, any attestation result it 1381 previously generated saying that the TA is valid will continue to be 1382 used until the attestation result expires. As such, the TAM's 1383 Verifier should take into account the acceptable time window when 1384 generating attestation results. See [I-D.ietf-rats-architecture] for 1385 further discussion. 1387 9.7. Certificate Expiry and Renewal 1389 TEE device certificates are expected to be long lived, longer than 1390 the lifetime of a device. A TAM certificate usually has a moderate 1391 lifetime of 2 to 5 years. A TAM should get renewed or rekeyed 1392 certificates. The root CA certificates for a TAM, which are embedded 1393 into the Trust Anchor Store in a device, should have long lifetimes 1394 that don't require device Trust Anchor updates. On the other hand, 1395 it is imperative that OEMs or device providers plan for support of 1396 Trust Anchor update in their shipped devices. 1398 For those cases where TEE devices are given certificates for which no 1399 good expiration date can be assigned the recommendations in 1400 Section 4.1.2.5 of [RFC5280] are applicable. 1402 9.8. Keeping Secrets from the TAM 1404 In some scenarios, it is desirable to protect the TA binary or 1405 Personalization Data from being disclosed to the TAM that distributes 1406 them. In such a scenario, the files can be encrypted end-to-end 1407 between a Trusted Component Signer and a TEE. However, there must be 1408 some means of provisioning the decryption key into the TEE and/or 1409 some means of the Trusted Component Signer securely learning a public 1410 key of the TEE that it can use to encrypt. One way to do this is for 1411 the Trusted Component Signer to run its own TAM so that it can 1412 distribute the decryption key via the TEEP protocol, and the key file 1413 can be a dependency in the manifest of the encrypted TA. Thus, the 1414 TEEP Agent would look at the Trusted Component manifest, determine 1415 there is a dependency with a TAM URI of the Trusted Component 1416 Signer's TAM. The Agent would then install the dependency, and then 1417 continue with the Trusted Component installation steps, including 1418 decrypting the TA binary with the relevant key. 1420 10. IANA Considerations 1422 This document does not require actions by IANA. 1424 11. Contributors 1426 - Andrew Atyeo, Intercede (andrew.atyeo@intercede.com) 1428 - Liu Dapeng, Alibaba Group (maxpassion@gmail.com) 1430 12. Acknowledgements 1432 We would like to thank Nick Cook, Minho Yoo, Brian Witten, Tyler Kim, 1433 Alin Mutu, Juergen Schoenwaelder, Nicolae Paladi, Sorin Faibish, Ned 1434 Smith, Russ Housley, Jeremy O'Donoghue, and Anders Rundgren for their 1435 feedback. 1437 13. Informative References 1439 [GPTEE] GlobalPlatform, "GlobalPlatform Device Technology: TEE 1440 System Architecture, v1.1", GlobalPlatform GPD_SPE_009, 1441 January 2017, . 1444 [I-D.ietf-rats-architecture] 1445 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 1446 W. Pan, "Remote Attestation Procedures Architecture", 1447 draft-ietf-rats-architecture-07 (work in progress), 1448 October 2020. 1450 [I-D.ietf-suit-manifest] 1451 Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, 1452 "A Concise Binary Object Representation (CBOR)-based 1453 Serialization Format for the Software Updates for Internet 1454 of Things (SUIT) Manifest", draft-ietf-suit-manifest-09 1455 (work in progress), July 2020. 1457 [I-D.ietf-teep-otrp-over-http] 1458 Thaler, D., "HTTP Transport for Trusted Execution 1459 Environment Provisioning: Agent-to- TAM Communication", 1460 draft-ietf-teep-otrp-over-http-08 (work in progress), 1461 October 2020. 1463 [I-D.ietf-teep-protocol] 1464 Tschofenig, H., Pei, M., Wheeler, D., Thaler, D., and A. 1465 Tsukamoto, "Trusted Execution Environment Provisioning 1466 (TEEP) Protocol", draft-ietf-teep-protocol-03 (work in 1467 progress), July 2020. 1469 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1470 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1471 . 1473 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1474 Housley, R., and W. Polk, "Internet X.509 Public Key 1475 Infrastructure Certificate and Certificate Revocation List 1476 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1477 . 1479 [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management 1480 Requirements", RFC 6024, DOI 10.17487/RFC6024, October 1481 2010, . 1483 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 1484 Agility and Selecting Mandatory-to-Implement Algorithms", 1485 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 1486 . 1488 [SGX] Intel, "Intel(R) Software Guard Extensions (Intel (R) 1489 SGX)", n.d., . 1493 [TrustZone] 1494 Arm, "Arm TrustZone Technology", n.d., 1495 . 1498 Authors' Addresses 1500 Mingliang Pei 1501 Broadcom 1503 EMail: mingliang.pei@broadcom.com 1505 Hannes Tschofenig 1506 Arm Limited 1508 EMail: hannes.tschofenig@arm.com 1510 Dave Thaler 1511 Microsoft 1513 EMail: dthaler@microsoft.com 1515 David Wheeler 1516 Intel 1518 EMail: david.m.wheeler@intel.com