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