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