idnits 2.17.00 (12 Aug 2021) /tmp/idnits50258/draft-ietf-teep-architecture-16.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 document date (28 February 2022) is 81 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-suit-architecture has been published as RFC 9019 == Outdated reference: A later version (-17) exists of draft-ietf-suit-manifest-16 == Outdated reference: A later version (-08) exists of draft-ietf-teep-protocol-07 Summary: 0 errors (**), 0 flaws (~~), 3 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: 1 September 2022 Arm Limited 6 D. Thaler 7 Microsoft 8 D. Wheeler 9 Amazon 10 28 February 2022 12 Trusted Execution Environment Provisioning (TEEP) Architecture 13 draft-ietf-teep-architecture-16 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 1 September 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 Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . . 9 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. 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. It may 156 also be the case in some constrained devices that there is no REE 157 (only a TEE) and there may be no local "user" per se, only a remote 158 TEE administrator. For further discussion of such confidential 159 computing use cases and threat model, see [CC-Overview] and 160 [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, for TEEs 221 that can install and enumerate TAs in a TEE-secured location and 222 where another domain-specific protocol standard (e.g., [GSMA], 223 [OTRP]) that meets the needs is not already in use. 225 2. Terminology 227 The following terms are used: 229 * Device: A physical piece of hardware that hosts one or more TEEs, 230 often along with an REE. 232 * Device Administrator: An entity that is responsible for 233 administration of a device, which could be the Device Owner. A 234 Device Administrator has privileges on the device to install and 235 remove Untrusted Applications and TAs, approve or reject Trust 236 Anchors, and approve or reject TA developers, among possibly other 237 privileges on the device. A Device Administrator can manage the 238 list of allowed TAMs by modifying the list of Trust Anchors on the 239 device. Although a Device Administrator may have privileges and 240 device-specific controls to locally administer a device, the 241 Device Administrator may choose to remotely administer a device 242 through a TAM. 244 * Device Owner: A device is always owned by someone. In some cases, 245 it is common for the (primary) device user to also own the device, 246 making the device user/owner also the Device Administrator. In 247 enterprise environments it is more common for the enterprise to 248 own the device, and any device user has no or limited 249 administration rights. In this case, the enterprise appoints a 250 Device Administrator that is not the device owner. 252 * Device User: A human being that uses a device. Many devices have 253 a single device user. Some devices have a primary device user 254 with other human beings as secondary device users (e.g., a parent 255 allowing children to use their tablet or laptop). Other devices 256 are not used by a human being and hence have no device user. 257 Relates to Device Owner and Device Administrator. 259 * Personalization Data: A set of configuration data that is specific 260 to the device or user. The Personalization Data may depend on the 261 type of TEE, a particular TEE instance, the TA, and even the user 262 of the device; an example of Personalization Data might be a 263 secret symmetric key used by a TA to communicate with some 264 service. 266 * Raw Public Key: A raw public key consists of only the algorithm 267 identifier (type) of the key and the cryptographic public key 268 material, such as the SubjectPublicKeyInfo structure of a PKIX 269 certificate [RFC5280]. Other serialization formats that do not 270 rely on ASN.1 may also be used. 272 * Rich Execution Environment (REE): An environment that is provided 273 and governed by a typical OS (e.g., Linux, Windows, Android, iOS), 274 potentially in conjunction with other supporting operating systems 275 and hypervisors; it is outside of the TEE(s) managed by the TEEP 276 protocol. This environment and applications running on it are 277 considered untrusted (or more precisely, less trusted than a TEE). 279 * Trust Anchor: As defined in [RFC6024] and 280 [I-D.ietf-suit-architecture], "A trust anchor represents an 281 authoritative entity via a public key and associated data. The 282 public key is used to verify digital signatures, and the 283 associated data is used to constrain the types of information for 284 which the trust anchor is authoritative." The Trust Anchor may be 285 a certificate or it may be a raw public key. 287 * Trust Anchor Store: As defined in [RFC6024], "A trust anchor store 288 is a set of one or more trust anchors stored in a device... A 289 device may have more than one trust anchor store, each of which 290 may be used by one or more applications." As noted in 291 [I-D.ietf-suit-architecture], a Trust Anchor Store must resist 292 modification against unauthorized insertion, deletion, and 293 modification. 295 * Trusted Application (TA): An application (or, in some 296 implementations, an application component) that runs in a TEE. 298 * Trusted Application Manager (TAM): An entity that manages Trusted 299 Applications and other Trusted Components running in TEEs of 300 various devices. 302 * Trusted Component: A set of code and/or data in a TEE managed as a 303 unit by a Trusted Application Manager. Trusted Applications and 304 Personalization Data are thus managed by being included in Trusted 305 Components. Trusted OS code or trusted firmware can also be 306 expressed as Trusted Components that a Trusted Component depends 307 on. 309 * Trusted Component Developer: An entity that develops one or more 310 Trusted Components. 312 * Trusted Component Signer: An entity that signs a Trusted Component 313 with a key that a TEE will trust. The signer might or might not 314 be the same entity as the Trusted Component Developer. For 315 example, a Trusted Component might be signed (or re-signed) by a 316 Device Administrator if the TEE will only trust the Device 317 Administrator. A Trusted Component might also be encrypted, if 318 the code is considered confidential. 320 * Trusted Execution Environment (TEE): An execution environment that 321 enforces that only authorized code can execute within the TEE, and 322 data used by that code cannot be read or tampered with by code 323 outside the TEE. A TEE also generally has a device unique 324 credential that cannot be cloned. There are multiple technologies 325 that can be used to implement a TEE, and the level of security 326 achieved varies accordingly. In addition, TEEs typically use an 327 isolation mechanism between Trusted Applications to ensure that 328 one TA cannot read, modify or delete the data and code of another 329 TA. 331 * Untrusted Application: An application running in an REE. An 332 Untrusted Application might depend on one or more TAs. 334 3. Use Cases 336 3.1. Payment 338 A payment application in a mobile device requires high security and 339 trust in the hosting device. Payments initiated from a mobile device 340 can use a Trusted Application to provide strong identification and 341 proof of transaction. 343 For a mobile payment application, some biometric identification 344 information could also be stored in a TEE. The mobile payment 345 application can use such information for unlocking the device and for 346 local identification of the user. 348 A trusted user interface (UI) may be used in a mobile device to 349 prevent malicious software from stealing sensitive user input data. 350 Such an implementation often relies on a TEE for providing access to 351 peripherals, such as PIN input or a trusted display, so that the REE 352 cannot observe or tamper with the user input or output. 354 3.2. Authentication 356 For better security of authentication, a device may store its keys 357 and cryptographic libraries inside a TEE limiting access to 358 cryptographic functions via a well-defined interface and thereby 359 reducing access to keying material. 361 3.3. Internet of Things 363 Weak security in Internet of Things (IoT) devices has been posing 364 threats to critical infrastructure that relies upon such devices. It 365 is desirable that IoT devices can prevent malware from manipulating 366 actuators (e.g., unlocking a door), or stealing or modifying 367 sensitive data, such as authentication credentials in the device. A 368 TEE can be the best way to implement such IoT security functions. 370 3.4. Confidential Cloud Computing 372 A tenant can store sensitive data, such as customer details or credit 373 card numbers, in a TEE in a cloud computing server such that only the 374 tenant can access the data, preventing the cloud hosting provider 375 from accessing the data. A tenant can run TAs inside a server TEE 376 for secure operation and enhanced data security. This provides 377 benefits not only to tenants with better data security but also to 378 cloud hosting providers for reduced liability and increased cloud 379 adoption. 381 4. Architecture 383 4.1. System Components 385 Figure 1 shows the main components in a typical device with an REE 386 and a TEE. Full descriptions of components not previously defined 387 are provided below. Interactions of all components are further 388 explained in the following paragraphs. 390 +-------------------------------------------+ 391 | Device | Trusted Component 392 | +--------+ | Signer 393 | +-------------+ | |-----------+ | 394 | | TEE-1 | | TEEP |---------+ | | 395 | | +--------+ | +----| Broker | | | | +--------+ | 396 | | | TEEP | | | | |<---+ | | +->| |<-+ 397 | | | Agent |<----+ | | | | | +-| TAM-1 | 398 | | +--------+ | | |<-+ | | +->| | |<-+ 399 | | | +--------+ | | | | +--------+ | 400 | | +---+ +---+ | | | | | TAM-2 | | 401 | +-->|TA1| |TA2| | +-------+ | | | +--------+ | 402 | | | | | | |<---------| App-2 |--+ | | | 403 | | | +---+ +---+ | +-------+ | | | Device Administrator 404 | | +-------------+ | App-1 | | | | 405 | | | | | | | 406 | +--------------------| |---+ | | 407 | | |--------+ | 408 | +-------+ | 409 +-------------------------------------------+ 411 Figure 1: Notional Architecture of TEEP 413 * Trusted Component Signers and Device Administrators utilize the 414 services of a TAM to manage TAs on devices. Trusted Component 415 Signers do not directly interact with devices. Device 416 Administators may elect to use a TAM for remote administration of 417 TAs instead of managing each device directly. 419 * Trusted Application Manager (TAM): A TAM is responsible for 420 performing lifecycle management activity on Trusted Components on 421 behalf of Trusted Component Signers and Device Administrators. 422 This includes installation and deletion of Trusted Components, and 423 may include, for example, over-the-air updates to keep Trusted 424 Components up-to-date and clean up when Trusted Components should 425 be removed. TAMs may provide services that make it easier for 426 Trusted Component Signers or Device Administators to use the TAM's 427 service to manage multiple devices, although that is not required 428 of a TAM. 430 The TAM performs its management of Trusted Components on the 431 device through interactions with a device's TEEP Broker, which 432 relays messages between a TAM and a TEEP Agent running inside the 433 TEE. TEEP authentication is performed between a TAM and a TEEP 434 Agent. 436 As shown in Figure 1, the TAM cannot directly contact a TEEP 437 Agent, but must wait for the TEEP Broker to contact the TAM 438 requesting a particular service. This architecture is intentional 439 in order to accommodate network and application firewalls that 440 normally protect user and enterprise devices from arbitrary 441 connections from external network entities. 443 A TAM may be publicly available for use by many Trusted Component 444 Signers, or a TAM may be private, and accessible by only one or a 445 limited number of Trusted Component Signers. It is expected that 446 many enterprises, manufacturers, and network carriers will run 447 their own private TAM. 449 A Trusted Component Signer or Device Administrator chooses a 450 particular TAM based on whether the TAM is trusted by a device or 451 set of devices. The TAM is trusted by a device if the TAM's 452 public key is, or chains up to, an authorized Trust Anchor in the 453 device. A Trusted Component Signer or Device Administrator may 454 run their own TAM, but the devices they wish to manage must 455 include this TAM's public key or certificate, or a certificate it 456 chains up to, in the Trust Anchor Store. 458 A Trusted Component Signer or Device Administrator is free to 459 utilize multiple TAMs. This may be required for managing Trusted 460 Components on multiple different types of devices from different 461 manufacturers, or mobile devices on different network carriers, 462 since the Trust Anchor Store on these different devices may 463 contain keys for different TAMs. A Device Administrator may be 464 able to add their own TAM's public key or certificate, or a 465 certificate it chains up to, to the Trust Anchor Store on all 466 their devices, overcoming this limitation. 468 Any entity is free to operate a TAM. For a TAM to be successful, 469 it must have its public key or certificate installed in a device's 470 Trust Anchor Store. A TAM may set up a relationship with device 471 manufacturers or network carriers to have them install the TAM's 472 keys in their device's Trust Anchor Store. Alternatively, a TAM 473 may publish its certificate and allow Device Administrators to 474 install the TAM's certificate in their devices as an after-market 475 action. 477 * TEEP Broker: A TEEP Broker is an application component running in 478 a Rich Execution Environment (REE) that enables the message 479 protocol exchange between a TAM and a TEE in a device. A TEEP 480 Broker does not process messages on behalf of a TEE, but merely is 481 responsible for relaying messages from the TAM to the TEE, and for 482 returning the TEE's responses to the TAM. In devices with no REE 483 (e.g., a microcontroller where all code runs in an environment 484 that meets the definition of a Trusted Execution Environment in 485 Section 2), the TEEP Broker would be absent and instead the TEEP 486 protocol transport would be implemented inside the TEE itself. 488 * TEEP Agent: The TEEP Agent is a processing module running inside a 489 TEE that receives TAM requests (typically relayed via a TEEP 490 Broker that runs in an REE). A TEEP Agent in the TEE may parse 491 requests or forward requests to other processing modules in a TEE, 492 which is up to a TEE provider's implementation. A response 493 message corresponding to a TAM request is sent back to the TAM, 494 again typically relayed via a TEEP Broker. 496 * Certification Authority (CA): A CA is an entity that issues 497 digital certificates (especially X.509 certificates) and vouches 498 for the binding between the data items in a certificate [RFC4949]. 499 Certificates are then used for authenticating a device, a TAM, or 500 a Trusted Component Signer, as discussed in Section 5. The CAs do 501 not need to be the same; different CAs can be chosen by each TAM, 502 and different device CAs can be used by different device 503 manufacturers. 505 4.2. Multiple TEEs in a Device 507 Some devices might implement multiple TEEs. In these cases, there 508 might be one shared TEEP Broker that interacts with all the TEEs in 509 the device. However, some TEEs (for example, SGX [SGX]) present 510 themselves as separate containers within memory without a controlling 511 manager within the TEE. As such, there might be multiple TEEP 512 Brokers in the REE, where each TEEP Broker communicates with one or 513 more TEEs associated with it. 515 It is up to the REE and the Untrusted Applications how they select 516 the correct TEEP Broker. Verification that the correct TA has been 517 reached then becomes a matter of properly verifying TA attestations, 518 which are unforgeable. 520 The multiple TEEP Broker approach is shown in the diagram below. For 521 brevity, TEEP Broker 2 is shown interacting with only one TAM and 522 Untrusted Application and only one TEE, but no such limitations are 523 intended to be implied in the architecture. 525 +-------------------------------------------+ Trusted 526 | Device | Component 527 | | Signer 528 | +-------------+ | | 529 | | TEE-1 | | | 530 | | +-------+ | +--------+ | +--------+ | 531 | | | TEEP | | | TEEP |------------->| |<-+ 532 | | | Agent |<----------| Broker | | | | TA 533 | | | 1 | | | 1 |---------+ | | 534 | | +-------+ | | | | | | | 535 | | | | |<---+ | | | | 536 | | +---+ +---+ | | | | | | +-| TAM-1 |Policy 537 | | |TA1| |TA2| | | |<-+ | | +->| | |<-+ 538 | +-->| | | |<---+ +--------+ | | | | +--------+ | 539 | | | +---+ +---+ | | | | | | TAM-2 | | 540 | | | | | +-------+ | | | +--------+ | 541 | | +-------------+ +-----| App-2 |--+ | | ^ | 542 | | +-------+ | | | | Device 543 | +--------------------| App-1 | | | | | Administrator 544 | +------| | | | | | 545 | +-----------|-+ | |---+ | | | 546 | | TEE-2 | | | |--------+ | | 547 | | +------+ | | | |------+ | | 548 | | | TEEP | | | +-------+ | | | 549 | | | Agent|<-----+ | | | 550 | | | 2 | | | | | | | 551 | | +------+ | | | | | | 552 | | | | | | | | 553 | | +---+ | | | | | | 554 | | |TA3|<----+ | | +----------+ | | | 555 | | | | | | | TEEP |<--+ | | 556 | | +---+ | +--| Broker | | | 557 | | | | 2 |----------------+ 558 | +-------------+ +----------+ | 559 | | 560 +-------------------------------------------+ 562 Figure 2: Notional Architecture of TEEP with multiple TEEs 564 In the diagram above, TEEP Broker 1 controls interactions with the 565 TAs in TEE-1, and TEEP Broker 2 controls interactions with the TAs in 566 TEE-2. This presents some challenges for a TAM in completely 567 managing the device, since a TAM may not interact with all the TEEP 568 Brokers on a particular platform. In addition, since TEEs may be 569 physically separated, with wholly different resources, there may be 570 no need for TEEP Brokers to share information on installed Trusted 571 Components or resource usage. 573 4.3. Multiple TAMs and Relationship to TAs 575 As shown in Figure 2, a TEEP Broker provides communication between 576 one or more TEEP Agents and one or more TAMs. The selection of which 577 TAM to interact with might be made with or without input from an 578 Untrusted Application, but is ultimately the decision of a TEEP 579 Agent. 581 A TEEP Agent is assumed to be able to determine, for any given 582 Trusted Component, whether that Trusted Component is installed (or 583 minimally, is running) in a TEE with which the TEEP Agent is 584 associated. 586 Each Trusted Component is digitally signed, protecting its integrity, 587 and linking the Trusted Component back to the Trusted Component 588 Signer. The Trusted Component Signer is often the Trusted Component 589 Developer, but in some cases might be another party such as a Device 590 Administrator or other party to whom the code has been licensed (in 591 which case the same code might be signed by multiple licensees and 592 distributed as if it were different TAs). 594 A Trusted Component Signer selects one or more TAMs and communicates 595 the Trusted Component(s) to the TAM. For example, the Trusted 596 Component Signer might choose TAMs based upon the markets into which 597 the TAM can provide access. There may be TAMs that provide services 598 to specific types of devices, or device operating systems, or 599 specific geographical regions or network carriers. A Trusted 600 Component Signer may be motivated to utilize multiple TAMs in order 601 to maximize market penetration and availability on multiple types of 602 devices. This means that the same Trusted Component will often be 603 available through multiple TAMs. 605 When the developer of an Untrusted Application that depends on a 606 Trusted Component publishes the Untrusted Application to an app store 607 or other app repository, the developer optionally binds the Untrusted 608 Application with a manifest that identifies what TAMs can be 609 contacted for the Trusted Component. In some situations, a Trusted 610 Component may only be available via a single TAM - this is likely the 611 case for enterprise applications or Trusted Component Signers serving 612 a closed community. For broad public apps, there will likely be 613 multiple TAMs in the Untrusted Application's manifest - one servicing 614 one brand of mobile device and another servicing a different 615 manufacturer, etc. Because different devices and different 616 manufacturers trust different TAMs, the manifest can include multiple 617 TAMs that support the required Trusted Component. 619 When a TEEP Broker receives a request (see the RequestTA API in 620 Section 6.2.1) from an Untrusted Application to install a Trusted 621 Component, a list of TAM URIs may be provided for that Trusted 622 Component, and the request is passed to the TEEP Agent. If the TEEP 623 Agent decides that the Trusted Component needs to be installed, the 624 TEEP Agent selects a single TAM URI that is consistent with the list 625 of trusted TAMs provisioned in the TEEP Agent, invokes the HTTP 626 transport for TEEP to connect to the TAM URI, and begins a TEEP 627 protocol exchange. When the TEEP Agent subsequently receives the 628 Trusted Component to install and the Trusted Component's manifest 629 indicates dependencies on any other trusted components, each 630 dependency can include a list of TAM URIs for the relevant 631 dependency. If such dependencies exist that are prerequisites to 632 install the Trusted Component, then the TEEP Agent recursively 633 follows the same procedure for each dependency that needs to be 634 installed or updated, including selecting a TAM URI that is 635 consistent with the list of trusted TAMs provisioned on the device, 636 and beginning a TEEP exchange. If multiple TAM URIs are considered 637 trusted, only one needs to be contacted and they can be attempted in 638 some order until one responds. 640 Separate from the Untrusted Application's manifest, this framework 641 relies on the use of the manifest format in [I-D.ietf-suit-manifest] 642 for expressing how to install a Trusted Component, as well as any 643 dependencies on other TEE components and versions. That is, 644 dependencies from Trusted Components on other Trusted Components can 645 be expressed in a SUIT manifest, including dependencies on any other 646 TAs, trusted OS code (if any), or trusted firmware. Installation 647 steps can also be expressed in a SUIT manifest. 649 For example, TEEs compliant with GlobalPlatform [GPTEE] may have a 650 notion of a "security domain" (which is a grouping of one or more TAs 651 installed on a device, that can share information within such a 652 group) that must be created and into which one or more TAs can then 653 be installed. It is thus up to the SUIT manifest to express a 654 dependency on having such a security domain existing or being created 655 first, as appropriate. 657 Updating a Trusted Component may cause compatibility issues with any 658 Untrusted Applications or other components that depend on the updated 659 Trusted Component, just like updating the OS or a shared library 660 could impact an Untrusted Application. Thus, an implementation needs 661 to take into account such issues. 663 4.4. Untrusted Apps, Trusted Apps, and Personalization Data 665 In TEEP, there is an explicit relationship and dependence between an 666 Untrusted Application in an REE and one or more TAs in a TEE, as 667 shown in Figure 2. For most purposes, an Untrusted Application that 668 uses one or more TAs in a TEE appears no different from any other 669 Untrusted Application in the REE. However, the way the Untrusted 670 Application and its corresponding TAs are packaged, delivered, and 671 installed on the device can vary. The variations depend on whether 672 the Untrusted Application and TA are bundled together or are provided 673 separately, and this has implications to the management of the TAs in 674 a TEE. In addition to the Untrusted Application and TA(s), the TA(s) 675 and/or TEE may also require additional data to personalize the TA to 676 the device or a user. Implementations must support encryption of 677 such Personalization Data to preserve the confidentiality of 678 potentially sensitive data contained within it, and must support 679 integrity protection of the Personalization Data. Other than the 680 requirement to support confidentiality and integrity protection, the 681 TEEP architecture places no limitations or requirements on the 682 Personalization Data. 684 There are multiple possible cases for bundling of an Untrusted 685 Application, TA(s), and Personalization Data. Such cases include 686 (possibly among others): 688 1. The Untrusted Application, TA(s), and Personalization Data are 689 all bundled together in a single package by a Trusted Component 690 Signer and either provided to the TEEP Broker through the TAM, or 691 provided separately (with encrypted Personalization Data), with 692 key material needed to decrypt and install the Personalization 693 Data and TA provided by a TAM. 695 2. The Untrusted Application and the TA(s) are bundled together in a 696 single package, which a TAM or a publicly accessible app store 697 maintains, and the Personalization Data is separately provided by 698 the Personalization Data provider's TAM. 700 3. All components are independent packages. The Untrusted 701 Application is installed through some independent or device- 702 specific mechanism, and one or more TAMs provide (directly or 703 indirectly by reference) the TA(s) and Personalization Data. 705 4. The TA(s) and Personalization Data are bundled together into a 706 package provided by a TAM, while the Untrusted Application is 707 installed through some independent or device-specific mechanism 708 such as an app store. 710 5. Encrypted Personalization Data is bundled into a package 711 distributed with the Untrusted Application, while the TA(s) and 712 key material needed to decrypt and install the Personalization 713 Data are in a separate package provided by a TAM. 715 The TEEP protocol can treat each TA, any dependencies the TA has, and 716 Personalization Data as separate Trusted Components with separate 717 installation steps that are expressed in SUIT manifests, and a SUIT 718 manifest might contain or reference multiple binaries (see 719 [I-D.ietf-suit-manifest] for more details). The TEEP Agent is 720 responsible for handling any installation steps that need to be 721 performed inside the TEE, such as decryption of private TA binaries 722 or Personalization Data. 724 In order to better understand these cases, it is helpful to review 725 actual implementations of TEEs and their application delivery 726 mechanisms. 728 4.4.1. Example: Application Delivery Mechanisms in Intel SGX 730 In Intel Software Guard Extensions (SGX), the Untrusted Application 731 and TA are typically bundled into the same package (Case 2). The TA 732 exists in the package as a shared library (.so or .dll). The 733 Untrusted Application loads the TA into an SGX enclave when the 734 Untrusted Application needs the TA. This organization makes it easy 735 to maintain compatibility between the Untrusted Application and the 736 TA, since they are updated together. It is entirely possible to 737 create an Untrusted Application that loads an external TA into an SGX 738 enclave, and use that TA (Cases 3-5). In this case, the Untrusted 739 Application would require a reference to an external file or download 740 such a file dynamically, place the contents of the file into memory, 741 and load that as a TA. Obviously, such file or downloaded content 742 must be properly formatted and signed for it to be accepted by the 743 SGX TEE. 745 In SGX, any Personalization Data is normally loaded into the SGX 746 enclave (the TA) after the TA has started. Although it is possible 747 with SGX to include the Untrusted Application in an encrypted package 748 along with Personalization Data (Cases 1 and 5), there are no 749 instances of this known to be in use at this time, since such a 750 construction would require a special installation program and SGX TA 751 (which might or might not be the TEEP Agent itself based on the 752 implementation) to receive the encrypted package, decrypt it, 753 separate it into the different elements, and then install each one. 754 This installation is complex because the Untrusted Application 755 decrypted inside the TEE must be passed out of the TEE to an 756 installer in the REE which would install the Untrusted Application. 757 Finally, the Personalization Data would need to be sent out of the 758 TEE (encrypted in an SGX enclave-to-enclave manner) to the REE's 759 installation app, which would pass this data to the installed 760 Untrusted Application, which would in turn send this data to the SGX 761 enclave (TA). This complexity is due to the fact that each SGX 762 enclave is separate and does not have direct communication to other 763 SGX enclaves. 765 As long as signed files (TAs and/or Personalization Data) are 766 installed into an untrusted filesystem and trust is verified by the 767 TEE at load time, classic distribution mechanisms can be used. Some 768 uses of SGX, however, allow a model where a TA can be dynamically 769 installed into an SGX enclave that provides a runtime platform. The 770 TEEP protocol can be used in such cases, where the runtime platform 771 could include a TEEP Agent. 773 4.4.2. Example: Application Delivery Mechanisms in Arm TrustZone 775 In Arm TrustZone [TrustZone] for A-class devices, the Untrusted 776 Application and TA may or may not be bundled together. This differs 777 from SGX since in TrustZone the TA lifetime is not inherently tied to 778 a specific Untrused Application process lifetime as occurs in SGX. A 779 TA is loaded by a trusted OS running in the TEE such as a 780 GlobalPlatform [GPTEE] compliant TEE, where the trusted OS is 781 separate from the OS in the REE. Thus Cases 2-4 are equally 782 applicable. In addition, it is possible for TAs to communicate with 783 each other without involving any Untrusted Application, and so the 784 complexity of Cases 1 and 5 are lower than in the SGX example, though 785 still more complex than Cases 2-4. 787 A trusted OS running in the TEE (e.g., OP-TEE) that supports loading 788 and verifying signed TAs from an untrusted filesystem can, like SGX, 789 use classic file distribution mechanisms. If secure TA storage is 790 used (e.g., a Replay-Protected Memory Block device) on the other 791 hand, the TEEP protocol can be used to manage such storage. 793 4.5. Entity Relations 795 This architecture leverages asymmetric cryptography to authenticate a 796 device to a TAM. Additionally, a TEEP Agent in a device 797 authenticates a TAM. The provisioning of Trust Anchors to a device 798 may be different from one use case to the other. A Device 799 Administrator may want to have the capability to control what TAs are 800 allowed. A device manufacturer enables verification by one or more 801 TAMs and by Trusted Component Signers; it may embed a list of default 802 Trust Anchors into the TEEP Agent and TEE for TAM trust verification 803 and TA signature verification. 805 (App Developers) (App Store) (TAM) (Device with TEE) (CAs) 806 | | | | | 807 | | | (Embedded TEE cert) <--| 808 | | | | | 809 | <--- Get an app cert -----------------------------------| 810 | | | | | 811 | | | <-- Get a TAM cert ---------| 812 | | | | | 813 1. Build two apps: | | | | 814 | | | | 815 (a) Untrusted | | | | 816 App - 2a. Supply --> | --- 3. Install ------> | | 817 | | | | 818 (b) TA -- 2b. Supply ----------> | 4. Messaging-->| | 819 | | | | 821 Figure 3: Example Developer Experience 823 Figure 3 shows an example where the same developer builds and signs 824 two applications: (a) an Untrusted Application; (b) a TA that 825 provides some security functions to be run inside a TEE. This 826 example assumes that the developer, the TEE, and the TAM have 827 previously been provisioned with certificates. 829 At step 1, the developer authors the two applications. 831 At step 2, the developer uploads the Untrusted Application (2a) to an 832 Application Store. In this example, the developer is also the 833 Trusted Component Signer, and so generates a signed TA. The 834 developer can then either bundle the signed TA with the Untrusted 835 Application, or the developer can provide a signed Trusted Component 836 containing the TA to a TAM that will be managing the TA in various 837 devices. 839 At step 3, a user will go to an Application Store to download the 840 Untrusted Application (where the arrow indicates the direction of 841 data transfer). 843 At step 4, since the Untrusted Application depends on the TA, 844 installing the Untrusted Application will trigger TA installation via 845 communication with a TAM. The TEEP Agent will interact with the TAM 846 via a TEEP Broker that faciliates communications between the TAM and 847 the TEEP Agent. 849 Some Trusted Component installation implementations might ask for a 850 user's consent. In other implementations, a Device Administrator 851 might choose what Untrusted Applications and related Trusted 852 Components to be installed. A user consent flow is out of scope of 853 the TEEP architecture. 855 The main components of the TEEP protocol consist of a set of standard 856 messages created by a TAM to deliver Trusted Component management 857 commands to a device, and device attestation and response messages 858 created by a TEE that responds to a TAM's message. 860 It should be noted that network communication capability is generally 861 not available in TAs in today's TEE-powered devices. Consequently, 862 Trusted Applications generally rely on a broker in the REE to provide 863 access to network functionality in the REE. A broker does not need 864 to know the actual content of messages to facilitate such access. 866 Similarly, since the TEEP Agent runs inside a TEE, the TEEP Agent 867 generally relies on a TEEP Broker in the REE to provide network 868 access, and relay TAM requests to the TEEP Agent and relay the 869 responses back to the TAM. 871 5. Keys and Certificate Types 873 This architecture leverages the following credentials, which allow 874 achieving end-to-end security between a TAM and a TEEP Agent. 876 Figure 4 summarizes the relationships between various keys and where 877 they are stored. Each public/private key identifies a Trusted 878 Component Signer, TAM, or TEE, and gets a certificate that chains up 879 to some trust anchor. A list of trusted certificates is used to 880 check a presented certificate against. 882 Different CAs can be used for different types of certificates. TEEP 883 messages are always signed, where the signer key is the message 884 originator's private key, such as that of a TAM or a TEE. In 885 addition to the keys shown in Figure 4, there may be additional keys 886 used for attestation or encryption. Refer to the RATS Architecture 887 [I-D.ietf-rats-architecture] for more discussion. 889 Cardinality & Location of 890 Location of Private Key Trust Anchor 891 Purpose Private Key Signs Store 892 ------------------ ----------- ------------- ------------- 893 Authenticating 1 per TEE TEEP responses TAM 894 TEEP Agent 896 Authenticating TAM 1 per TAM TEEP requests TEEP Agent 898 Code Signing 1 per Trusted TA binary TEE 899 Component 900 Signer 902 Figure 4: Signature Keys 904 Note that Personalization Data is not included in the table above. 905 The use of Personalization Data is dependent on how TAs are used and 906 what their security requirements are. 908 TEEP requests from a TAM to a TEEP Agent are signed with the TAM 909 private key (for authentication and integrity protection). 910 Personalization Data and TA binaries can be encrypted with a key that 911 is established with a content-encryption key established with the TEE 912 public key (to provide confidentiality). Conversely, TEEP responses 913 from a TEEP Agent to a TAM can be signed with the TEE private key. 915 The TEE key pair and certificate are thus used for authenticating the 916 TEE to a remote TAM, and for sending private data to the TEE. Often, 917 the key pair is burned into the TEE by the TEE manufacturer and the 918 key pair and its certificate are valid for the expected lifetime of 919 the TEE. A TAM provider is responsible for configuring the TAM's 920 Trust Anchor Store with the manufacturer certificates or CAs that are 921 used to sign TEE keys. This is discussed further in Section 5.3 922 below. Typically the same key TEE pair is used for both signing and 923 encryption, though separate key pairs might also be used in the 924 future, as the joint security of encryption and signature with a 925 single key remains to some extent an open question in academic 926 cryptography. 928 The TAM key pair and certificate are used for authenticating a TAM to 929 a remote TEE, and for sending private data to the TAM (separate key 930 pairs for authentication vs. encryption could also be used in the 931 future). A TAM provider is responsible for acquiring a certificate 932 from a CA that is trusted by the TEEs it manages. This is discussed 933 further in Section 5.1 below. 935 The Trusted Component Signer key pair and certificate are used to 936 sign Trusted Components that the TEE will consider authorized to 937 execute. TEEs must be configured with the certificates or keys that 938 it considers authorized to sign TAs that it will execute. This is 939 discussed further in Section 5.2 below. 941 5.1. Trust Anchors in a TEEP Agent 943 A TEEP Agent's Trust Anchor Store contains a list of Trust Anchors, 944 which are typically CA certificates that sign various TAM 945 certificates. The list is typically preloaded at manufacturing time, 946 and can be updated using the TEEP protocol if the TEE has some form 947 of "Trust Anchor Manager TA" that has Trust Anchors in its 948 configuration data. Thus, Trust Anchors can be updated similarly to 949 the Personalization Data for any other TA. 951 When Trust Anchor update is carried out, it is imperative that any 952 update must maintain integrity where only an authentic Trust Anchor 953 list from a device manufacturer or a Device Administrator is 954 accepted. Details are out of scope of the architecture and can be 955 addressed in a protocol document. 957 Before a TAM can begin operation in the marketplace to support a 958 device with a particular TEE, it must be able to get its raw public 959 key, or its certificate, or a certificate it chains up to, listed in 960 the Trust Anchor Store of the TEEP Agent. 962 5.2. Trust Anchors in a TEE 964 The Trust Anchor Store in a TEE contains a list of Trust Anchors (raw 965 public keys or certificates) that are used to determine whether TA 966 binaries are allowed to execute by checking if their signatures can 967 be verified. The list is typically preloaded at manufacturing time, 968 and can be updated using the TEEP protocol if the TEE has some form 969 of "Trust Anchor Manager TA" that has Trust Anchors in its 970 configuration data. Thus, Trust Anchors can be updated similarly to 971 the Personalization Data for any other TA, as discussed in 972 Section 5.1. 974 5.3. Trust Anchors in a TAM 976 The Trust Anchor Store in a TAM consists of a list of Trust Anchors, 977 which are certificates that sign various device TEE certificates. A 978 TAM will accept a device for Trusted Component management if the TEE 979 in the device uses a TEE certificate that is chained to a certificate 980 or raw public key that the TAM trusts, is contained in an allow list, 981 is not found on a block list, and/or fulfills any other policy 982 criteria. 984 5.4. Scalability 986 This architecture uses a PKI (including self-signed certificates). 987 Trust Anchors exist on the devices to enable the TEEP Agent to 988 authenticate TAMs and the TEE to authenticate Trusted Component 989 Signers, and TAMs use Trust Anchors to authenticate TEEP Agents. 990 When a PKI is used, many intermediate CA certificates can chain to a 991 root certificate, each of which can issue many certificates. This 992 makes the protocol highly scalable. New factories that produce TEEs 993 can join the ecosystem. In this case, such a factory can get an 994 intermediate CA certificate from one of the existing roots without 995 requiring that TAMs are updated with information about the new device 996 factory. Likewise, new TAMs can join the ecosystem, providing they 997 are issued a TAM certificate that chains to an existing root whereby 998 existing TEEs will be allowed to be personalized by the TAM without 999 requiring changes to the TEE itself. This enables the ecosystem to 1000 scale, and avoids the need for centralized databases of all TEEs 1001 produced or all TAMs that exist or all Trusted Component Signers that 1002 exist. 1004 5.5. Message Security 1006 Messages created by a TAM are used to deliver Trusted Component 1007 management commands to a device, and device attestation and messages 1008 are created by the device TEE to respond to TAM messages. 1010 These messages are signed end-to-end between a TEEP Agent and a TAM. 1011 Confidentiality is provided by encrypting sensitive payloads (such as 1012 Personalization Data and attestation evidence), rather than 1013 encrypting the messages themselves. Using encrypted payloads is 1014 important to ensure that only the targeted device TEE or TAM is able 1015 to decrypt and view the actual content. 1017 6. TEEP Broker 1019 A TEE and TAs often do not have the capability to directly 1020 communicate outside of the hosting device. For example, 1021 GlobalPlatform [GPTEE] specifies one such architecture. This calls 1022 for a software module in the REE world to handle network 1023 communication with a TAM. 1025 A TEEP Broker is an application component running in the REE of the 1026 device or an SDK that facilitates communication between a TAM and a 1027 TEE. It also provides interfaces for Untrusted Applications to query 1028 and trigger installation of Trusted Components that the application 1029 needs to use. 1031 An Untrusted Application might communicate with a TEEP Broker at 1032 runtime to trigger Trusted Component installation itself, or an 1033 Untrusted Application might simply have a metadata file that 1034 describes the Trusted Components it depends on and the associated 1035 TAM(s) for each Trusted Component, and an REE Application Installer 1036 can inspect this application metadata file and invoke the TEEP Broker 1037 to trigger Trusted Component installation on behalf of the Untrusted 1038 Application without requiring the Untrusted Application to run first. 1040 6.1. Role of the TEEP Broker 1042 A TEEP Broker abstracts the message exchanges with a TEE in a device. 1043 The input data is originated from a TAM or the first initialization 1044 call to trigger a Trusted Component installation. 1046 The Broker doesn't need to parse TEEP message content received from a 1047 TAM that should be processed by a TEE (see the ProcessTeepMessage API 1048 in Section 6.2.1). When a device has more than one TEE, one TEEP 1049 Broker per TEE could be present in the REE or a common TEEP Broker 1050 could be used by multiple TEEs where the transport protocol (e.g., 1051 [I-D.ietf-teep-otrp-over-http]) allows the TEEP Broker to distinguish 1052 which TEE is relevant for each message from a TAM. 1054 The TEEP Broker interacts with a TEEP Agent inside a TEE, and relays 1055 the response messages generated from the TEEP Agent back to the TAM. 1057 The Broker only needs to return a (transport) error message to the 1058 TAM if the TEE is not reachable for some reason. Other errors are 1059 represented as TEEP response messages returned from the TEE which 1060 will then be passed to the TAM. 1062 6.2. TEEP Broker Implementation Consideration 1064 As depicted in Figure 5, there are multiple ways in which a TEEP 1065 Broker can be implemented, with more or fewer layers being inside the 1066 TEE. For example, in model A, the model with the smallest TEE 1067 footprint, only the TEEP implementation is inside the TEE, whereas 1068 the TEEP/HTTP implementation is in the TEEP Broker outside the TEE. 1070 Model: A B C ... 1072 TEE TEE TEE 1073 +----------------+ | | | 1074 | TEEP | Agent | | | Agent 1075 | implementation | | | | 1076 +----------------+ v | | 1077 | | | 1078 +----------------+ ^ | | 1079 | TEEP/HTTP | Broker | | | 1080 | implementation | | | | 1081 +----------------+ | v | 1082 | | | 1083 +----------------+ | ^ | 1084 | HTTP(S) | | | | 1085 | implementation | | | | 1086 +----------------+ | | v 1087 | | | 1088 +----------------+ | | ^ 1089 | TCP or QUIC | | | | Broker 1090 | implementation | | | | 1091 +----------------+ | | | 1092 REE REE REE 1094 Figure 5: TEEP Broker Models 1096 In other models, additional layers are moved into the TEE, increasing 1097 the TEE footprint, with the Broker either containing or calling the 1098 topmost protocol layer outside of the TEE. An implementation is free 1099 to choose any of these models. 1101 TEEP Broker implementers should consider methods of distribution, 1102 scope and concurrency on devices and runtime options. 1104 6.2.1. TEEP Broker APIs 1106 The following conceptual APIs exist from a TEEP Broker to a TEEP 1107 Agent: 1109 1. RequestTA: A notification from an REE application (e.g., an 1110 installer, or an Untrusted Application) that it depends on a 1111 given Trusted Component, which may or may not already be 1112 installed in the TEE. 1114 2. UnrequestTA: A notification from an REE application (e.g., an 1115 installer, or an Untrusted Application) that it no longer depends 1116 on a given Trusted Component, which may or may not already be 1117 installed in the TEE. For example, if the Untrusted Application 1118 is uninstalled, the uninstaller might invoke this conceptual API. 1120 3. ProcessTeepMessage: A message arriving from the network, to be 1121 delivered to the TEEP Agent for processing. 1123 4. RequestPolicyCheck: A hint (e.g., based on a timer) that the TEEP 1124 Agent may wish to contact the TAM for any changes, without the 1125 device itself needing any particular change. 1127 5. ProcessError: A notification that the TEEP Broker could not 1128 deliver an outbound TEEP message to a TAM. 1130 For comparison, similar APIs may exist on the TAM side, where a 1131 Broker may or may not exist, depending on whether the TAM uses a TEE 1132 or not: 1134 1. ProcessConnect: A notification that a new TEEP session is being 1135 requested by a TEEP Agent. 1137 2. ProcessTeepMessage: A message arriving on an existing TEEP 1138 session, to be delivered to the TAM for processing. 1140 For further discussion on these APIs, see 1141 [I-D.ietf-teep-otrp-over-http]. 1143 6.2.2. TEEP Broker Distribution 1145 The Broker installation is commonly carried out at OEM time. A user 1146 can dynamically download and install a Broker on-demand. 1148 7. Attestation 1150 Attestation is the process through which one entity (an Attester) 1151 presents "evidence", in the form of a series of claims, to another 1152 entity (a Verifier), and provides sufficient proof that the claims 1153 are true. Different Verifiers may require different degrees of 1154 confidence in attestation proofs and not all attestations are 1155 acceptable to every verifier. A third entity (a Relying Party) can 1156 then use "attestation results", in the form of another series of 1157 claims, from a Verifier to make authorization decisions. (See 1158 [I-D.ietf-rats-architecture] for more discussion.) 1159 In TEEP, as depicted in Figure 6, the primary purpose of an 1160 attestation is to allow a device (the Attester) to prove to a TAM 1161 (the Relying Party) that a TEE in the device has particular 1162 properties, was built by a particular manufacturer, and/or is 1163 executing a particular TA. Other claims are possible; TEEP does not 1164 limit the claims that may appear in evidence or attestation results, 1165 but defines a minimal set of attestation result claims required for 1166 TEEP to operate properly. Extensions to these claims are possible. 1167 Other standards or groups may define the format and semantics of 1168 extended claims. 1170 +----------------+ 1171 | Device | +----------+ 1172 | +------------+ | Evidence | TAM | Evidence +----------+ 1173 | | TEE |------------->| (Relying |-------------->| Verifier | 1174 | | (Attester) | | | Party) |<--------------| | 1175 | +------------+ | +----------+ Attestation +----------+ 1176 +----------------+ Result 1178 Figure 6: TEEP Attestation Roles 1180 As of the writing of this specification, device and TEE attestations 1181 have not been standardized across the market. Different devices, 1182 manufacturers, and TEEs support different attestation protocols. In 1183 order for TEEP to be inclusive, it is agnostic to the format of 1184 evidence, allowing proprietary or standardized formats to be used 1185 between a TEE and a verifier (which may or may not be colocated in 1186 the TAM), as long as the format supports encryption of any 1187 information that is considered sensitive. 1189 However, it should be recognized that not all Verifiers may be able 1190 to process all proprietary forms of attestation evidence. Similarly, 1191 the TEEP protocol is agnostic as to the format of attestation 1192 results, and the protocol (if any) used between the TAM and a 1193 verifier, as long as they convey at least the required set of claims 1194 in some format. Note that the respective attestation algorithms are 1195 not defined in the TEEP protocol itself; see 1196 [I-D.ietf-rats-architecture] and [I-D.ietf-teep-protocol] for more 1197 discussion. 1199 There are a number of considerations that need to be considered when 1200 appraising evidence provided by a TEE, including: 1202 * What security measures a manufacturer takes when provisioning keys 1203 into devices/TEEs; 1205 * What hardware and software components have access to the 1206 attestation keys of the TEE; 1208 * The source or local verification of claims within an attestation 1209 prior to a TEE signing a set of claims; 1211 * The level of protection afforded to attestation keys against 1212 exfiltration, modification, and side channel attacks; 1214 * The limitations of use applied to TEE attestation keys; 1216 * The processes in place to discover or detect TEE breaches; and 1218 * The revocation and recovery process of TEE attestation keys. 1220 Some TAMs may require additional claims in order to properly 1221 authorize a device or TEE. The specific format for these additional 1222 claims are outside the scope of this specification, but the TEEP 1223 protocol allows these additional claims to be included in the 1224 attestation messages. 1226 For more discussion of the attestation and appraisal process, see the 1227 RATS Architecture [I-D.ietf-rats-architecture]. 1229 The following information is required for TEEP attestation: 1231 * Device Identifying Information: Attestation information may need 1232 to uniquely identify a device to the TAM. Unique device 1233 identification allows the TAM to provide services to the device, 1234 such as managing installed TAs, and providing subscriptions to 1235 services, and locating device-specific keying material to 1236 communicate with or authenticate the device. In some use cases it 1237 may be sufficient to identify only the class of the device. The 1238 security and privacy requirements regarding device identification 1239 will vary with the type of TA provisioned to the TEE. 1241 * TEE Identifying Information: The type of TEE that generated this 1242 attestation must be identified. This includes version 1243 identification information for hardware, firmware, and software 1244 version of the TEE, as applicable by the TEE type. TEE 1245 manufacturer information for the TEE is required in order to 1246 disambiguate the same TEE type created by different manufacturers 1247 and address considerations around manufacturer provisioning, 1248 keying and support for the TEE. 1250 * Freshness Proof: A claim that includes freshness information must 1251 be included, such as a nonce or timestamp. 1253 8. Algorithm and Attestation Agility 1255 RFC 7696 [RFC7696] outlines the requirements to migrate from one 1256 mandatory-to-implement cryptographic algorithm suite to another over 1257 time. This feature is also known as crypto agility. Protocol 1258 evolution is greatly simplified when crypto agility is considered 1259 during the design of the protocol. In the case of the TEEP protocol 1260 the diverse range of use cases, from trusted app updates for smart 1261 phones and tablets to updates of code on higher-end IoT devices, 1262 creates the need for different mandatory-to-implement algorithms 1263 already from the start. 1265 Crypto agility in TEEP concerns the use of symmetric as well as 1266 asymmetric algorithms. In the context of TEEP, symmetric algorithms 1267 are used for encryption and integrity protection of TA binaries and 1268 Personalization Data whereas the asymmetric algorithms are used for 1269 signing messages and managing symmetric keys. 1271 In addition to the use of cryptographic algorithms in TEEP, there is 1272 also the need to make use of different attestation technologies. A 1273 device must provide techniques to inform a TAM about the attestation 1274 technology it supports. For many deployment cases it is more likely 1275 for the TAM to support one or more attestation techniques whereas the 1276 device may only support one. 1278 9. Security Considerations 1280 9.1. Broker Trust Model 1282 The architecture enables the TAM to communicate, via a TEEP Broker, 1283 with the device's TEE to manage Trusted Components. Since the TEEP 1284 Broker runs in a potentially vulnerable REE, the TEEP Broker could, 1285 however, be (or be infected by) malware. As such, all TAM messages 1286 are signed and sensitive data is encrypted such that the TEEP Broker 1287 cannot modify or capture sensitive data, but the TEEP Broker can 1288 still conduct DoS attacks as discussed in Section 9.3. 1290 A TEEP Agent in a TEE is responsible for protecting against potential 1291 attacks from a compromised TEEP Broker or rogue malware in the REE. 1292 A rogue TEEP Broker might send corrupted data to the TEEP Agent, or 1293 launch a DoS attack by sending a flood of TEEP protocol requests, or 1294 simply drop or delay notifications to a TEE. The TEEP Agent 1295 validates the signature of each TEEP protocol request and checks the 1296 signing certificate against its Trust Anchors. To mitigate DoS 1297 attacks, it might also add some protection scheme such as a threshold 1298 on repeated requests or number of TAs that can be installed. 1300 Some implementations might rely on (due to lack of any available 1301 alternative) the use of an untrusted timer or other event to call the 1302 RequestPolicyCheck API (Section 6.2.1), which means that a 1303 compromised REE can cause a TEE to not receive policy changes and 1304 thus be out of date with respect to policy. The same can potentially 1305 be done by any other man-in-the-middle simply by blocking 1306 communication with a TAM. Ultimately such outdated compliance could 1307 be addressed by using attestation in secure communication, where the 1308 attestation evidence reveals what state the TEE is in, so that 1309 communication (other than remediation such as via TEEP) from an out- 1310 of-compliance TEE can be rejected. 1312 Similarly, in most implementations the REE is involved in the 1313 mechanics of installing new TAs. However, the authority for what TAs 1314 are running in a given TEE is between the TEEP Agent and the TAM. 1315 While a TEEP Broker broker can in effect make suggestions, it cannot 1316 decide or enforce what runs where. The TEEP Broker can also control 1317 which TEE a given installation request is directed at, but a TEEP 1318 Agent will only accept TAs that are actually applicable to it and 1319 where installation instructions are received by a TAM that it trusts. 1321 The authorization model for the UnrequestTA operation is, however, 1322 weaker in that it expresses the removal of a dependency from an 1323 application that was untrusted to begin with. This means that a 1324 compromised REE could remove a valid dependency from an Untrusted 1325 Application on a TA. Normal REE security mechanisms should be used 1326 to protect the REE and Untrusted Applications. 1328 9.2. Data Protection 1330 It is the responsibility of the TAM to protect data on its servers. 1331 Similarly, it is the responsibility of the TEE implementation to 1332 provide protection of data against integrity and confidentiality 1333 attacks from outside the TEE. TEEs that provide isolation among TAs 1334 within the TEE are likewise responsible for protecting TA data 1335 against the REE and other TAs. For example, this can be used to 1336 protect one user's or tenant's data from compromise by another user 1337 or tenant, even if the attacker has TAs. 1339 The protocol between TEEP Agents and TAMs similarly is responsible 1340 for securely providing integrity and confidentiality protection 1341 against adversaries between them. It is a design choice at what 1342 layers to best provide protection against network adversaries. As 1343 discussed in Section 6, the transport protocol and any security 1344 mechanism associated with it (e.g., the Transport Layer Security 1345 protocol) under the TEEP protocol may terminate outside a TEE. If it 1346 does, the TEEP protocol itself must provide integrity protection and 1347 confidentiality protection to secure data end-to-end. For example, 1348 confidentiality protection for payloads may be provided by utilizing 1349 encrypted TA binaries and encrypted attestation information. See 1350 [I-D.ietf-teep-protocol] for how a specific solution addresses the 1351 design question of how to provide integrity and confidentiality 1352 protection. 1354 9.3. Compromised REE 1356 It is possible that the REE of a device is compromised. We have 1357 already seen examples of attacks on the public Internet with billions 1358 of compromised devices being used to mount DDoS attacks. A 1359 compromised REE can be used for such an attack but it cannot tamper 1360 with the TEE's code or data in doing so. A compromised REE can, 1361 however, launch DoS attacks against the TEE. 1363 The compromised REE may terminate the TEEP Broker such that TEEP 1364 transactions cannot reach the TEE, or might drop or delay messages 1365 between a TAM and a TEEP Agent. However, while a DoS attack cannot 1366 be prevented, the REE cannot access anything in the TEE if the TEE is 1367 implemented correctly. Some TEEs may have some watchdog scheme to 1368 observe REE state and mitigate DoS attacks against it but most TEEs 1369 don't have such a capability. 1371 In some other scenarios, the compromised REE may ask a TEEP Broker to 1372 make repeated requests to a TEEP Agent in a TEE to install or 1373 uninstall a Trusted Component. An installation or uninstallation 1374 request constructed by the TEEP Broker or REE will be rejected by the 1375 TEEP Agent because the request won't have the correct signature from 1376 a TAM to pass the request signature validation. 1378 This can become a DoS attack by exhausting resources in a TEE with 1379 repeated requests. In general, a DoS attack threat exists when the 1380 REE is compromised, and a DoS attack can happen to other resources. 1381 The TEEP architecture doesn't change this. 1383 A compromised REE might also request initiating the full flow of 1384 installation of Trusted Components that are not necessary. It may 1385 also repeat a prior legitimate Trusted Component installation 1386 request. A TEEP Agent implementation is responsible for ensuring 1387 that it can recognize and decline such repeated requests. It is also 1388 responsible for protecting the resource usage allocated for Trusted 1389 Component management. 1391 9.4. CA Compromise or Expiry of CA Certificate 1393 A root CA for TAM certificates might get compromised or its 1394 certificate might expire, or a Trust Anchor other than a root CA 1395 certificate may also expire or be compromised. TEEs are responsible 1396 for validating the entire TAM certificate path, including the TAM 1397 certificate and any intermediate certificates up to the root 1398 certificate. See Section 6 of [RFC5280] for details. Such 1399 validation generally includes checking for certificate revocation, 1400 but certificate status check protocols may not scale down to 1401 constrained devices that use TEEP. 1403 To address the above issues, a certificate path update mechanism is 1404 expected from TAM operators, so that the TAM can get a new 1405 certificate path that can be validated by a TEEP Agent. In addition, 1406 the Trust Anchor in the TEEP Agent's Trust Anchor Store may need to 1407 be updated. To address this, some TEE Trust Anchor update mechanism 1408 is expected from device OEMs, such as using the TEEP protocol to 1409 distribute new Trust Anchors. 1411 Similarly, a root CA for TEE certificates might get compromised or 1412 its certificate might expire, or a Trust Anchor other than a root CA 1413 certificate may also expire or be compromised. TAMs are responsible 1414 for validating the entire TEE certificate path, including the TEE 1415 certificate and any intermediate certificates up to the root 1416 certificate. Such validation includes checking for certificate 1417 revocation. 1419 If a TEE certificate path validation fails, the TEE might be rejected 1420 by a TAM, subject to the TAM's policy. To address this, some 1421 certificate path update mechanism is expected from device OEMs, so 1422 that the TEE can get a new certificate path that can be validated by 1423 a TAM. In addition, the Trust Anchor in the TAM's Trust Anchor Store 1424 may need to be updated. 1426 9.5. Compromised TAM 1428 Device TEEs are responsible for validating the supplied TAM 1429 certificates to determine that the TAM is trustworthy. 1431 9.6. Malicious TA Removal 1433 It is possible that a rogue developer distributes a malicious 1434 Untrusted Application and intends to get a malicious TA installed. 1435 Such a TA might be able to escape from malware detection by the REE, 1436 or access trusted resources within the TEE (but could not access 1437 other TEEs, or access other TA's if the TEE provides isolation 1438 between TAs). 1440 It is the responsibility of the TAM to not install malicious TAs in 1441 the first place. The TEEP architecture allows a TEEP Agent to decide 1442 which TAMs it trusts via Trust Anchors, and delegates the TA 1443 authenticity check to the TAMs it trusts. 1445 It may happen that a TA was previously considered trustworthy but is 1446 later found to be buggy or compromised. In this case, the TAM can 1447 initiate the removal of the TA by notifying devices to remove the TA 1448 (and potentially the REE or Device Owner to remove any Untrusted 1449 Application that depend on the TA). If the TAM does not currently 1450 have a connection to the TEEP Agent on a device, such a notification 1451 would occur the next time connectivity does exist. That is, to 1452 recover, the TEEP Agent must be able to reach out to the TAM, for 1453 example whenever the RequestPolicyCheck API (Section 6.2.1) is 1454 invoked by a timer or other event. 1456 Furthermore the policy in the Verifier in an attestation process can 1457 be updated so that any evidence that includes the malicious TA would 1458 result in an attestation failure. There is, however, a time window 1459 during which a malicious TA might be able to operate successfully, 1460 which is the validity time of the previous attestation result. For 1461 example, if the Verifier in Figure 6 is updated to treat a previously 1462 valid TA as no longer trustworthy, any attestation result it 1463 previously generated saying that the TA is valid will continue to be 1464 used until the attestation result expires. As such, the TAM's 1465 Verifier should take into account the acceptable time window when 1466 generating attestation results. See [I-D.ietf-rats-architecture] for 1467 further discussion. 1469 9.7. Certificate Expiry and Renewal 1471 TEE device certificates are expected to be long lived, longer than 1472 the lifetime of a device. A TAM certificate usually has a moderate 1473 lifetime of 2 to 5 years. A TAM should get renewed or rekeyed 1474 certificates. The root CA certificates for a TAM, which are embedded 1475 into the Trust Anchor Store in a device, should have long lifetimes 1476 that don't require device Trust Anchor updates. On the other hand, 1477 it is imperative that OEMs or device providers plan for support of 1478 Trust Anchor update in their shipped devices. 1480 For those cases where TEE devices are given certificates for which no 1481 good expiration date can be assigned the recommendations in 1482 Section 4.1.2.5 of [RFC5280] are applicable. 1484 9.8. Keeping Secrets from the TAM 1486 In some scenarios, it is desirable to protect the TA binary or 1487 Personalization Data from being disclosed to the TAM that distributes 1488 them. In such a scenario, the files can be encrypted end-to-end 1489 between a Trusted Component Signer and a TEE. However, there must be 1490 some means of provisioning the decryption key into the TEE and/or 1491 some means of the Trusted Component Signer securely learning a public 1492 key of the TEE that it can use to encrypt. The Trusted Component 1493 Signer cannot necessarily even trust the TAM to report the correct 1494 public key of a TEE for use with encryption, since the TAM might 1495 instead provide the public key of a TEE that it controls. 1497 One way to solve this is for the Trusted Component Signer to run its 1498 own TAM that is only used to distribute the decryption key via the 1499 TEEP protocol, and the key file can be a dependency in the manifest 1500 of the encrypted TA. Thus, the TEEP Agent would look at the Trusted 1501 Component manifest, determine there is a dependency with a TAM URI of 1502 the Trusted Component Signer's TAM. The Agent would then install the 1503 dependency, and then continue with the Trusted Component installation 1504 steps, including decrypting the TA binary with the relevant key. 1506 9.9. REE Privacy 1508 The TEEP architecture is applicable to cases where devices have a TEE 1509 that protects data and code from the REE administrator. In such 1510 cases, the TAM administrator, not the REE administrator, controls the 1511 TEE in the devices. As some examples: 1513 * a cloud hoster may be the REE administrator where a customer 1514 administrator controls the TEE hosted in the cloud. 1516 * a device manufacturer might control the TEE in a device purchased 1517 by a customer 1519 The privacy risk is that data in the REE might be susceptible to 1520 disclosure to the TEE administrator. This risk is not introduced by 1521 the TEEP architecture, but is inherent in most uses of TEEs. This 1522 risk can be mitigated by making sure the REE administrator is aware 1523 of and explicitly chooses to have a TEE that is managed by another 1524 party. In the cloud hoster example, this choice is made by 1525 explicitly offering a service to customers to provide TEEs for them 1526 to administer. In the device manufacturer example, this choice is 1527 made by the customer choosing to buy a device made by a given 1528 manufacturer. 1530 10. IANA Considerations 1532 This document does not require actions by IANA. 1534 11. Contributors 1536 * Andrew Atyeo, Intercede (andrew.atyeo@intercede.com) 1538 * Liu Dapeng, Alibaba Group (maxpassion@gmail.com) 1540 12. Acknowledgements 1542 We would like to thank Nick Cook, Minho Yoo, Brian Witten, Tyler Kim, 1543 Alin Mutu, Juergen Schoenwaelder, Nicolae Paladi, Sorin Faibish, Ned 1544 Smith, Russ Housley, Jeremy O'Donoghue, and Anders Rundgren for their 1545 feedback. 1547 13. Informative References 1549 [CC-Overview] 1550 Confidential Computing Consortium, "Confidential 1551 Computing: Hardware-Based Trusted Execution for 1552 Applications and Data", January 2021, 1553 . 1557 [CC-Technical-Analysis] 1558 Confidential Computing Consortium, "A Technical Analysis 1559 of Confidential Computing, v1.2", October 2021, 1560 . 1564 [GPTEE] GlobalPlatform, "GlobalPlatform Device Technology: TEE 1565 System Architecture, v1.1", GlobalPlatform GPD_SPE_009, 1566 January 2017, . 1569 [GSMA] GSM Association, "GP.22 RSP Technical Specification, 1570 Version 2.2.2", June 2020, . 1573 [I-D.ietf-rats-architecture] 1574 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 1575 W. Pan, "Remote Attestation Procedures Architecture", Work 1576 in Progress, Internet-Draft, draft-ietf-rats-architecture- 1577 15, 8 February 2022, . 1580 [I-D.ietf-suit-architecture] 1581 Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A 1582 Firmware Update Architecture for Internet of Things", Work 1583 in Progress, Internet-Draft, draft-ietf-suit-architecture- 1584 16, 27 January 2021, . 1587 [I-D.ietf-suit-manifest] 1588 Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, 1589 "A Concise Binary Object Representation (CBOR)-based 1590 Serialization Format for the Software Updates for Internet 1591 of Things (SUIT) Manifest", Work in Progress, Internet- 1592 Draft, draft-ietf-suit-manifest-16, 25 October 2021, 1593 . 1596 [I-D.ietf-teep-otrp-over-http] 1597 Thaler, D., "HTTP Transport for Trusted Execution 1598 Environment Provisioning: Agent Initiated Communication", 1599 Work in Progress, Internet-Draft, draft-ietf-teep-otrp- 1600 over-http-13, 28 February 2022, 1601 . 1604 [I-D.ietf-teep-protocol] 1605 Tschofenig, H., Pei, M., Wheeler, D., Thaler, D., and A. 1606 Tsukamoto, "Trusted Execution Environment Provisioning 1607 (TEEP) Protocol", Work in Progress, Internet-Draft, draft- 1608 ietf-teep-protocol-07, 25 October 2021, 1609 . 1612 [OTRP] GlobalPlatform, "Open Trust Protocol (OTrP) Profile v1.1", 1613 GlobalPlatform GPD_SPE_123, July 2020, 1614 . 1617 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1618 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1619 . 1621 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1622 Housley, R., and W. Polk, "Internet X.509 Public Key 1623 Infrastructure Certificate and Certificate Revocation List 1624 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1625 . 1627 [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management 1628 Requirements", RFC 6024, DOI 10.17487/RFC6024, October 1629 2010, . 1631 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 1632 Agility and Selecting Mandatory-to-Implement Algorithms", 1633 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 1634 . 1636 [SGX] Intel, "Intel(R) Software Guard Extensions (Intel (R) 1637 SGX)", n.d., . 1641 [TrustZone] 1642 Arm, "Arm TrustZone Technology", n.d., 1643 . 1646 Authors' Addresses 1648 Mingliang Pei 1649 Broadcom 1651 Email: mingliang.pei@broadcom.com 1653 Hannes Tschofenig 1654 Arm Limited 1656 Email: hannes.tschofenig@arm.com 1658 Dave Thaler 1659 Microsoft 1661 Email: dthaler@microsoft.com 1663 David Wheeler 1664 Amazon 1665 Email: davewhee@amazon.com