idnits 2.17.1 draft-ietf-teep-architecture-17.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 date (19 April 2022) is 737 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-15 == Outdated reference: A later version (-25) exists of draft-ietf-suit-manifest-16 == Outdated reference: A later version (-15) exists of draft-ietf-teep-otrp-over-http-13 == Outdated reference: A later version (-18) exists of draft-ietf-teep-protocol-08 Summary: 0 errors (**), 0 flaws (~~), 5 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: 21 October 2022 Arm Limited 6 D. Thaler 7 Microsoft 8 D. Wheeler 9 Amazon 10 19 April 2022 12 Trusted Execution Environment Provisioning (TEEP) Architecture 13 draft-ietf-teep-architecture-17 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 https://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 21 October 2022. 41 Copyright Notice 43 Copyright (c) 2022 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 (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 8 62 3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 8 63 3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 8 64 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9 65 4.1. System Components . . . . . . . . . . . . . . . . . . . . 9 66 4.2. Multiple TEEs in a Device . . . . . . . . . . . . . . . . 11 67 4.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 13 68 4.4. Untrusted Apps, Trusted Apps, and Personalization Data . 15 69 4.4.1. Example: Application Delivery Mechanisms in Intel 70 SGX . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 4.4.2. Example: Application Delivery Mechanisms in Arm 72 TrustZone . . . . . . . . . . . . . . . . . . . . . . 17 73 4.5. Entity Relations . . . . . . . . . . . . . . . . . . . . 17 74 5. Keys and Certificate Types . . . . . . . . . . . . . . . . . 19 75 5.1. Trust Anchors in a TEEP Agent . . . . . . . . . . . . . . 21 76 5.2. Trust Anchors in a TEE . . . . . . . . . . . . . . . . . 21 77 5.3. Trust Anchors in a TAM . . . . . . . . . . . . . . . . . 21 78 5.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 22 79 5.5. Message Security . . . . . . . . . . . . . . . . . . . . 22 80 6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 22 81 6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 23 82 6.2. TEEP Broker Implementation Consideration . . . . . . . . 23 83 6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 24 84 6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 25 85 7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 25 86 8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 28 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 88 9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 28 89 9.2. Data Protection . . . . . . . . . . . . . . . . . . . . . 29 90 9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 30 91 9.4. CA Compromise or Expiry of CA Certificate . . . . . . . . 31 92 9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 31 93 9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 31 94 9.7. TEE Certificate Expiry and Renewal . . . . . . . . . . . 32 95 9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 33 96 9.9. REE Privacy . . . . . . . . . . . . . . . . . . . . . . . 33 98 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 99 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34 100 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 101 13. Informative References . . . . . . . . . . . . . . . . . . . 34 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 104 1. Introduction 106 Applications executing in a device are exposed to many different 107 attacks intended to compromise the execution of the application or 108 reveal the data upon which those applications are operating. These 109 attacks increase with the number of other applications on the device, 110 with such other applications coming from potentially untrustworthy 111 sources. The potential for attacks further increases with the 112 complexity of features and applications on devices, and the 113 unintended interactions among those features and applications. The 114 danger of attacks on a system increases as the sensitivity of the 115 applications or data on the device increases. As an example, 116 exposure of emails from a mail client is likely to be of concern to 117 its owner, but a compromise of a banking application raises even 118 greater concerns. 120 The Trusted Execution Environment (TEE) concept is designed to let 121 applications execute in a protected environment that enforces that 122 any code within that environment cannot be tampered with, and that 123 any data used by such code cannot be read or tampered with by any 124 code outside that environment, including by a commodity operating 125 system (if present). In a system with multiple TEEs, this also means 126 that code in one TEE cannot be read or tampered with by code in 127 another TEE. 129 This separation reduces the possibility of a successful attack on 130 application components and the data contained inside the TEE. 131 Typically, application components are chosen to execute inside a TEE 132 because those application components perform security sensitive 133 operations or operate on sensitive data. An application component 134 running inside a TEE is referred to as a Trusted Application (TA), 135 while an application running outside any TEE, i.e., in the Rich 136 Execution Environment (REE), is referred to as an Untrusted 137 Application. In the example of a banking application, code that 138 relates to the authentication protocol could reside in a TA while the 139 application logic including HTTP protocol parsing could be contained 140 in the Untrusted Application. In addition, processing of credit card 141 numbers or account balances could be done in a TA as it is sensitive 142 data. The precise code split is ultimately a decision of the 143 developer based on the assets he or she wants to protect according to 144 the threat model. 146 TEEs are typically used in cases where a software or data asset needs 147 to be protected from unauthorized entities that may include the owner 148 (or pwner) or possesser of a device. This situation arises for 149 example in gaming consoles where anti-cheat protection is a concern, 150 devices such as ATMs or IoT devices placed in locations where 151 attackers might have physical access, cell phones or other devices 152 used for mobile payments, and hosted cloud environments. Such 153 environments can be thought of as hybrid devices where one user or 154 administrator controls the REE and a different (remote) user or 155 administrator controls a TEE in the same physical device. 156 It may also be the case in some constrained devices that there is no 157 REE (only a TEE) and there may be no local "user" per se, only a 158 remote TEE administrator. For further discussion of such 159 confidential computing use cases and threat model, see [CC-Overview] 160 and [CC-Technical-Analysis]. 162 TEEs use hardware enforcement combined with software protection to 163 secure TAs and its data. TEEs typically offer a more limited set of 164 services to TAs than is normally available to Untrusted Applications. 166 Not all TEEs are the same, however, and different vendors may have 167 different implementations of TEEs with different security properties, 168 different features, and different control mechanisms to operate on 169 TAs. Some vendors may themselves market multiple different TEEs with 170 different properties attuned to different markets. A device vendor 171 may integrate one or more TEEs into their devices depending on market 172 needs. 174 To simplify the life of TA developers interacting with TAs in a TEE, 175 an interoperable protocol for managing TAs running in different TEEs 176 of various devices is needed. This software update protocol needs to 177 make sure that compatible trusted and untrusted components (if any) 178 of an application are installed on the correct device. In this TEE 179 ecosystem, there often arises a need for an external trusted party to 180 verify the identity, claims, and rights of TA developers, devices, 181 and their TEEs. This external trusted party is the Trusted 182 Application Manager (TAM). 184 The Trusted Execution Environment Provisioning (TEEP) protocol 185 addresses the following problems: 187 * An installer of an Untrusted Application that depends on a given 188 TA wants to request installation of that TA in the device's TEE so 189 that the Untrusted Application can complete, but the TEE needs to 190 verify whether such a TA is actually authorized to run in the TEE 191 and consume potentially scarce TEE resources. 193 * A TA developer providing a TA whose code itself is considered 194 confidential wants to determine security-relevant information of a 195 device before allowing their TA to be provisioned to the TEE 196 within the device. An example is the verification of the type of 197 TEE included in a device and that it is capable of providing the 198 security protections required. 200 * A TEE in a device wants to determine whether an entity that wants 201 to manage a TA in the device is authorized to manage TAs in the 202 TEE, and what TAs the entity is permitted to manage. 204 * A Device Administrator wants to determine if a TA exists (is 205 installed) on a device (in the TEE), and if not, install the TA in 206 the TEE. 208 * A Device Administrator wants to check whether a TA in a device's 209 TEE is the most up-to-date version, and if not, update the TA in 210 the TEE. 212 * A Device Administrator wants to remove a TA from a device's TEE if 213 the TA developer is no longer maintaining that TA, when the TA has 214 been revoked, or is not used for other reasons anymore (e.g., due 215 to an expired subscription). 217 For TEEs that simply verify and load signed TA's from an untrusted 218 filesystem, classic application distribution protocols can be used 219 without modification. The problems in the bullets above, on the 220 other hand, require a new protocol, i.e., the TEEP protocol. The 221 TEEP protocol is a solution for TEEs that can install and enumerate 222 TAs in a TEE-secured location where another domain-specific protocol 223 standard (e.g., [GSMA], [OTRP]) that meets the needs is not already 224 in use. 226 2. Terminology 228 The following terms are used: 230 * App Store: An online location from which Untrusted Applications 231 can be downloaded. 233 * Device: A physical piece of hardware that hosts one or more TEEs, 234 often along with an REE. 236 * Device Administrator: An entity that is responsible for 237 administration of a device, which could be the Device Owner. A 238 Device Administrator has privileges on the device to install and 239 remove Untrusted Applications and TAs, approve or reject Trust 240 Anchors, and approve or reject TA developers, among possibly other 241 privileges on the device. A Device Administrator can manage the 242 list of allowed TAMs by modifying the list of Trust Anchors on the 243 device. Although a Device Administrator may have privileges and 244 device-specific controls to locally administer a device, the 245 Device Administrator may choose to remotely administer a device 246 through a TAM. 248 * Device Owner: A device is always owned by someone. In some cases, 249 it is common for the (primary) device user to also own the device, 250 making the device user/owner also the Device Administrator. In 251 enterprise environments it is more common for the enterprise to 252 own the device, and any device user has no or limited 253 administration rights. In this case, the enterprise appoints a 254 Device Administrator that is not the device owner. 256 * Device User: A human being that uses a device. Many devices have 257 a single device user. Some devices have a primary device user 258 with other human beings as secondary device users (e.g., a parent 259 allowing children to use their tablet or laptop). Other devices 260 are not used by a human being and hence have no device user. 261 Relates to Device Owner and Device Administrator. 263 * Personalization Data: A set of configuration data that is specific 264 to the device or user. The Personalization Data may depend on the 265 type of TEE, a particular TEE instance, the TA, and even the user 266 of the device; an example of Personalization Data might be a 267 secret symmetric key used by a TA to communicate with some 268 service. 270 * Raw Public Key: A raw public key consists of only the algorithm 271 identifier (type) of the key and the cryptographic public key 272 material, such as the SubjectPublicKeyInfo structure of a PKIX 273 certificate [RFC5280]. Other serialization formats that do not 274 rely on ASN.1 may also be used. 276 * Rich Execution Environment (REE): An environment that is provided 277 and governed by a typical OS (e.g., Linux, Windows, Android, iOS), 278 potentially in conjunction with other supporting operating systems 279 and hypervisors; it is outside of the TEE(s) managed by the TEEP 280 protocol. This environment and applications running on it are 281 considered untrusted (or more precisely, less trusted than a TEE). 283 * Trust Anchor: As defined in [RFC6024] and 284 [I-D.ietf-suit-architecture], "A trust anchor represents an 285 authoritative entity via a public key and associated data. The 286 public key is used to verify digital signatures, and the 287 associated data is used to constrain the types of information for 288 which the trust anchor is authoritative." The Trust Anchor may be 289 a certificate, a raw public key or other structure, as 290 appropriate. It can be a non-root certificate when it is a 291 certificate. 293 * Trust Anchor Store: As defined in [RFC6024], "A trust anchor store 294 is a set of one or more trust anchors stored in a device... A 295 device may have more than one trust anchor store, each of which 296 may be used by one or more applications." As noted in 297 [I-D.ietf-suit-architecture], a Trust Anchor Store must resist 298 modification against unauthorized insertion, deletion, and 299 modification. 301 * Trusted Application (TA): An application (or, in some 302 implementations, an application component) that runs in a TEE. 304 * Trusted Application Manager (TAM): An entity that manages Trusted 305 Applications and other Trusted Components running in TEEs of 306 various devices. 308 * Trusted Component: A set of code and/or data in a TEE managed as a 309 unit by a Trusted Application Manager. Trusted Applications and 310 Personalization Data are thus managed by being included in Trusted 311 Components. Trusted OS code or trusted firmware can also be 312 expressed as Trusted Components that a Trusted Component depends 313 on. 315 * Trusted Component Developer: An entity that develops one or more 316 Trusted Components. 318 * Trusted Component Signer: An entity that signs a Trusted Component 319 with a key that a TEE will trust. The signer might or might not 320 be the same entity as the Trusted Component Developer. For 321 example, a Trusted Component might be signed (or re-signed) by a 322 Device Administrator if the TEE will only trust the Device 323 Administrator. A Trusted Component might also be encrypted, if 324 the code is considered confidential. 326 * Trusted Execution Environment (TEE): An execution environment that 327 enforces that only authorized code can execute within the TEE, and 328 data used by that code cannot be read or tampered with by code 329 outside the TEE. A TEE also generally has a device unique 330 credential that cannot be cloned. There are multiple technologies 331 that can be used to implement a TEE, and the level of security 332 achieved varies accordingly. In addition, TEEs typically use an 333 isolation mechanism between Trusted Applications to ensure that 334 one TA cannot read, modify or delete the data and code of another 335 TA. 337 * Untrusted Application: An application running in an REE. An 338 Untrusted Application might depend on one or more TAs. 340 3. Use Cases 342 3.1. Payment 344 A payment application in a mobile device requires high security and 345 trust in the hosting device. Payments initiated from a mobile device 346 can use a Trusted Application to provide strong identification and 347 proof of transaction. 349 For a mobile payment application, some biometric identification 350 information could also be stored in a TEE. The mobile payment 351 application can use such information for unlocking the device and for 352 local identification of the user. 354 A trusted user interface (UI) may be used in a mobile device to 355 prevent malicious software from stealing sensitive user input data. 356 Such an implementation often relies on a TEE for providing access to 357 peripherals, such as PIN input or a trusted display, so that the REE 358 cannot observe or tamper with the user input or output. 360 3.2. Authentication 362 For better security of authentication, a device may store its keys 363 and cryptographic libraries inside a TEE limiting access to 364 cryptographic functions via a well-defined interface and thereby 365 reducing access to keying material. 367 3.3. Internet of Things 369 Weak security in Internet of Things (IoT) devices has been posing 370 threats to critical infrastructure, i.e., assets that are essential 371 for the functioning of a society and economy. It is desirable that 372 IoT devices can prevent malware from manipulating actuators (e.g., 373 unlocking a door), or stealing or modifying sensitive data, such as 374 authentication credentials in the device. A TEE can be the best way 375 to implement such IoT security functions. 377 3.4. Confidential Cloud Computing 379 A tenant can store sensitive data, such as customer details or credit 380 card numbers, in a TEE in a cloud computing server such that only the 381 tenant can access the data, preventing the cloud hosting provider 382 from accessing the data. A tenant can run TAs inside a server TEE 383 for secure operation and enhanced data security. This provides 384 benefits not only to tenants with better data security but also to 385 cloud hosting providers for reduced liability and increased cloud 386 adoption. 388 4. Architecture 390 4.1. System Components 392 Figure 1 shows the main components in a typical device with an REE 393 and a TEE. Full descriptions of components not previously defined 394 are provided below. Interactions of all components are further 395 explained in the following paragraphs. 397 +-------------------------------------------+ 398 | Device | Trusted Component 399 | +--------+ | Signer 400 | +-------------+ | |-----------+ | 401 | | TEE-1 | | TEEP |---------+ | | 402 | | +--------+ | +----| Broker | | | | +--------+ | 403 | | | TEEP | | | | |<---+ | | +->| |<-+ 404 | | | Agent |<----+ | | | | | +-| TAM-1 | 405 | | +--------+ | | |<-+ | | +->| | |<-+ 406 | | | +--------+ | | | | +--------+ | 407 | | +---+ +---+ | | | | | TAM-2 | | 408 | +-->|TA1| |TA2| | +-------+ | | | +--------+ | 409 | | | | | | |<---------| App-2 |--+ | | | 410 | | | +---+ +---+ | +-------+ | | | Device Administrator 411 | | +-------------+ | App-1 | | | | 412 | | | | | | | 413 | +--------------------| |---+ | | 414 | | |--------+ | 415 | +-------+ | 416 +-------------------------------------------+ 418 Figure 1: Notional Architecture of TEEP 420 * Trusted Component Signers and Device Administrators utilize the 421 services of a TAM to manage TAs on devices. Trusted Component 422 Signers do not directly interact with devices. Device 423 Administators may elect to use a TAM for remote administration of 424 TAs instead of managing each device directly. 426 * Trusted Application Manager (TAM): A TAM is responsible for 427 performing lifecycle management activity on Trusted Components on 428 behalf of Trusted Component Signers and Device Administrators. 429 This includes installation and deletion of Trusted Components, and 430 may include, for example, over-the-air updates to keep Trusted 431 Components up-to-date and clean up when Trusted Components should 432 be removed. TAMs may provide services that make it easier for 433 Trusted Component Signers or Device Administators to use the TAM's 434 service to manage multiple devices, although that is not required 435 of a TAM. 437 The TAM performs its management of Trusted Components on the 438 device through interactions with a device's TEEP Broker, which 439 relays messages between a TAM and a TEEP Agent running inside the 440 TEE. TEEP authentication is performed between a TAM and a TEEP 441 Agent. 443 As shown in Figure 1, the TAM cannot directly contact a TEEP 444 Agent, but must wait for the TEEP Broker to contact the TAM 445 requesting a particular service. This architecture is intentional 446 in order to accommodate network and application firewalls that 447 normally protect user and enterprise devices from arbitrary 448 connections from external network entities. 450 A TAM may be publicly available for use by many Trusted Component 451 Signers, or a TAM may be private, and accessible by only one or a 452 limited number of Trusted Component Signers. It is expected that 453 many enterprises, manufacturers, and network carriers will run 454 their own private TAM. 456 A Trusted Component Signer or Device Administrator chooses a 457 particular TAM based on whether the TAM is trusted by a device or 458 set of devices. The TAM is trusted by a device if the TAM's 459 public key is, or chains up to, an authorized Trust Anchor in the 460 device. A Trusted Component Signer or Device Administrator may 461 run their own TAM, but the devices they wish to manage must 462 include this TAM's public key or certificate, or a certificate it 463 chains up to, in the Trust Anchor Store. 465 A Trusted Component Signer or Device Administrator is free to 466 utilize multiple TAMs. This may be required for managing Trusted 467 Components on multiple different types of devices from different 468 manufacturers, or mobile devices on different network carriers, 469 since the Trust Anchor Store on these different devices may 470 contain keys for different TAMs. A Device Administrator may be 471 able to add their own TAM's public key or certificate, or a 472 certificate it chains up to, to the Trust Anchor Store on all 473 their devices, overcoming this limitation. 475 Any entity is free to operate a TAM. For a TAM to be successful, 476 it must have its public key or certificate installed in a device's 477 Trust Anchor Store. A TAM may set up a relationship with device 478 manufacturers or network carriers to have them install the TAM's 479 keys in their device's Trust Anchor Store. Alternatively, a TAM 480 may publish its certificate and allow Device Administrators to 481 install the TAM's certificate in their devices as an after-market 482 action. 484 * TEEP Broker: A TEEP Broker is an application component running in 485 a Rich Execution Environment (REE) that enables the message 486 protocol exchange between a TAM and a TEE in a device. A TEEP 487 Broker does not process messages on behalf of a TEE, but merely is 488 responsible for relaying messages from the TAM to the TEE, and for 489 returning the TEE's responses to the TAM. In devices with no REE 490 (e.g., a microcontroller where all code runs in an environment 491 that meets the definition of a Trusted Execution Environment in 492 Section 2), the TEEP Broker would be absent and instead the TEEP 493 protocol transport would be implemented inside the TEE itself. 495 * TEEP Agent: The TEEP Agent is a processing module running inside a 496 TEE that receives TAM requests (typically relayed via a TEEP 497 Broker that runs in an REE). A TEEP Agent in the TEE may parse 498 requests or forward requests to other processing modules in a TEE, 499 which is up to a TEE provider's implementation. A response 500 message corresponding to a TAM request is sent back to the TAM, 501 again typically relayed via a TEEP Broker. 503 * Certification Authority (CA): A CA is an entity that issues 504 digital certificates (especially X.509 certificates) and vouches 505 for the binding between the data items in a certificate [RFC4949]. 506 Certificates are then used for authenticating a device, a TAM, or 507 a Trusted Component Signer, as discussed in Section 5. The CAs do 508 not need to be the same; different CAs can be chosen by each TAM, 509 and different device CAs can be used by different device 510 manufacturers. 512 4.2. Multiple TEEs in a Device 514 Some devices might implement multiple TEEs. In these cases, there 515 might be one shared TEEP Broker that interacts with all the TEEs in 516 the device. However, some TEEs (for example, SGX [SGX]) present 517 themselves as separate containers within memory without a controlling 518 manager within the TEE. As such, there might be multiple TEEP 519 Brokers in the REE, where each TEEP Broker communicates with one or 520 more TEEs associated with it. 522 It is up to the REE and the Untrusted Applications how they select 523 the correct TEEP Broker. Verification that the correct TA has been 524 reached then becomes a matter of properly verifying TA attestations, 525 which are unforgeable. 527 The multiple TEEP Broker approach is shown in the diagram below. For 528 brevity, TEEP Broker 2 is shown interacting with only one TAM and 529 Untrusted Application and only one TEE, but no such limitations are 530 intended to be implied in the architecture. 532 +-------------------------------------------+ Trusted 533 | Device | Component 534 | | Signer 535 | +-------------+ | | 536 | | TEE-1 | | | 537 | | +-------+ | +--------+ | +--------+ | 538 | | | TEEP | | | TEEP |------------->| |<-+ 539 | | | Agent |<----------| Broker | | | | TA 540 | | | 1 | | | 1 |---------+ | | 541 | | +-------+ | | | | | | | 542 | | | | |<---+ | | | | 543 | | +---+ +---+ | | | | | | +-| TAM-1 |Policy 544 | | |TA1| |TA2| | | |<-+ | | +->| | |<-+ 545 | +-->| | | |<---+ +--------+ | | | | +--------+ | 546 | | | +---+ +---+ | | | | | | TAM-2 | | 547 | | | | | +-------+ | | | +--------+ | 548 | | +-------------+ +-----| App-2 |--+ | | ^ | 549 | | +-------+ | | | | Device 550 | +--------------------| App-1 | | | | | Administrator 551 | +------| | | | | | 552 | +-----------|-+ | |---+ | | | 553 | | TEE-2 | | | |--------+ | | 554 | | +------+ | | | |------+ | | 555 | | | TEEP | | | +-------+ | | | 556 | | | Agent|<-----+ | | | 557 | | | 2 | | | | | | | 558 | | +------+ | | | | | | 559 | | | | | | | | 560 | | +---+ | | | | | | 561 | | |TA3|<----+ | | +----------+ | | | 562 | | | | | | | TEEP |<--+ | | 563 | | +---+ | +--| Broker | | | 564 | | | | 2 |----------------+ 565 | +-------------+ +----------+ | 566 | | 567 +-------------------------------------------+ 569 Figure 2: Notional Architecture of TEEP with multiple TEEs 571 In the diagram above, TEEP Broker 1 controls interactions with the 572 TAs in TEE-1, and TEEP Broker 2 controls interactions with the TAs in 573 TEE-2. This presents some challenges for a TAM in completely 574 managing the device, since a TAM may not interact with all the TEEP 575 Brokers on a particular platform. In addition, since TEEs may be 576 physically separated, with wholly different resources, there may be 577 no need for TEEP Brokers to share information on installed Trusted 578 Components or resource usage. 580 4.3. Multiple TAMs and Relationship to TAs 582 As shown in Figure 2, a TEEP Broker provides communication between 583 one or more TEEP Agents and one or more TAMs. The selection of which 584 TAM to interact with might be made with or without input from an 585 Untrusted Application, but is ultimately the decision of a TEEP 586 Agent. 588 A TEEP Agent is assumed to be able to determine, for any given 589 Trusted Component, whether that Trusted Component is installed (or 590 minimally, is running) in a TEE with which the TEEP Agent is 591 associated. 593 Each Trusted Component is digitally signed, protecting its integrity, 594 and linking the Trusted Component back to the Trusted Component 595 Signer. The Trusted Component Signer is often the Trusted Component 596 Developer, but in some cases might be another party such as a Device 597 Administrator or other party to whom the code has been licensed (in 598 which case the same code might be signed by multiple licensees and 599 distributed as if it were different TAs). 601 A Trusted Component Signer selects one or more TAMs and communicates 602 the Trusted Component(s) to the TAM. For example, the Trusted 603 Component Signer might choose TAMs based upon the markets into which 604 the TAM can provide access. There may be TAMs that provide services 605 to specific types of devices, or device operating systems, or 606 specific geographical regions or network carriers. A Trusted 607 Component Signer may be motivated to utilize multiple TAMs in order 608 to maximize market penetration and availability on multiple types of 609 devices. This means that the same Trusted Component will often be 610 available through multiple TAMs. 612 When the developer of an Untrusted Application that depends on a 613 Trusted Component publishes the Untrusted Application to an app store 614 or other app repository, the developer optionally binds the Untrusted 615 Application with a manifest that identifies what TAMs can be 616 contacted for the Trusted Component. In some situations, a Trusted 617 Component may only be available via a single TAM - this is likely the 618 case for enterprise applications or Trusted Component Signers serving 619 a closed community. For broad public apps, there will likely be 620 multiple TAMs in the Untrusted Application's manifest - one servicing 621 one brand of mobile device and another servicing a different 622 manufacturer, etc. Because different devices and different 623 manufacturers trust different TAMs, the manifest can include multiple 624 TAMs that support the required Trusted Component. 626 When a TEEP Broker receives a request (see the RequestTA API in 627 Section 6.2.1) from an Untrusted Application to install a Trusted 628 Component, a list of TAM URIs may be provided for that Trusted 629 Component, and the request is passed to the TEEP Agent. If the TEEP 630 Agent decides that the Trusted Component needs to be installed, the 631 TEEP Agent selects a single TAM URI that is consistent with the list 632 of trusted TAMs provisioned in the TEEP Agent, invokes the HTTP 633 transport for TEEP to connect to the TAM URI, and begins a TEEP 634 protocol exchange. When the TEEP Agent subsequently receives the 635 Trusted Component to install and the Trusted Component's manifest 636 indicates dependencies on any other trusted components, each 637 dependency can include a list of TAM URIs for the relevant 638 dependency. If such dependencies exist that are prerequisites to 639 install the Trusted Component, then the TEEP Agent recursively 640 follows the same procedure for each dependency that needs to be 641 installed or updated, including selecting a TAM URI that is 642 consistent with the list of trusted TAMs provisioned on the device, 643 and beginning a TEEP exchange. If multiple TAM URIs are considered 644 trusted, only one needs to be contacted and they can be attempted in 645 some order until one responds. 647 Separate from the Untrusted Application's manifest, this framework 648 relies on the use of the manifest format in [I-D.ietf-suit-manifest] 649 for expressing how to install a Trusted Component, as well as any 650 dependencies on other TEE components and versions. That is, 651 dependencies from Trusted Components on other Trusted Components can 652 be expressed in a SUIT manifest, including dependencies on any other 653 TAs, trusted OS code (if any), or trusted firmware. Installation 654 steps can also be expressed in a SUIT manifest. 656 For example, TEEs compliant with GlobalPlatform [GPTEE] may have a 657 notion of a "security domain" (which is a grouping of one or more TAs 658 installed on a device, that can share information within such a 659 group) that must be created and into which one or more TAs can then 660 be installed. It is thus up to the SUIT manifest to express a 661 dependency on having such a security domain existing or being created 662 first, as appropriate. 664 Updating a Trusted Component may cause compatibility issues with any 665 Untrusted Applications or other components that depend on the updated 666 Trusted Component, just like updating the OS or a shared library 667 could impact an Untrusted Application. Thus, an implementation needs 668 to take into account such issues. 670 4.4. Untrusted Apps, Trusted Apps, and Personalization Data 672 In TEEP, there is an explicit relationship and dependence between an 673 Untrusted Application in an REE and one or more TAs in a TEE, as 674 shown in Figure 2. For most purposes, an Untrusted Application that 675 uses one or more TAs in a TEE appears no different from any other 676 Untrusted Application in the REE. However, the way the Untrusted 677 Application and its corresponding TAs are packaged, delivered, and 678 installed on the device can vary. The variations depend on whether 679 the Untrusted Application and TA are bundled together or are provided 680 separately, and this has implications to the management of the TAs in 681 a TEE. In addition to the Untrusted Application and TA(s), the TA(s) 682 and/or TEE may also require additional data to personalize the TA to 683 the device or a user. Implementations must support encryption to 684 preserve the confidentiality and integrity of such Personalized Data, 685 which may potentially contain sensitive data. Other than the 686 requirement to support confidentiality and integrity protection, the 687 TEEP architecture places no limitations or requirements on the 688 Personalization Data. 690 There are multiple possible cases for bundling of an Untrusted 691 Application, TA(s), and Personalization Data. Such cases include 692 (possibly among others): 694 1. The Untrusted Application, TA(s), and Personalization Data are 695 all bundled together in a single package by a Trusted Component 696 Signer and either provided to the TEEP Broker through the TAM, or 697 provided separately (with encrypted Personalization Data), with 698 key material needed to decrypt and install the Personalization 699 Data and TA provided by a TAM. 701 2. The Untrusted Application and the TA(s) are bundled together in a 702 single package, which a TAM or a publicly accessible app store 703 maintains, and the Personalization Data is separately provided by 704 the Personalization Data provider's TAM. 706 3. All components are independent packages. The Untrusted 707 Application is installed through some independent or device- 708 specific mechanism, and one or more TAMs provide (directly or 709 indirectly by reference) the TA(s) and Personalization Data. 711 4. The TA(s) and Personalization Data are bundled together into a 712 package provided by a TAM, while the Untrusted Application is 713 installed through some independent or device-specific mechanism 714 such as an app store. 716 5. Encrypted Personalization Data is bundled into a package 717 distributed with the Untrusted Application, while the TA(s) and 718 key material needed to decrypt and install the Personalization 719 Data are in a separate package provided by a TAM. 721 The TEEP protocol can treat each TA, any dependencies the TA has, and 722 Personalization Data as separate Trusted Components with separate 723 installation steps that are expressed in SUIT manifests, and a SUIT 724 manifest might contain or reference multiple binaries (see 725 [I-D.ietf-suit-manifest] for more details). The TEEP Agent is 726 responsible for handling any installation steps that need to be 727 performed inside the TEE, such as decryption of private TA binaries 728 or Personalization Data. 730 In order to better understand these cases, it is helpful to review 731 actual implementations of TEEs and their application delivery 732 mechanisms. 734 4.4.1. Example: Application Delivery Mechanisms in Intel SGX 736 In Intel Software Guard Extensions (SGX), the Untrusted Application 737 and TA are typically bundled into the same package (Case 2). The TA 738 exists in the package as a shared library (.so or .dll). The 739 Untrusted Application loads the TA into an SGX enclave when the 740 Untrusted Application needs the TA. This organization makes it easy 741 to maintain compatibility between the Untrusted Application and the 742 TA, since they are updated together. It is entirely possible to 743 create an Untrusted Application that loads an external TA into an SGX 744 enclave, and use that TA (Cases 3-5). In this case, the Untrusted 745 Application would require a reference to an external file or download 746 such a file dynamically, place the contents of the file into memory, 747 and load that as a TA. Obviously, such file or downloaded content 748 must be properly formatted and signed for it to be accepted by the 749 SGX TEE. 751 In SGX, any Personalization Data is normally loaded into the SGX 752 enclave (the TA) after the TA has started. Although it is possible 753 with SGX to include the Untrusted Application in an encrypted package 754 along with Personalization Data (Cases 1 and 5), there are no 755 instances of this known to be in use at this time, since such a 756 construction would require a special installation program and SGX TA 757 (which might or might not be the TEEP Agent itself based on the 758 implementation) to receive the encrypted package, decrypt it, 759 separate it into the different elements, and then install each one. 760 This installation is complex because the Untrusted Application 761 decrypted inside the TEE must be passed out of the TEE to an 762 installer in the REE which would install the Untrusted Application. 763 Finally, the Personalization Data would need to be sent out of the 764 TEE (encrypted in an SGX enclave-to-enclave manner) to the REE's 765 installation app, which would pass this data to the installed 766 Untrusted Application, which would in turn send this data to the SGX 767 enclave (TA). This complexity is due to the fact that each SGX 768 enclave is separate and does not have direct communication to other 769 SGX enclaves. 771 As long as signed files (TAs and/or Personalization Data) are 772 installed into an untrusted filesystem and trust is verified by the 773 TEE at load time, classic distribution mechanisms can be used. Some 774 uses of SGX, however, allow a model where a TA can be dynamically 775 installed into an SGX enclave that provides a runtime platform. The 776 TEEP protocol can be used in such cases, where the runtime platform 777 could include a TEEP Agent. 779 4.4.2. Example: Application Delivery Mechanisms in Arm TrustZone 781 In Arm TrustZone [TrustZone] for A-class devices, the Untrusted 782 Application and TA may or may not be bundled together. This differs 783 from SGX since in TrustZone the TA lifetime is not inherently tied to 784 a specific Untrused Application process lifetime as occurs in SGX. A 785 TA is loaded by a trusted OS running in the TEE such as a 786 GlobalPlatform [GPTEE] compliant TEE, where the trusted OS is 787 separate from the OS in the REE. Thus Cases 2-4 are equally 788 applicable. In addition, it is possible for TAs to communicate with 789 each other without involving any Untrusted Application, and so the 790 complexity of Cases 1 and 5 are lower than in the SGX example, though 791 still more complex than Cases 2-4. 793 A trusted OS running in the TEE (e.g., OP-TEE) that supports loading 794 and verifying signed TAs from an untrusted filesystem can, like SGX, 795 use classic file distribution mechanisms. If secure TA storage is 796 used (e.g., a Replay-Protected Memory Block device) on the other 797 hand, the TEEP protocol can be used to manage such storage. 799 4.5. Entity Relations 801 This architecture leverages asymmetric cryptography to authenticate a 802 device to a TAM. Additionally, a TEEP Agent in a device 803 authenticates a TAM. The provisioning of Trust Anchors to a device 804 may be different from one use case to the other. A Device 805 Administrator may want to have the capability to control what TAs are 806 allowed. A device manufacturer enables verification by one or more 807 TAMs and by Trusted Component Signers; it may embed a list of default 808 Trust Anchors into the TEEP Agent and TEE for TAM trust verification 809 and TA signature verification. 811 (App Developers) (App Store) (TAM) (Device with TEE) (CAs) 812 | | | | | 813 | | | (Embedded TEE cert) <--| 814 | | | | | 815 | <--- Get an app cert -----------------------------------| 816 | | | | | 817 | | | <-- Get a TAM cert ---------| 818 | | | | | 819 1. Build two apps: | | | | 820 | | | | 821 (a) Untrusted | | | | 822 App - 2a. Supply --> | --- 3. Install ------> | | 823 | | | | 824 (b) TA -- 2b. Supply ----------> | 4. Messaging-->| | 825 | | | | 827 Figure 3: Example Developer Experience 829 Figure 3 shows an example where the same developer builds and signs 830 two applications: (a) an Untrusted Application; (b) a TA that 831 provides some security functions to be run inside a TEE. This 832 example assumes that the developer, the TEE, and the TAM have 833 previously been provisioned with certificates. 835 At step 1, the developer authors the two applications. 837 At step 2, the developer uploads the Untrusted Application (2a) to an 838 Application Store. In this example, the developer is also the 839 Trusted Component Signer, and so generates a signed TA. The 840 developer can then either bundle the signed TA with the Untrusted 841 Application, or the developer can provide a signed Trusted Component 842 containing the TA to a TAM that will be managing the TA in various 843 devices. 845 At step 3, a user will go to an Application Store to download the 846 Untrusted Application (where the arrow indicates the direction of 847 data transfer). 849 At step 4, since the Untrusted Application depends on the TA, 850 installing the Untrusted Application will trigger TA installation via 851 communication with a TAM. The TEEP Agent will interact with the TAM 852 via a TEEP Broker that faciliates communications between the TAM and 853 the TEEP Agent. 855 Some Trusted Component installation implementations might ask for a 856 user's consent. In other implementations, a Device Administrator 857 might choose what Untrusted Applications and related Trusted 858 Components to be installed. A user consent flow is out of scope of 859 the TEEP architecture. 861 The main components of the TEEP protocol consist of a set of standard 862 messages created by a TAM to deliver Trusted Component management 863 commands to a device, and device attestation and response messages 864 created by a TEE that responds to a TAM's message. 866 It should be noted that network communication capability is generally 867 not available in TAs in today's TEE-powered devices. Consequently, 868 Trusted Applications generally rely on a broker in the REE to provide 869 access to network functionality in the REE. A broker does not need 870 to know the actual content of messages to facilitate such access. 872 Similarly, since the TEEP Agent runs inside a TEE, the TEEP Agent 873 generally relies on a TEEP Broker in the REE to provide network 874 access, and relay TAM requests to the TEEP Agent and relay the 875 responses back to the TAM. 877 5. Keys and Certificate Types 879 This architecture leverages the following credentials, which allow 880 achieving end-to-end security between a TAM and a TEEP Agent. 882 Figure 4 summarizes the relationships between various keys and where 883 they are stored. Each public/private key identifies a Trusted 884 Component Signer, TAM, or TEE, and gets a certificate that chains up 885 to some trust anchor. A list of trusted certificates is used to 886 check a presented certificate against. 888 Different CAs can be used for different types of certificates. TEEP 889 messages are always signed, where the signer key is the message 890 originator's private key, such as that of a TAM or a TEE. In 891 addition to the keys shown in Figure 4, there may be additional keys 892 used for attestation or encryption. Refer to the RATS Architecture 893 [I-D.ietf-rats-architecture] for more discussion. 895 Cardinality & Location of 896 Location of Private Key Trust Anchor 897 Purpose Private Key Signs Store 898 ------------------ ----------- ------------- ------------- 899 Authenticating 1 per TEE TEEP responses TAM 900 TEEP Agent 902 Authenticating TAM 1 per TAM TEEP requests TEEP Agent 904 Code Signing 1 per Trusted TA binary TEE 905 Component 906 Signer 908 Figure 4: Signature Keys 910 Note that Personalization Data is not included in the table above. 911 The use of Personalization Data is dependent on how TAs are used and 912 what their security requirements are. 914 TEEP requests from a TAM to a TEEP Agent are signed with the TAM 915 private key (for authentication and integrity protection). 916 Personalization Data and TA binaries can be encrypted with a key that 917 is established with a content-encryption key established with the TEE 918 public key (to provide confidentiality). Conversely, TEEP responses 919 from a TEEP Agent to a TAM can be signed with the TEE private key. 921 The TEE key pair and certificate are thus used for authenticating the 922 TEE to a remote TAM, and for sending private data to the TEE. Often, 923 the key pair is burned into the TEE by the TEE manufacturer and the 924 key pair and its certificate are valid for the expected lifetime of 925 the TEE. A TAM provider is responsible for configuring the TAM's 926 Trust Anchor Store with the manufacturer certificates or CAs that are 927 used to sign TEE keys. This is discussed further in Section 5.3 928 below. Typically the same key TEE pair is used for both signing and 929 encryption, though separate key pairs might also be used in the 930 future, as the joint security of encryption and signature with a 931 single key remains to some extent an open question in academic 932 cryptography. 934 The TAM key pair and certificate are used for authenticating a TAM to 935 a remote TEE, and for sending private data to the TAM (separate key 936 pairs for authentication vs. encryption could also be used in the 937 future). A TAM provider is responsible for acquiring a certificate 938 from a CA that is trusted by the TEEs it manages. This is discussed 939 further in Section 5.1 below. 941 The Trusted Component Signer key pair and certificate are used to 942 sign Trusted Components that the TEE will consider authorized to 943 execute. TEEs must be configured with the certificates or keys that 944 it considers authorized to sign TAs that it will execute. This is 945 discussed further in Section 5.2 below. 947 5.1. Trust Anchors in a TEEP Agent 949 A TEEP Agent's Trust Anchor Store contains a list of Trust Anchors, 950 which are typically CA certificates that sign various TAM 951 certificates. The list is typically preloaded at manufacturing time, 952 and can be updated using the TEEP protocol if the TEE has some form 953 of "Trust Anchor Manager TA" that has Trust Anchors in its 954 configuration data. Thus, Trust Anchors can be updated similarly to 955 the Personalization Data for any other TA. 957 When Trust Anchor update is carried out, it is imperative that any 958 update must maintain integrity where only an authentic Trust Anchor 959 list from a device manufacturer or a Device Administrator is 960 accepted. Details are out of scope of the architecture and can be 961 addressed in a protocol document. 963 Before a TAM can begin operation in the marketplace to support a 964 device with a particular TEE, it must be able to get its raw public 965 key, or its certificate, or a certificate it chains up to, listed in 966 the Trust Anchor Store of the TEEP Agent. 968 5.2. Trust Anchors in a TEE 970 The Trust Anchor Store in a TEE contains a list of Trust Anchors (raw 971 public keys or certificates) that are used to determine whether TA 972 binaries are allowed to execute by checking if their signatures can 973 be verified. The list is typically preloaded at manufacturing time, 974 and can be updated using the TEEP protocol if the TEE has some form 975 of "Trust Anchor Manager TA" that has Trust Anchors in its 976 configuration data. Thus, Trust Anchors can be updated similarly to 977 the Personalization Data for any other TA, as discussed in 978 Section 5.1. 980 5.3. Trust Anchors in a TAM 982 The Trust Anchor Store in a TAM consists of a list of Trust Anchors, 983 which are certificates that sign various device TEE certificates. A 984 TAM will accept a device for Trusted Component management if the TEE 985 in the device uses a TEE certificate that is chained to a certificate 986 or raw public key that the TAM trusts, is contained in an allow list, 987 is not found on a block list, and/or fulfills any other policy 988 criteria. 990 5.4. Scalability 992 This architecture uses a PKI (including self-signed certificates). 993 Trust Anchors exist on the devices to enable the TEEP Agent to 994 authenticate TAMs and the TEE to authenticate Trusted Component 995 Signers, and TAMs use Trust Anchors to authenticate TEEP Agents. 996 When a PKI is used, many intermediate CA certificates can chain to a 997 root certificate, each of which can issue many certificates. This 998 makes the protocol highly scalable. New factories that produce TEEs 999 can join the ecosystem. In this case, such a factory can get an 1000 intermediate CA certificate from one of the existing roots without 1001 requiring that TAMs are updated with information about the new device 1002 factory. Likewise, new TAMs can join the ecosystem, providing they 1003 are issued a TAM certificate that chains to an existing root whereby 1004 existing TEEs will be allowed to be personalized by the TAM without 1005 requiring changes to the TEE itself. This enables the ecosystem to 1006 scale, and avoids the need for centralized databases of all TEEs 1007 produced or all TAMs that exist or all Trusted Component Signers that 1008 exist. 1010 5.5. Message Security 1012 Messages created by a TAM are used to deliver Trusted Component 1013 management commands to a device, and device attestation and messages 1014 are created by the device TEE to respond to TAM messages. 1016 These messages are signed end-to-end between a TEEP Agent and a TAM. 1017 Confidentiality is provided by encrypting sensitive payloads (such as 1018 Personalization Data and attestation evidence), rather than 1019 encrypting the messages themselves. Using encrypted payloads is 1020 important to ensure that only the targeted device TEE or TAM is able 1021 to decrypt and view the actual content. 1023 6. TEEP Broker 1025 A TEE and TAs often do not have the capability to directly 1026 communicate outside of the hosting device. For example, 1027 GlobalPlatform [GPTEE] specifies one such architecture. This calls 1028 for a software module in the REE world to handle network 1029 communication with a TAM. 1031 A TEEP Broker is an application component running in the REE of the 1032 device or an SDK that facilitates communication between a TAM and a 1033 TEE. It also provides interfaces for Untrusted Applications to query 1034 and trigger installation of Trusted Components that the application 1035 needs to use. 1037 An Untrusted Application might communicate with a TEEP Broker at 1038 runtime to trigger Trusted Component installation itself, or an 1039 Untrusted Application might simply have a metadata file that 1040 describes the Trusted Components it depends on and the associated 1041 TAM(s) for each Trusted Component, and an REE Application Installer 1042 can inspect this application metadata file and invoke the TEEP Broker 1043 to trigger Trusted Component installation on behalf of the Untrusted 1044 Application without requiring the Untrusted Application to run first. 1046 6.1. Role of the TEEP Broker 1048 A TEEP Broker abstracts the message exchanges with a TEE in a device. 1049 The input data is originated from a TAM or the first initialization 1050 call to trigger a Trusted Component installation. 1052 The Broker doesn't need to parse TEEP message content received from a 1053 TAM that should be processed by a TEE (see the ProcessTeepMessage API 1054 in Section 6.2.1). When a device has more than one TEE, one TEEP 1055 Broker per TEE could be present in the REE or a common TEEP Broker 1056 could be used by multiple TEEs where the transport protocol (e.g., 1057 [I-D.ietf-teep-otrp-over-http]) allows the TEEP Broker to distinguish 1058 which TEE is relevant for each message from a TAM. 1060 The TEEP Broker interacts with a TEEP Agent inside a TEE, and relays 1061 the response messages generated from the TEEP Agent back to the TAM. 1063 The Broker only needs to return a (transport) error message to the 1064 TAM if the TEE is not reachable for some reason. Other errors are 1065 represented as TEEP response messages returned from the TEE which 1066 will then be passed to the TAM. 1068 6.2. TEEP Broker Implementation Consideration 1070 As depicted in Figure 5, there are multiple ways in which a TEEP 1071 Broker can be implemented, with more or fewer layers being inside the 1072 TEE. For example, in model A, the model with the smallest TEE 1073 footprint, only the TEEP implementation is inside the TEE, whereas 1074 the TEEP/HTTP implementation is in the TEEP Broker outside the TEE. 1076 Model: A B C ... 1078 TEE TEE TEE 1079 +----------------+ | | | 1080 | TEEP | Agent | | | Agent 1081 | implementation | | | | 1082 +----------------+ v | | 1083 | | | 1084 +----------------+ ^ | | 1085 | TEEP/HTTP | Broker | | | 1086 | implementation | | | | 1087 +----------------+ | v | 1088 | | | 1089 +----------------+ | ^ | 1090 | HTTP(S) | | | | 1091 | implementation | | | | 1092 +----------------+ | | v 1093 | | | 1094 +----------------+ | | ^ 1095 | TCP or QUIC | | | | Broker 1096 | implementation | | | | 1097 +----------------+ | | | 1098 REE REE REE 1100 Figure 5: TEEP Broker Models 1102 In other models, additional layers are moved into the TEE, increasing 1103 the TEE footprint, with the Broker either containing or calling the 1104 topmost protocol layer outside of the TEE. An implementation is free 1105 to choose any of these models. 1107 TEEP Broker implementers should consider methods of distribution, 1108 scope and concurrency on devices and runtime options. 1110 6.2.1. TEEP Broker APIs 1112 The following conceptual APIs exist from a TEEP Broker to a TEEP 1113 Agent: 1115 1. RequestTA: A notification from an REE application (e.g., an 1116 installer, or an Untrusted Application) that it depends on a 1117 given Trusted Component, which may or may not already be 1118 installed in the TEE. 1120 2. UnrequestTA: A notification from an REE application (e.g., an 1121 installer, or an Untrusted Application) that it no longer depends 1122 on a given Trusted Component, which may or may not already be 1123 installed in the TEE. For example, if the Untrusted Application 1124 is uninstalled, the uninstaller might invoke this conceptual API. 1126 3. ProcessTeepMessage: A message arriving from the network, to be 1127 delivered to the TEEP Agent for processing. 1129 4. RequestPolicyCheck: A hint (e.g., based on a timer) that the TEEP 1130 Agent may wish to contact the TAM for any changes, without the 1131 device itself needing any particular change. 1133 5. ProcessError: A notification that the TEEP Broker could not 1134 deliver an outbound TEEP message to a TAM. 1136 For comparison, similar APIs may exist on the TAM side, where a 1137 Broker may or may not exist, depending on whether the TAM uses a TEE 1138 or not: 1140 1. ProcessConnect: A notification that a new TEEP session is being 1141 requested by a TEEP Agent. 1143 2. ProcessTeepMessage: A message arriving on an existing TEEP 1144 session, to be delivered to the TAM for processing. 1146 For further discussion on these APIs, see 1147 [I-D.ietf-teep-otrp-over-http]. 1149 6.2.2. TEEP Broker Distribution 1151 The Broker installation is commonly carried out at OEM time. A user 1152 can dynamically download and install a Broker on-demand. 1154 7. Attestation 1156 Attestation is the process through which one entity (an Attester) 1157 presents "evidence", in the form of a series of claims, to another 1158 entity (a Verifier), and provides sufficient proof that the claims 1159 are true. Different Verifiers may require different degrees of 1160 confidence in attestation proofs and not all attestations are 1161 acceptable to every verifier. A third entity (a Relying Party) can 1162 then use "attestation results", in the form of another series of 1163 claims, from a Verifier to make authorization decisions. (See 1164 [I-D.ietf-rats-architecture] for more discussion.) 1165 In TEEP, as depicted in Figure 6, the primary purpose of an 1166 attestation is to allow a device (the Attester) to prove to a TAM 1167 (the Relying Party) that a TEE in the device has particular 1168 properties, was built by a particular manufacturer, and/or is 1169 executing a particular TA. Other claims are possible; TEEP does not 1170 limit the claims that may appear in evidence or attestation results, 1171 but defines a minimal set of attestation result claims required for 1172 TEEP to operate properly. Extensions to these claims are possible. 1173 Other standards or groups may define the format and semantics of 1174 extended claims. 1176 +----------------+ 1177 | Device | +----------+ 1178 | +------------+ | Evidence | TAM | Evidence +----------+ 1179 | | TEE |------------->| (Relying |-------------->| Verifier | 1180 | | (Attester) | | | Party) |<--------------| | 1181 | +------------+ | +----------+ Attestation +----------+ 1182 +----------------+ Result 1184 Figure 6: TEEP Attestation Roles 1186 As of the writing of this specification, device and TEE attestations 1187 have not been standardized across the market. Different devices, 1188 manufacturers, and TEEs support different attestation protocols. In 1189 order for TEEP to be inclusive, it is agnostic to the format of 1190 evidence, allowing proprietary or standardized formats to be used 1191 between a TEE and a verifier (which may or may not be colocated in 1192 the TAM), as long as the format supports encryption of any 1193 information that is considered sensitive. 1195 However, it should be recognized that not all Verifiers may be able 1196 to process all proprietary forms of attestation evidence. Similarly, 1197 the TEEP protocol is agnostic as to the format of attestation 1198 results, and the protocol (if any) used between the TAM and a 1199 verifier, as long as they convey at least the required set of claims 1200 in some format. Note that the respective attestation algorithms are 1201 not defined in the TEEP protocol itself; see 1202 [I-D.ietf-rats-architecture] and [I-D.ietf-teep-protocol] for more 1203 discussion. 1205 There are a number of considerations that need to be considered when 1206 appraising evidence provided by a TEE, including: 1208 * What security measures a manufacturer takes when provisioning keys 1209 into devices/TEEs; 1211 * What hardware and software components have access to the 1212 attestation keys of the TEE; 1214 * The source or local verification of claims within an attestation 1215 prior to a TEE signing a set of claims; 1217 * The level of protection afforded to attestation keys against 1218 exfiltration, modification, and side channel attacks; 1220 * The limitations of use applied to TEE attestation keys; 1222 * The processes in place to discover or detect TEE breaches; and 1224 * The revocation and recovery process of TEE attestation keys. 1226 Some TAMs may require additional claims in order to properly 1227 authorize a device or TEE. The specific format for these additional 1228 claims are outside the scope of this specification, but the TEEP 1229 protocol allows these additional claims to be included in the 1230 attestation messages. 1232 For more discussion of the attestation and appraisal process, see the 1233 RATS Architecture [I-D.ietf-rats-architecture]. 1235 The following information is required for TEEP attestation: 1237 * Device Identifying Information: Attestation information may need 1238 to uniquely identify a device to the TAM. Unique device 1239 identification allows the TAM to provide services to the device, 1240 such as managing installed TAs, and providing subscriptions to 1241 services, and locating device-specific keying material to 1242 communicate with or authenticate the device. In some use cases it 1243 may be sufficient to identify only the class of the device. The 1244 security and privacy requirements regarding device identification 1245 will vary with the type of TA provisioned to the TEE. 1247 * TEE Identifying Information: The type of TEE that generated this 1248 attestation must be identified. This includes version 1249 identification information for hardware, firmware, and software 1250 version of the TEE, as applicable by the TEE type. TEE 1251 manufacturer information for the TEE is required in order to 1252 disambiguate the same TEE type created by different manufacturers 1253 and address considerations around manufacturer provisioning, 1254 keying and support for the TEE. 1256 * Freshness Proof: A claim that includes freshness information must 1257 be included, such as a nonce or timestamp. 1259 8. Algorithm and Attestation Agility 1261 RFC 7696 [RFC7696] outlines the requirements to migrate from one 1262 mandatory-to-implement cryptographic algorithm suite to another over 1263 time. This feature is also known as crypto agility. Protocol 1264 evolution is greatly simplified when crypto agility is considered 1265 during the design of the protocol. In the case of the TEEP protocol 1266 the diverse range of use cases, from trusted app updates for smart 1267 phones and tablets to updates of code on higher-end IoT devices, 1268 creates the need for different mandatory-to-implement algorithms 1269 already from the start. 1271 Crypto agility in TEEP concerns the use of symmetric as well as 1272 asymmetric algorithms. In the context of TEEP, symmetric algorithms 1273 are used for encryption and integrity protection of TA binaries and 1274 Personalization Data whereas the asymmetric algorithms are used for 1275 signing messages and managing symmetric keys. 1277 In addition to the use of cryptographic algorithms in TEEP, there is 1278 also the need to make use of different attestation technologies. A 1279 device must provide techniques to inform a TAM about the attestation 1280 technology it supports. For many deployment cases it is more likely 1281 for the TAM to support one or more attestation techniques whereas the 1282 device may only support one. 1284 9. Security Considerations 1286 9.1. Broker Trust Model 1288 The architecture enables the TAM to communicate, via a TEEP Broker, 1289 with the device's TEE to manage Trusted Components. Since the TEEP 1290 Broker runs in a potentially vulnerable REE, the TEEP Broker could, 1291 however, be (or be infected by) malware. As such, all TAM messages 1292 are signed and sensitive data is encrypted such that the TEEP Broker 1293 cannot modify or capture sensitive data, but the TEEP Broker can 1294 still conduct DoS attacks as discussed in Section 9.3. 1296 A TEEP Agent in a TEE is responsible for protecting against potential 1297 attacks from a compromised TEEP Broker or rogue malware in the REE. 1298 A rogue TEEP Broker might send corrupted data to the TEEP Agent, or 1299 launch a DoS attack by sending a flood of TEEP protocol requests, or 1300 simply drop or delay notifications to a TEE. The TEEP Agent 1301 validates the signature of each TEEP protocol request and checks the 1302 signing certificate against its Trust Anchors. To mitigate DoS 1303 attacks, it might also add some protection scheme such as a threshold 1304 on repeated requests or number of TAs that can be installed. 1306 Some implementations might rely on (due to lack of any available 1307 alternative) the use of an untrusted timer or other event to call the 1308 RequestPolicyCheck API (Section 6.2.1), which means that a 1309 compromised REE can cause a TEE to not receive policy changes and 1310 thus be out of date with respect to policy. The same can potentially 1311 be done by any other man-in-the-middle simply by blocking 1312 communication with a TAM. Ultimately such outdated compliance could 1313 be addressed by using attestation in secure communication, where the 1314 attestation evidence reveals what state the TEE is in, so that 1315 communication (other than remediation such as via TEEP) from an out- 1316 of-compliance TEE can be rejected. 1318 Similarly, in most implementations the REE is involved in the 1319 mechanics of installing new TAs. However, the authority for what TAs 1320 are running in a given TEE is between the TEEP Agent and the TAM. 1321 While a TEEP Broker broker can in effect make suggestions, it cannot 1322 decide or enforce what runs where. The TEEP Broker can also control 1323 which TEE a given installation request is directed at, but a TEEP 1324 Agent will only accept TAs that are actually applicable to it and 1325 where installation instructions are received by a TAM that it trusts. 1327 The authorization model for the UnrequestTA operation is, however, 1328 weaker in that it expresses the removal of a dependency from an 1329 application that was untrusted to begin with. This means that a 1330 compromised REE could remove a valid dependency from an Untrusted 1331 Application on a TA. Normal REE security mechanisms should be used 1332 to protect the REE and Untrusted Applications. 1334 9.2. Data Protection 1336 It is the responsibility of the TAM to protect data on its servers. 1337 Similarly, it is the responsibility of the TEE implementation to 1338 provide protection of data against integrity and confidentiality 1339 attacks from outside the TEE. TEEs that provide isolation among TAs 1340 within the TEE are likewise responsible for protecting TA data 1341 against the REE and other TAs. For example, this can be used to 1342 protect one user's or tenant's data from compromise by another user 1343 or tenant, even if the attacker has TAs. 1345 The protocol between TEEP Agents and TAMs similarly is responsible 1346 for securely providing integrity and confidentiality protection 1347 against adversaries between them. It is a design choice at what 1348 layers to best provide protection against network adversaries. As 1349 discussed in Section 6, the transport protocol and any security 1350 mechanism associated with it (e.g., the Transport Layer Security 1351 protocol) under the TEEP protocol may terminate outside a TEE. If it 1352 does, the TEEP protocol itself must provide integrity protection and 1353 confidentiality protection to secure data end-to-end. For example, 1354 confidentiality protection for payloads may be provided by utilizing 1355 encrypted TA binaries and encrypted attestation information. See 1356 [I-D.ietf-teep-protocol] for how a specific solution addresses the 1357 design question of how to provide integrity and confidentiality 1358 protection. 1360 9.3. Compromised REE 1362 It is possible that the REE of a device is compromised. We have 1363 already seen examples of attacks on the public Internet with billions 1364 of compromised devices being used to mount DDoS attacks. A 1365 compromised REE can be used for such an attack but it cannot tamper 1366 with the TEE's code or data in doing so. A compromised REE can, 1367 however, launch DoS attacks against the TEE. 1369 The compromised REE may terminate the TEEP Broker such that TEEP 1370 transactions cannot reach the TEE, or might drop, replay, or delay 1371 messages between a TAM and a TEEP Agent. However, while a DoS attack 1372 cannot be prevented, the REE cannot access anything in the TEE if the 1373 TEE is implemented correctly. Some TEEs may have some watchdog 1374 scheme to observe REE state and mitigate DoS attacks against it but 1375 most TEEs don't have such a capability. 1377 In some other scenarios, the compromised REE may ask a TEEP Broker to 1378 make repeated requests to a TEEP Agent in a TEE to install or 1379 uninstall a Trusted Component. An installation or uninstallation 1380 request constructed by the TEEP Broker or REE will be rejected by the 1381 TEEP Agent because the request won't have the correct signature from 1382 a TAM to pass the request signature validation. 1384 This can become a DoS attack by exhausting resources in a TEE with 1385 repeated requests. In general, a DoS attack threat exists when the 1386 REE is compromised, and a DoS attack can happen to other resources. 1387 The TEEP architecture doesn't change this. 1389 A compromised REE might also request initiating the full flow of 1390 installation of Trusted Components that are not necessary. It may 1391 also repeat a prior legitimate Trusted Component installation 1392 request. A TEEP Agent implementation is responsible for ensuring 1393 that it can recognize and decline such repeated requests. It is also 1394 responsible for protecting the resource usage allocated for Trusted 1395 Component management. 1397 9.4. CA Compromise or Expiry of CA Certificate 1399 A root CA for TAM certificates might get compromised or its 1400 certificate might expire, or a Trust Anchor other than a root CA 1401 certificate may also expire or be compromised. TEEs are responsible 1402 for validating the entire TAM certificate path, including the TAM 1403 certificate and any intermediate certificates up to the root 1404 certificate. See Section 6 of [RFC5280] for details. Such 1405 validation generally includes checking for certificate revocation, 1406 but certificate status check protocols may not scale down to 1407 constrained devices that use TEEP. 1409 To address the above issues, a certificate path update mechanism is 1410 expected from TAM operators, so that the TAM can get a new 1411 certificate path that can be validated by a TEEP Agent. In addition, 1412 the Trust Anchor in the TEEP Agent's Trust Anchor Store may need to 1413 be updated. To address this, some TEE Trust Anchor update mechanism 1414 is expected from device OEMs, such as using the TEEP protocol to 1415 distribute new Trust Anchors. 1417 Similarly, a root CA for TEE certificates might get compromised or 1418 its certificate might expire, or a Trust Anchor other than a root CA 1419 certificate may also expire or be compromised. TAMs are responsible 1420 for validating the entire TEE certificate path, including the TEE 1421 certificate and any intermediate certificates up to the root 1422 certificate. Such validation includes checking for certificate 1423 revocation. 1425 If a TEE certificate path validation fails, the TEE might be rejected 1426 by a TAM, subject to the TAM's policy. To address this, some 1427 certificate path update mechanism is expected from device OEMs, so 1428 that the TEE can get a new certificate path that can be validated by 1429 a TAM. In addition, the Trust Anchor in the TAM's Trust Anchor Store 1430 may need to be updated. 1432 9.5. Compromised TAM 1434 Device TEEs are responsible for validating the supplied TAM 1435 certificates to determine that the TAM is trustworthy. 1437 9.6. Malicious TA Removal 1439 It is possible that a rogue developer distributes a malicious 1440 Untrusted Application and intends to get a malicious TA installed. 1441 Such a TA might be able to escape from malware detection by the REE, 1442 or access trusted resources within the TEE (but could not access 1443 other TEEs, or access other TA's if the TEE provides isolation 1444 between TAs). 1446 It is the responsibility of the TAM to not install malicious TAs in 1447 the first place. The TEEP architecture allows a TEEP Agent to decide 1448 which TAMs it trusts via Trust Anchors, and delegates the TA 1449 authenticity check to the TAMs it trusts. 1451 It may happen that a TA was previously considered trustworthy but is 1452 later found to be buggy or compromised. In this case, the TAM can 1453 initiate the removal of the TA by notifying devices to remove the TA 1454 (and potentially the REE or Device Owner to remove any Untrusted 1455 Application that depend on the TA). If the TAM does not currently 1456 have a connection to the TEEP Agent on a device, such a notification 1457 would occur the next time connectivity does exist. That is, to 1458 recover, the TEEP Agent must be able to reach out to the TAM, for 1459 example whenever the RequestPolicyCheck API (Section 6.2.1) is 1460 invoked by a timer or other event. 1462 Furthermore the policy in the Verifier in an attestation process can 1463 be updated so that any evidence that includes the malicious TA would 1464 result in an attestation failure. There is, however, a time window 1465 during which a malicious TA might be able to operate successfully, 1466 which is the validity time of the previous attestation result. For 1467 example, if the Verifier in Figure 6 is updated to treat a previously 1468 valid TA as no longer trustworthy, any attestation result it 1469 previously generated saying that the TA is valid will continue to be 1470 used until the attestation result expires. As such, the TAM's 1471 Verifier should take into account the acceptable time window when 1472 generating attestation results. See [I-D.ietf-rats-architecture] for 1473 further discussion. 1475 9.7. TEE Certificate Expiry and Renewal 1477 TEE device certificates are expected to be long lived, longer than 1478 the lifetime of a device. A TAM certificate usually has a moderate 1479 lifetime of 2 to 5 years. A TAM should get renewed or rekeyed 1480 certificates. The root CA certificates for a TAM, which are embedded 1481 into the Trust Anchor Store in a device, should have long lifetimes 1482 that don't require device Trust Anchor updates. On the other hand, 1483 it is imperative that OEMs or device providers plan for support of 1484 Trust Anchor update in their shipped devices. 1486 For those cases where TEE devices are given certificates for which no 1487 good expiration date can be assigned the recommendations in 1488 Section 4.1.2.5 of [RFC5280] are applicable. 1490 9.8. Keeping Secrets from the TAM 1492 In some scenarios, it is desirable to protect the TA binary or 1493 Personalization Data from being disclosed to the TAM that distributes 1494 them. In such a scenario, the files can be encrypted end-to-end 1495 between a Trusted Component Signer and a TEE. However, there must be 1496 some means of provisioning the decryption key into the TEE and/or 1497 some means of the Trusted Component Signer securely learning a public 1498 key of the TEE that it can use to encrypt. The Trusted Component 1499 Signer cannot necessarily even trust the TAM to report the correct 1500 public key of a TEE for use with encryption, since the TAM might 1501 instead provide the public key of a TEE that it controls. 1503 One way to solve this is for the Trusted Component Signer to run its 1504 own TAM that is only used to distribute the decryption key via the 1505 TEEP protocol, and the key file can be a dependency in the manifest 1506 of the encrypted TA. Thus, the TEEP Agent would look at the Trusted 1507 Component manifest, determine there is a dependency with a TAM URI of 1508 the Trusted Component Signer's TAM. The Agent would then install the 1509 dependency, and then continue with the Trusted Component installation 1510 steps, including decrypting the TA binary with the relevant key. 1512 9.9. REE Privacy 1514 The TEEP architecture is applicable to cases where devices have a TEE 1515 that protects data and code from the REE administrator. In such 1516 cases, the TAM administrator, not the REE administrator, controls the 1517 TEE in the devices. As some examples: 1519 * a cloud hoster may be the REE administrator where a customer 1520 administrator controls the TEE hosted in the cloud. 1522 * a device manufacturer might control the TEE in a device purchased 1523 by a customer 1525 The privacy risk is that data in the REE might be susceptible to 1526 disclosure to the TEE administrator. This risk is not introduced by 1527 the TEEP architecture, but is inherent in most uses of TEEs. This 1528 risk can be mitigated by making sure the REE administrator is aware 1529 of and explicitly chooses to have a TEE that is managed by another 1530 party. In the cloud hoster example, this choice is made by 1531 explicitly offering a service to customers to provide TEEs for them 1532 to administer. In the device manufacturer example, this choice is 1533 made by the customer choosing to buy a device made by a given 1534 manufacturer. 1536 10. IANA Considerations 1538 This document does not require actions by IANA. 1540 11. Contributors 1542 * Andrew Atyeo, Intercede (andrew.atyeo@intercede.com) 1544 * Liu Dapeng, Alibaba Group (maxpassion@gmail.com) 1546 12. Acknowledgements 1548 We would like to thank Nick Cook, Minho Yoo, Brian Witten, Tyler Kim, 1549 Alin Mutu, Juergen Schoenwaelder, Nicolae Paladi, Sorin Faibish, Ned 1550 Smith, Russ Housley, Jeremy O'Donoghue, and Anders Rundgren for their 1551 feedback. 1553 13. Informative References 1555 [CC-Overview] 1556 Confidential Computing Consortium, "Confidential 1557 Computing: Hardware-Based Trusted Execution for 1558 Applications and Data", January 2021, 1559 . 1563 [CC-Technical-Analysis] 1564 Confidential Computing Consortium, "A Technical Analysis 1565 of Confidential Computing, v1.2", October 2021, 1566 . 1570 [GPTEE] GlobalPlatform, "GlobalPlatform Device Technology: TEE 1571 System Architecture, v1.1", GlobalPlatform GPD_SPE_009, 1572 January 2017, . 1575 [GSMA] GSM Association, "GP.22 RSP Technical Specification, 1576 Version 2.2.2", June 2020, . 1579 [I-D.ietf-rats-architecture] 1580 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 1581 W. Pan, "Remote Attestation Procedures Architecture", Work 1582 in Progress, Internet-Draft, draft-ietf-rats-architecture- 1583 15, 8 February 2022, . 1586 [I-D.ietf-suit-architecture] 1587 Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A 1588 Firmware Update Architecture for Internet of Things", Work 1589 in Progress, Internet-Draft, draft-ietf-suit-architecture- 1590 16, 27 January 2021, . 1593 [I-D.ietf-suit-manifest] 1594 Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, 1595 "A Concise Binary Object Representation (CBOR)-based 1596 Serialization Format for the Software Updates for Internet 1597 of Things (SUIT) Manifest", Work in Progress, Internet- 1598 Draft, draft-ietf-suit-manifest-16, 25 October 2021, 1599 . 1602 [I-D.ietf-teep-otrp-over-http] 1603 Thaler, D., "HTTP Transport for Trusted Execution 1604 Environment Provisioning: Agent Initiated Communication", 1605 Work in Progress, Internet-Draft, draft-ietf-teep-otrp- 1606 over-http-13, 28 February 2022, 1607 . 1610 [I-D.ietf-teep-protocol] 1611 Tschofenig, H., Pei, M., Wheeler, D., Thaler, D., and A. 1612 Tsukamoto, "Trusted Execution Environment Provisioning 1613 (TEEP) Protocol", Work in Progress, Internet-Draft, draft- 1614 ietf-teep-protocol-08, 7 March 2022, 1615 . 1618 [OTRP] GlobalPlatform, "Open Trust Protocol (OTrP) Profile v1.1", 1619 GlobalPlatform GPD_SPE_123, July 2020, 1620 . 1623 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1624 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1625 . 1627 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1628 Housley, R., and W. Polk, "Internet X.509 Public Key 1629 Infrastructure Certificate and Certificate Revocation List 1630 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1631 . 1633 [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management 1634 Requirements", RFC 6024, DOI 10.17487/RFC6024, October 1635 2010, . 1637 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 1638 Agility and Selecting Mandatory-to-Implement Algorithms", 1639 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 1640 . 1642 [SGX] Intel, "Intel(R) Software Guard Extensions (Intel (R) 1643 SGX)", n.d., . 1647 [TrustZone] 1648 Arm, "Arm TrustZone Technology", n.d., 1649 . 1652 Authors' Addresses 1654 Mingliang Pei 1655 Broadcom 1656 Email: mingliang.pei@broadcom.com 1658 Hannes Tschofenig 1659 Arm Limited 1660 Email: hannes.tschofenig@arm.com 1662 Dave Thaler 1663 Microsoft 1664 Email: dthaler@microsoft.com 1666 David Wheeler 1667 Amazon 1668 Email: davewhee@amazon.com