idnits 2.17.00 (12 Aug 2021) /tmp/idnits53604/draft-ietf-teep-architecture-05.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 (December 12, 2019) is 890 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-suit-manifest-02 == Outdated reference: A later version (-13) exists of draft-ietf-teep-otrp-over-http-03 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEEP M. Pei 3 Internet-Draft Symantec 4 Intended status: Informational H. Tschofenig 5 Expires: June 14, 2020 Arm Limited 6 D. Thaler 7 Microsoft 8 D. Wheeler 9 Intel 10 December 12, 2019 12 Trusted Execution Environment Provisioning (TEEP) Architecture 13 draft-ietf-teep-architecture-05 15 Abstract 17 A Trusted Execution Environment (TEE) is an environment that enforces 18 that only authorized code can execute with that environment, and that 19 any data used by such code cannot be read or tampered with by any 20 code outside that environment. This architecture document motivates 21 the design and standardization of a protocol for managing the 22 lifecycle of trusted applications running inside a TEE. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 14, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 7 75 3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 7 76 3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 7 77 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8 78 4.1. System Components . . . . . . . . . . . . . . . . . . . . 8 79 4.2. Different Renditions of TEEP Architecture . . . . . . . . 10 80 4.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 12 81 4.4. Untrusted Apps, Trusted Apps, and Personalization Data . 13 82 4.5. Examples of Application Delivery Mechanisms in Existing 83 TEEs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 4.6. Entity Relations . . . . . . . . . . . . . . . . . . . . 15 85 5. Keys and Certificate Types . . . . . . . . . . . . . . . . . 17 86 5.1. Trust Anchors in TEE . . . . . . . . . . . . . . . . . . 18 87 5.2. Trust Anchors in TAM . . . . . . . . . . . . . . . . . . 19 88 5.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 19 89 5.4. Message Security . . . . . . . . . . . . . . . . . . . . 19 90 6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 19 91 6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 20 92 6.2. TEEP Broker Implementation Consideration . . . . . . . . 20 93 6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 20 94 6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 21 95 6.2.3. Number of TEEP Brokers . . . . . . . . . . . . . . . 21 96 7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 22 97 7.1. Information Required in TEEP Claims . . . . . . . . . . . 23 98 8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 24 99 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 100 9.1. TA Trust Check at TEE . . . . . . . . . . . . . . . . . . 25 101 9.2. One TA Multiple SP Case . . . . . . . . . . . . . . . . . 25 102 9.3. Broker Trust Model . . . . . . . . . . . . . . . . . . . 25 103 9.4. Data Protection at TAM and TEE . . . . . . . . . . . . . 25 104 9.5. Compromised CA . . . . . . . . . . . . . . . . . . . . . 26 105 9.6. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 26 106 9.7. Certificate Renewal . . . . . . . . . . . . . . . . . . . 26 107 9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 26 108 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 109 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 110 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 111 13. Informative References . . . . . . . . . . . . . . . . . . . 27 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 114 1. Introduction 116 Applications executing in a device are exposed to many different 117 attacks intended to compromise the execution of the application, or 118 reveal the data upon which those applications are operating. These 119 attacks increase with the number of other applications on the device, 120 with such other applications coming from potentially untrustworthy 121 sources. The potential for attacks further increase with the 122 complexity of features and applications on devices, and the 123 unintended interactions among those features and applications. The 124 danger of attacks on a system increases as the sensitivity of the 125 applications or data on the device increases. As an example, 126 exposure of emails from a mail client is likely to be of concern to 127 its owner, but a compromise of a banking application raises even 128 greater concerns. 130 The Trusted Execution Environment (TEE) concept is designed to 131 execute applications in a protected environment that enforces that 132 only authorized code can execute with that environment, and that any 133 data used by such code cannot be read or tampered with by any code 134 outside that environment, including a commodity operating system (if 135 present). 137 This separation reduces the possibility of a successful attack on 138 application components and the data contained inside the TEE. 139 Typically, application components are chosen to execute inside a TEE 140 because those application components perform security sensitive 141 operations or operate on sensitive data. An application component 142 running inside a TEE is referred to as a Trusted Application (TA), 143 while an application running outside any TEE is referred to as an 144 Untrusted Application (UA). 146 TEEs use hardware enforcement combined with software protection to 147 secure TAs and its data. TEEs typically offer a more limited set of 148 services to TAs than is normally available to Untrusted Applications. 150 But not all TEEs are the same, and different vendors may have 151 different implementations of TEEs with different security properties, 152 different features, and different control mechanisms to operate on 153 TAs. Some vendors may themselves market multiple different TEEs with 154 different properties attuned to different markets. A device vendor 155 may integrate one or more TEEs into their devices depending on market 156 needs. 158 To simplify the life of developers and service providers interacting 159 with TAs in a TEE, an interoperable protocol for managing TAs running 160 in different TEEs of various devices is needed. In this TEE 161 ecosystem, there often arises a need for an external trusted party to 162 verify the identity, claims, and rights of Service Providers (SP), 163 devices, and their TEEs. This trusted third party is the Trusted 164 Application Manager (TAM). 166 The Trusted Execution Provisioning (TEEP) protocol addresses the 167 following problems: 169 - A Service Provider (SP) intending to provide services through a TA 170 to users of a device needs to determine security-relevant 171 information of a device before provisioning their TA to the TEE 172 within the device. An example is the verification of the type of 173 TEE included in a device and that it is capable of providing the 174 security protections required by a particular TA. 176 - A TEE in a device needs to determine whether a Service Provider 177 (SP) that wants to manage a TA in the device is authorized to 178 manage TAs in the TEE, and what TAs the SP is permitted to manage. 180 - A Service Provider (SP) must be able to determine if a TA exists 181 (is installed) on a device (in the TEE), and if not, install the 182 TA in the TEE. 184 - A Service Provider (SP) must be able to check whether a TA in a 185 device's TEE is the most up-to-date version, and if not, update 186 the TA in the TEE. 188 - A Service Provider (SP) must be able to remove a TA in a device's 189 TEE if the SP is no longer offering such services or the services 190 are being revoked from a particular user (or device). For 191 example, if a subscription or contract for a particular service 192 has expired, or a payment by the user has not been completed or 193 has been rescinded. 195 - A Service Provider (SP) must be able to define the relationship 196 between cooperating TAs under the SP's control, and specify 197 whether the TAs can communicate, share data, and/or share key 198 material. 200 Note: The Service Provider requires the help of a TAM to provision 201 the Trusted Applications to remote devices and the TEEP protocol 202 exchanges messages between a Trusted Application Manager (TAM) and a 203 TEEP Agent via a TEEP Broker. 205 2. Terminology 207 The following terms are used: 209 - Untrusted Application: An application running in a Rich Execution 210 Environment, such as an Android, Windows, or iOS application. 212 - Trusted Application Manager (TAM): An entity that manages Trusted 213 Applications (TAs) running in different TEEs of various devices. 215 - Device: A physical piece of hardware that hosts one or more TEEs, 216 often along with a Rich Execution Environment. A Device contains 217 a default list of Trust Anchors that identify entities (e.g., 218 TAMs) that are trusted by the Device. This list is normally set 219 by the Device Manufacturer, and may be governed by the Device's 220 network carrier. The list of Trust Anchors is normally modifiable 221 by the Device's owner or Device Administrator. However the Device 222 manufacturer and network carrier may restrict some modifications, 223 for example, by not allowing the manufacturer or carrier's Trust 224 Anchor to be removed or disabled. 226 - Rich Execution Environment (REE): An environment that is provided 227 and governed by a typical OS (e.g., Linux, Windows, Android, iOS), 228 potentially in conjunction with other supporting operating systems 229 and hypervisors; it is outside of any TEE. This environment and 230 applications running on it are considered untrusted. 232 - Service Provider (SP): An entity that wishes to provide a service 233 on Devices that requires the use of one or more Trusted 234 Applications. 236 - Device User: A human being that uses a device. Many devices have 237 a single device user. Some devices have a primary device user 238 with other human beings as secondary device users (e.g., parent 239 allowing children to use their tablet or laptop). Other devices 240 are not used by a human being and hence have no device user. 241 Relates to Device Owner and Device Administrator. 243 - Device Owner: A device is always owned by someone. In some cases, 244 it is common for the (primary) device user to also own the device, 245 making the device user/owner also the device administrator. In 246 enterprise environments it is more common for the enterprise to 247 own the device, and any device user has no or limited 248 administration rights. In this case, the enterprise appoints a 249 device administrator that is not the device owner. 251 - Device Administrator (DA): An entity that is responsible for 252 administration of a Device, which could be the device owner. A 253 Device Administrator has privileges on the Device to install and 254 remove applications and TAs, approve or reject Trust Anchors, and 255 approve or reject Service Providers, among possibly other 256 privileges on the Device. A Device Administrator can manage the 257 list of allowed TAMs by modifying the list of Trust Anchors on the 258 Device. Although a Device Administrator may have privileges and 259 Device-specific controls to locally administer a device, the 260 Device Administrator may choose to remotely administrate a device 261 through a TAM. 263 - Trust Anchor: As defined in [RFC6024] and 264 [I-D.ietf-suit-manifest], "A trust anchor represents an 265 authoritative entity via a public key and associated data. The 266 public key is used to verify digital signatures, and the 267 associated data is used to constrain the types of information for 268 which the trust anchor is authoritative." The Trust Anchor may be 269 a certificate or it may be a raw public key along with additional 270 data if necessary such as its public key algorithm and parameters. 272 - Trust Anchor Store: As defined in [RFC6024], "A trust anchor store 273 is a set of one or more trust anchors stored in a device. A 274 device may have more than one trust anchor store, each of which 275 may be used by one or more applications." As noted in 276 [I-D.ietf-suit-manifest], a trust anchor store must resist 277 modification against unauthorized insertion, deletion, and 278 modification. 280 - Trusted Application (TA): An application component that runs in a 281 TEE. 283 - Trusted Execution Environment (TEE): An execution environment that 284 enforces that only authorized code can execute within the TEE, and 285 data used by that code cannot be read or tampered with by code 286 outside the TEE. A TEE also generally has a device unique 287 credential that cannot be cloned. There are multiple technologies 288 that can be used to implement a TEE, and the level of security 289 achieved varies accordingly. In addition, TEEs typically use an 290 isolation mechanism between Trusted Applications to ensure that 291 one TA cannot read, modify or delete the data and code of another 292 TA. 294 3. Use Cases 296 3.1. Payment 298 A payment application in a mobile device requires high security and 299 trust about the hosting device. Payments initiated from a mobile 300 device can use a Trusted Application to provide strong identification 301 and proof of transaction. 303 For a mobile payment application, some biometric identification 304 information could also be stored in a TEE. The mobile payment 305 application can use such information for unlocking the phone and for 306 local identification of the user. 308 A trusted user interface (UI) may be used in a mobile device to 309 prevent malicious software from stealing sensitive user input data. 310 Such an implementation often relies on a TEE for providing access to 311 peripherals, such as PIN input. 313 3.2. Authentication 315 For better security of authentication, a device may store its keys 316 and cryptographic libraries inside a TEE limiting access to 317 cryptographic functions via a well-defined interface and thereby 318 reducing access to keying material. 320 3.3. Internet of Things 322 The Internet of Things (IoT) has been posing threats to critical 323 infrastructure because of weak security in devices. It is desirable 324 that IoT devices can prevent malware from manipulating actuators 325 (e.g., unlocking a door), or stealing or modifying sensitive data, 326 such as authentication credentials in the device. A TEE can be the 327 best way to implement such IoT security functions. 329 3.4. Confidential Cloud Computing 331 A tenant can store sensitive data in a TEE in a cloud computing 332 server such that only the tenant can access the data, preventing the 333 cloud hosting provider from accessing the data. A tenant can run TAs 334 inside a server TEE for secure operation and enhanced data security. 335 This provides benefits not only to tenants with better data security 336 but also to cloud hosting provider for reduced liability and 337 increased cloud adoption. 339 4. Architecture 341 4.1. System Components 343 The following are the main components in the system. Full 344 descriptions of components not previously defined are provided below. 345 Interactions of all components are further explained in the following 346 paragraphs. 348 +-------------------------------------------+ 349 | Device | 350 | +--------+ | Service Provider 351 | +-------------+ | |----------+ | 352 | | TEE-1 | | TEEP |---------+| | 353 | | +--------+ | +----| Broker | | || +--------+ | 354 | | | TEEP | | | | |<---+ | |+-->| |<-+ 355 | | | Agent |<----+ | | | | | +-| TAM-1 | 356 | | +--------+ | | |<-+ | | +->| | |<-+ 357 | | | +--------+ | | | | +--------+ | 358 | | +---+ +---+ | | | | | TAM-2 | | 359 | +-->|TA1| |TA2| | +-------+ | | | +--------+ | 360 | | | | | | |<---------| App-2 |--+ | | | 361 | | | +---+ +---+ | +-------+ | | | Device Administrator 362 | | +-------------+ | App-1 | | | | 363 | | | | | | | 364 | +--------------------| |---+ | | 365 | | |--------+ | 366 | +-------+ | 367 +-------------------------------------------+ 369 Figure 1: Notional Architecture of TEEP 371 - Service Providers (SP) and Device Administrators (DA) utilize the 372 services of a TAM to manage TAs on Devices. SPs do not directly 373 interact with devices. DAs may elect to use a TAM for remote 374 administration of TAs instead of managing each device directly. 376 - Trusted Application Manager (TAM): A TAM is responsible for 377 performing lifecycle management activity on TA's on behalf of 378 Service Providers and Device Administrators. This includes 379 creation and deletion of TA's, and may include, for example, over- 380 the-air updates to keep an SP's TAs up-to-date and clean up when a 381 version should be removed. TAMs may provide services that make it 382 easier for SPs or DAs to use the TAM's service to manage multiple 383 devices, although that is not required of a TAM. 385 The TAM performs its management of TA's through an interaction 386 with a Device's TEEP Broker. As shown in Figure 1, the TAM cannot 387 directly contact a TEEP Agent, but must wait for the TEEP Broker 388 to contact the TAM requesting a particular service. This 389 architecture is intentional in order to accommodate network and 390 application firewalls that normally protect user and enterprise 391 devices from arbitrary connections from external network entities. 393 A TAM may be publicly available for use by many SPs, or a TAM may 394 be private, and accessible by only one or a limited number of SPs. 395 It is expected that manufacturers and carriers will run their own 396 private TAM. Another example of a private TAM is a TAM running as 397 a Software-as-a-Service (SaaS) within an SP. 399 A SP or Device Administrator chooses a particular TAM based on 400 whether the TAM is trusted by a Device or set of Devices. The TAM 401 is trusted by a device if the TAM's public key is an authorized 402 Trust Anchor in the Device. A SP or Device Administrator may run 403 their own TAM, however the Devices they wish to manage must 404 include this TAM's pubic key in the Trust Anchor list. 406 A SP or Device Administrator is free to utilize multiple TAMs. 407 This may be required for a SP to manage multiple different types 408 of devices from different manufacturers, or devices on different 409 carriers, since the Trust Anchor list on these different devices 410 may contain different TAMs. A Device Administrator may be able to 411 add their own TAM's public key or certificate to the Trust Anchor 412 list on all their devices, overcoming this limitation. 414 Any entity is free to operate a TAM. For a TAM to be successful, 415 it must have its public key or certificate installed in Devices 416 Trust Anchor list. A TAM may set up a relationship with device 417 manufacturers or carriers to have them install the TAM's keys in 418 their device's Trust Anchor list. Alternatively, a TAM may 419 publish its certificate and allow Device Administrators to install 420 the TAM's certificate in their devices as an after-market-action. 422 - TEEP Broker: The TEEP Broker is an application component running 423 in a Rich Execution Environment (REE) that enables the message 424 protocol exchange between a TAM and a TEE in a device. The TEEP 425 Broker does not process messages on behalf of a TEE, but merely is 426 responsible for relaying messages from the TAM to the TEE, and for 427 returning the TEE's responses to the TAM. 429 - TEEP Agent: the TEEP Agent is a processing module running inside a 430 TEE that receives TAM requests that are relayed via a TEEP Broker 431 that runs in an REE. A TEEP Agent in the TEE may parse requests 432 or forward requests to other processing modules in a TEE, which is 433 up to a TEE provider's implementation. A response message 434 corresponding to a TAM request is sent by a TEEP Agent back to a 435 TEEP Broker. 437 - Certification Authority (CA): Certificate-based credentials used 438 for authenticating a device, a TAM and an SP. A device embeds a 439 list of root certificates (Trust Anchors), from trusted CAs that a 440 TAM will be validated against. A TAM will remotely attest a 441 device by checking whether a device comes with a certificate from 442 a CA that the TAM trusts. The CAs do not need to be the same; 443 different CAs can be chosen by each TAM, and different device CAs 444 can be used by different device manufacturers. 446 4.2. Different Renditions of TEEP Architecture 448 There is nothing prohibiting a device from implementing multiple 449 TEEs. In addition, some TEEs (for example, SGX) present themselves 450 as separate containers within memory without a controlling manager 451 within the TEE. In these cases, the Rich Execution Environment hosts 452 multiple TEEP brokers, where each Broker manages a particular TEE or 453 set of TEEs. Enumeration and access to the appropriate TEEP Broker 454 is up to the Rich Execution Environment and the Untrusted 455 Applications. Verification that the correct TA has been reached then 456 becomes a matter of properly verifying TA attestations, which are 457 unforgeable. The multiple TEEP Broker approach is shown in the 458 diagram below. For brevity, TEEP Broker 2 is shown interacting with 459 only one TAM and UA, but no such limitation is intended to be implied 460 in the architecture. 462 +-------------------------------------------+ 463 | Device | 464 | +--------+ | Service Provider 465 | | |----------+ | 466 | +-------------+ | TEEP |---------+| | 467 | | TEE-1 | +---| Broker | | || +--------+ | 468 | | | | | 1 |<---+ | |+-->| |<-+ 469 | | +-------+ | | | | | | | | | 470 | | | TEEP | | | | | | | | | | 471 | | | Agent |<------+ | | | | | | | 472 | | | 1 | | | | | | | | | 473 | | +-------+ | | | | | | | | 474 | | | | | | | | | | 475 | | +---+ +---+ | | | | | | +-| TAM-1 | 476 | | |TA1| |TA2| | | |<-+ | | +->| | |<-+ 477 | +-->| | | |<---+ +--------+ | | | | +--------+ | 478 | | | +---+ +---+ | | | | | | TAM-2 | | 479 | | | | | +-------+ | | | +--------+ | 480 | | +-------------+ +-----| App-2 |--+ | | ^ | 481 | | +-------+ | | | | Device 482 | +--------------------| App-1 | | | | | Administrator 483 | +------| | | | | | 484 | +-----------|-+ | |---+ | | | 485 | | TEE-2 | | | |--------+ | | 486 | | +------+ | | | |------+ | | 487 | | | TEEP | | | +-------+ | | | 488 | | | Agent|<-----+ | | | 489 | | | 2 | | | | | | | 490 | | +------+ | | | | | | 491 | | | | | | | | 492 | | +---+ | | | | | | 493 | | |TA3|<----+ | | +----------+ | | | 494 | | | | | | | TEEP |<--+ | | 495 | | +---+ | +--| Broker |----------------+ 496 | | | | 2 | | 497 | +-------------+ +----------+ | 498 | | 499 +-------------------------------------------+ 501 Figure 2: Notional Architecture of TEEP with multiple TEEs 503 In the diagram above, TEEP Broker 1 controls interactions with the 504 TA's in TEE-1, and TEEP Broker 2 controls interactions with the TA's 505 in TEE-2. This presents some challenges for a TAM in completely 506 managing the device, since a TAM may not interact with all the TEEP 507 Brokers on a particular platform. In addition, since TEE's may be 508 physically separated, with wholly different resources, there may be 509 no need for TEEP Brokers to share information on installed TAs or 510 resource usage. However, the architecture guarantees that the TAM 511 will receive all the relevant information from the TEEP Broker to 512 which it communicates. 514 4.3. Multiple TAMs and Relationship to TAs 516 As shown in Figure 2, the TEEP Broker provides connections from the 517 TEE and the Untrusted Application to one or more TAMs. The selection 518 of which TAM to communicate with is dependent on information from the 519 Untrusted Application and is directly related to the TA. 521 When a SP offers a service which requires a TA, the SP associates 522 that service with a specific TA. The TA itself is digitally signed, 523 protecting its integrity, but the signature also links the TA back to 524 the signer. The signer is usually the SP, but in some cases may be 525 another party that the SP trusts. The SP selects one or more TAMs 526 through which to offer their service, and communicates the 527 information of the service and the specific Untrusted Applications 528 and TAs to the TAM. 530 The SP chooses TAMs based upon the markets into which the TAM can 531 provide access. There may be TAMs that provide services to specific 532 types of mobile devices, or mobile device operating systems, or 533 specific geographical regions or network carriers. A SP may be 534 motivated to utilize multiple TAMs for its service in order to 535 maximize market penetration and availability on multiple types of 536 devices. This likely means that the same service will be available 537 through multiple TAMs. 539 When the SP publishes the Untrusted Application to an app store or 540 other app repositories, the SP binds the Untrusted Application with a 541 manifest that identifies what TAMs can be contacted for the TA. In 542 some situations, an SP may use only a single TAM - this is likely the 543 case for enterprise applications or SPs serving a closed community. 544 For broad public apps, there will likely be multiple TAMs in the 545 manifest - one servicing one brand of mobile device and another 546 servicing a different manufacturer, etc. Because different devices 547 and different manufacturers trust different TAMs, the manifest will 548 include different TAMs that support this SP's Untrusted Application 549 and TA. Multiple TAMs allow the SP to provide their service and this 550 app (and TA) to multiple different devices. 552 When a TEEP Broker receives a request from an Untrusted Application 553 to install a TA, a list of TAM URIs may be provided for that TA, and 554 the request is passed to the TEEP Agent. If the TEEP Agent decides 555 that the TA needs to be installed, the TEEP Agent selects a single 556 TAM URI that is consistent with the list of trusted TAMs provisioned 557 on the device invokes the HTTP transport for TEEP to connect to the 558 TAM URI and begins a TEEP protocol exchange. When the TEEP Agent 559 subsequently receives the TA to install and the TA's manifest 560 indicates dependencies on any other trusted components, each 561 dependency can include a list of TAM URIs for the relevant 562 dependency. If such dependencies exist that are prerequisites to 563 install the TA, then the TEEP Agent recursively follows the same 564 procedure for each dependency that needs to be installed or updated, 565 including selecting a TAM URI that is consistent with the list of 566 trusted TAMs provisioned on the device, and beginning a TEEP 567 exchange. If multiple TAM URIs are considered trusted, only one 568 needs to be contacted and they can be attempted in some order until 569 one responds. 571 Separate from the Untrusted Application's manifest, this framework 572 relies on the use of the manifest format in [I-D.ietf-suit-manifest] 573 for expressing how to install the TA as well as dependencies on other 574 TEE components and versions. That is, dependencies from TAs on other 575 TEE components can be expressed in a SUIT manifest, including 576 dependencies on any other TAs, or trusted OS code (if any), or 577 trusted firmware. Installation steps can also be expressed in a SUIT 578 manifest. 580 For example, TEE's compliant with Global Platform may have a notion 581 of a "security domain" (which is a grouping of one or more TAs 582 installed on a device, that can share information within such a 583 group) that must be created and into which one or more TAs can then 584 be installed. It is thus up to the SUIT manifest to express a 585 dependency on having such a security domain existing or being created 586 first, as appropriate. 588 Updating a TA may cause compatibility issues with any Untrusted 589 Applications or other components that depend on the updated TA, just 590 like updating the OS or a shared library could impact an Untrusted 591 Application. Thus, an implementation needs to take into account such 592 issues. 594 4.4. Untrusted Apps, Trusted Apps, and Personalization Data 596 In TEEP, there is an explicit relationship and dependence between the 597 Untrusted Application in the REE and one or more TAs in the TEE, as 598 shown in Figure 2. For most purposes, an Untrusted Application that 599 uses one or more TA's in a TEE appears no different from any other 600 Untrusted Application in the REE. However, the way the Untrusted 601 Application and its corresponding TA's are packaged, delivered, and 602 installed on the device can vary. The variations depend on whether 603 the Untrusted Application and TA are bundled together or are provided 604 separately, and this has implications to the management of the TAs in 605 the TEE. In addition to the Untrusted Application and TA, the TA 606 and/or TEE may require some additional data to personalize the TA to 607 the service provider or the device or a user. This personalization 608 data is dependent on the TEE, the TA and the SP; an example of 609 personalization data might be a secret symmetric key used by the TA 610 to communicate with the SP. The personalization data must be 611 encrypted to preserve the confidentiality of potentially sensitive 612 data contained within it. Other than this requirement to support 613 confidentiality, TEEP place no limitations or requirements on the 614 personalization data. 616 There are three possible cases for bundling of the Untrusted 617 Application, TA, and personalization data: 619 1. The Untrusted Application, TA, and personalization data are all 620 bundled together in a single package by the SP and provided to 621 the TEEP Broker through the TAM. 623 2. The Untrusted Application and the TA are bundled together in a 624 single package, which a TAM or a publicly accessible app store 625 maintains, and the personalization data is separately provided by 626 the SP's TAM. 628 3. All components are independent. The Untrusted Application is 629 installed through some independent or device-specific mechanism, 630 and the TAM provides the TA and personalization data from the SP. 631 Delivery of the TA and personalization data may be combined or 632 separate. 634 The TEEP protocol treats the TA, any dependencies the TA has, and 635 personalization data as separate components with separate 636 installation steps that are expressed in SUIT manifests, and a SUIT 637 manifest might contain or reference multiple binaries (see {{I- 638 D.ietf-suit-manifest} for more details). The TEEP Agent is 639 responsible for handling any installation steps that need to be 640 performed inside the TEE, such as decryption of private TA bianries 641 or personalization data. 643 4.5. Examples of Application Delivery Mechanisms in Existing TEEs 645 In order to better understand these cases, it is helpful to review 646 actual implementations of TEEs and their application delivery 647 mechanisms. 649 In Intel Software Guard Extensions (SGX), the Untrusted Application 650 and TA are typically bundled into the same package (Case 2). The TA 651 exists in the package as a shared library (.so or .dll). The 652 Untrusted Application loads the TA into an SGX enclave when the 653 Untrusted Application needs the TA. This organization makes it easy 654 to maintain compatibility between the Untrusted Application and the 655 TA, since they are updated together. It is entirely possible to 656 create an Untrusted Application that loads an external TA into an SGX 657 enclave and use that TA (Case 3). In this case, the Untrusted 658 Application would require a reference to an external file or download 659 such a file dynamically, place the contents of the file into memory, 660 and load that as a TA. Obviously, such file or downloaded content 661 must be properly formatted and signed for it to be accepted by the 662 SGX TEE. In SGX, for Case 2 and Case 3, the personalization data is 663 normally loaded into the SGX enclave (the TA) after the TA has 664 started. Although Case 1 is possible with SGX, there are no 665 instances of this known to be in use at this time, since such a 666 construction would require a special installation program and SGX TA 667 to receive the encrypted binary, decrypt it, separate it into the 668 three different elements, and then install all three. This 669 installation is complex, because the Untrusted Application decrypted 670 inside the TEE must be passed out of the TEE to an installer in the 671 REE which would install the Untrusted Application; this assumes that 672 the Untrusted Application package includes the TA code also, since 673 otherwise there is a significant problem in getting the SGX enclave 674 code (the TA) from the TEE, through the installer and into the 675 Untrusted Application in a trusted fashion. Finally, the 676 personalization data would need to be sent out of the TEE (encrypted 677 in an SGX encalve-to-enclave manner) to the REE's installation app, 678 which would pass this data to the installed Untrusted Application, 679 which would in turn send this data to the SGX enclave (TA). This 680 complexity is due to the fact that each SGX enclave is separate and 681 does not have direct communication to other SGX enclaves. 683 In Arm TrustZone for A- and R-class devices, the Untrusted 684 Application and TA may or may not be bundled together. This differs 685 from SGX since in TrustZone the TA lifetime is not inherently tied to 686 a specific Untrused Application process lifetime as occurs in SGX. A 687 TA is loaded by a trusted OS running in the TEE, where the trusted OS 688 is separate from the OS in the REE. Thus Cases 2 and 3 are equally 689 applicable. In addition, it is possible for TAs to communicate with 690 each other without involving the Untrusted Application, and so the 691 complexity of Case 1 is lower than in the SGX example, and so Case 1 692 is possible as well though still more complex than Cases 2 and 3. 694 4.6. Entity Relations 696 This architecture leverages asymmetric cryptography to authenticate a 697 device to a TAM. Additionally, a TEE in a device authenticates a TAM 698 and TA signer. The provisioning of Trust Anchors to a device may be 699 different from one use case to the other. A device administrator may 700 want to have the capability to control what TAs are allowed. A 701 device manufacturer enables verification of the TA signers and TAM 702 providers; it may embed a list of default Trust Anchors that the 703 signer of an allowed TA's signer certificate should chain to. A 704 device administrator may choose to accept a subset of the allowed TAs 705 via consent or action of downloading. 707 (App Developer) (App Store) (TAM) (Device with TEE) (CAs) 708 | | 709 | --> (Embedded TEE cert) <-- 710 | | 711 | <------------------------------ Get an app cert ----- | 712 | | <-- Get a TAM cert ------ | 713 | 714 1. Build two apps: 715 Untrusted Application 716 TA 717 | 718 | 719 Untrusted Application -- 2a. --> | ----- 3. Install -------> | 720 TA ----------------- 2b. Supply ------> | 4. Messaging-->| 721 | | | | 723 Figure 3: Developer Experience 725 Note that Figure 3 shows the app developer as a TA signer and not the 726 SP. However, the App Developer is either closely associated with the 727 SP or the SP delegates the signing authority to the app developer. 728 For the purpose of this document there is no difference between the 729 SP and the app developer. 731 Figure 3 shows an application developer building two applications: 1) 732 an Untrusted Application; 2) a TA that provides some security 733 functions to be run inside a TEE. At step 2, the application 734 developer uploads the Untrusted Application (2a) to an Application 735 Store. The Untrusted Application may optionally bundle the TA 736 binary. Meanwhile, the application developer may provide its TA to a 737 TAM provider that will be managing the TA in various devices. 3. A 738 user will go to an Application Store to download the Untrusted 739 Application. The Untrusted Application will trigger TA installation 740 by initiating communication with a TAM. This is the step 4. The 741 Untrusted Application will get messages from TAM, and interacts with 742 device TEE via an Agent. 744 The main components consist of a set of standard messages created by 745 a TAM to deliver TA management commands to a device, and device 746 attestation and response messages created by a TEE that responds to a 747 TAM's message. 749 It should be noted that network communication capability is generally 750 not available in TAs in today's TEE-powered devices. Trusted 751 Applications need to rely on a broker in the REE to interact with a 752 TEE for network message exchanges. Consequently, a TAM generally 753 communicates with an Untrusted Application about how it gets messages 754 that originate from a TEE inside a device. Similarly, a TA or TEE 755 generally gets messages from a TAM via a TEEP Broker in this protocol 756 architecture, not directly from the network. 758 It is imperative to have an interoperable protocol to communicate 759 with different TAMs and different TEEs in different devices. This is 760 the role of the Broker, which is a software component that bridges 761 communication between a TAM and a TEE. Furthermore the Broker 762 communicates with a Agent inside a TEE that is responsible to process 763 TAM requests. The Broker in REE does not need to know the actual 764 content of messages except for the TEE routing information. 766 5. Keys and Certificate Types 768 This architecture leverages the following credentials, which allow 769 delivering end-to-end security between a TAM and a TEEP Agent. 771 Figure 4 summarizes the relationships between various keys and where 772 they are stored. Each public/private key identifies an SP, TAM, or 773 TEE, and gets a certificate that chains up to some CA. A list of 774 trusted certificates is then used to check a presented certificate 775 against. 777 Different CAs can be used for different types of certificates. TEEP 778 messages are always signed, where the signer key is the message 779 originator's private key such as that of a TAM, or a TEE's private 780 key. In addition to the keys shown in Figure 4, there may be 781 additional keys used for attestation. Refer to the RATS Architecture 782 for more discussion. 784 Cardinality & Location of 785 Location of Private Key Corresponding 786 Purpose Private Key Signs CA Certs 787 ------------------ ----------- ------------- ------------- 788 Authenticating TEE 1 per TEE TEEP responses TAM 790 Authenticating TAM 1 per TAM TEEP requests TEEP Agent 792 Code Signing 1 per SP TA binary TEE 794 Figure 4: Keys 796 Note that personalization data is not included in the table above. 797 The use of personalization data is dependent on how TAs are used and 798 what their security requirements are. 800 The TEE key pair and certificate are used for authenticating the TEE 801 to a remote TAM. Often, the key pair is burned into the TEE by the 802 TEE manufacturer and the key pair and its certificate are valid for 803 the expected lifetime of the TEE. A TAM provider is responsible for 804 configuring its TAM with the manufacturer certificates or CAs that 805 are used to sign TEE keys. 807 The TAM key pair and certificate are used for authenticating a TAM to 808 a remote TEE. A TAM provider is responsible for acquiring a 809 certificate from a CA that is trusted by the TEEs it manages. 811 The SP key pair and certificate are used to sign TAs that the TEE 812 will consider authorized to execute. TEEs must be configured with 813 the CAs that it considers authorized to sign TAs that it will 814 execute. 816 5.1. Trust Anchors in TEE 818 A TEEP Agent's Trust Anchor store contains a list of Trust Anchors, 819 which are CA certificates that sign various TAM certificates. The 820 list is typically preloaded at manufacturing time, and can be updated 821 using the TEEP protocol if the TEE has some form of "Trust Anchor 822 Manager TA" that has Trust Anchors in its configuration data. Thus, 823 Trust Anchors can be updated similar to updating the configuration 824 data for any other TA. 826 When Trust Anchor update is carried out, it is imperative that any 827 update must maintain integrity where only authentic Trust Anchor list 828 from a device manufacturer or a Device Administrator is accepted. 829 This calls for a complete lifecycle flow in authorizing who can make 830 Trust Anchor update and whether a given Trust Anchor list are non- 831 tampered from the original provider. The signing of a Trust Anchor 832 list for integrity check and update authorization methods are 833 desirable to be developed. This can be addressed outside of this 834 architecture document. 836 Before a TAM can begin operation in the marketplace to support a 837 device with a particular TEE, it must obtain a TAM certificate from a 838 CA that is listed in the Trust Anchor store of the TEE. 840 5.2. Trust Anchors in TAM 842 The Trust Anchor store in a TAM consists of a list of Trust Anchors, 843 which are CA certificates that sign various device TEE certificates. 844 A TAM will accept a device for TA management if the TEE in the device 845 uses a TEE certificate that is chained to a CA that the TAM trusts. 847 5.3. Scalability 849 This architecture uses a PKI. Trust Anchors exist on the devices to 850 enable the TEE to authenticate TAMs, and TAMs use Trust Anchors to 851 authenticate TEEs. Since a PKI is used, many intermediate CA 852 certificates can chain to a root certificate, each of which can issue 853 many certificates. This makes the protocol highly scalable. New 854 factories that produce TEEs can join the ecosystem. In this case, 855 such a factory can get an intermediate CA certificate from one of the 856 existing roots without requiring that TAMs are updated with 857 information about the new device factory. Likewise, new TAMs can 858 join the ecosystem, providing they are issued a TAM certificate that 859 chains to an existing root whereby existing TEEs will be allowed to 860 be personalized by the TAM without requiring changes to the TEE 861 itself. This enables the ecosystem to scale, and avoids the need for 862 centralized databases of all TEEs produced or all TAMs that exist. 864 5.4. Message Security 866 Messages created by a TAM are used to deliver TA management commands 867 to a device, and device attestation and messages created by the 868 device TEE to respond to TAM messages. 870 These messages are signed end-to-end between a TEEP Agent and a TAM, 871 and are typically encrypted such that only the targeted device TEE or 872 TAM is able to decrypt and view the actual content. 874 6. TEEP Broker 876 A TEE and TAs often do not have the capability to directly 877 communicate outside of the hosting device. For example, 878 GlobalPlatform [GPTEE] specifies one such architecture. This calls 879 for a software module in the REE world to handle network 880 communication with a TAM. 882 A TEEP Broker is an application component running in the REE of the 883 device or an SDK that facilitates communication between a TAM and a 884 TEE. It also provides interfaces for Untrusted Applications to query 885 and trigger TA installation that the application needs to use. 887 An Untrusted Application might communicate with the TEEP Broker at 888 runtime to trigger TA installation itself. Or an Untrusted 889 Application might simply have a metadata file that describes the TAs 890 it depends on and the associated TAM(s) for each TA, and an REE 891 Application Installer can inspect this application metadata file and 892 invoke the TEEP Broker to trigger TA installation on behalf of the 893 Untrusted Application without requiring the Untrusted Application to 894 run first. 896 6.1. Role of the TEEP Broker 898 A TEEP Broker abstracts the message exchanges with a TEE in a device. 899 The input data is originated from a TAM or the first initialization 900 call to trigger a TA installation. 902 The Broker doesn't need to parse a message content received from a 903 TAM that should be processed by a TEE. When a device has more than 904 one TEE, one TEEP Broker per TEE could be present in REE. A TEEP 905 Broker interacts with a TEEP Agent inside a TEE. 907 A TAM message may indicate the target TEE where a TA should be 908 installed. A compliant TEEP protocol should include a target TEE 909 identifier for a TEEP Broker when multiple TEEs are present. 911 The Broker relays the response messages generated from a TEEP Agent 912 in a TEE to the TAM. The Broker is not expected to handle any 913 network connection with an application or TAM. 915 The Broker only needs to return an error message if the TEE is not 916 reachable for some reason. Other errors are represented as response 917 messages returned from the TEE which will then be passed to the TAM. 919 6.2. TEEP Broker Implementation Consideration 921 A Provider should consider methods of distribution, scope and 922 concurrency on devices and runtime options when implementing a TEEP 923 Broker. Several non-exhaustive options are discussed below. 924 Providers are encouraged to take advantage of the latest 925 communication and platform capabilities to offer the best user 926 experience. 928 6.2.1. TEEP Broker APIs 930 The following conceptual APIs exist from a TEEP Broker to a TEEP 931 Agent: 933 1. RequestTA: A notification from an REE application (e.g., an 934 installer, or a normal application) that it depends on a given 935 TA, which may or may not already be installed in the TEE. 937 2. ProcessTeepMessage: A message arriving from the network, to be 938 delivered to the TEEP Agent for processing. 940 3. RequestPolicyCheck: A hint (e.g., based on a timer) that the TEEP 941 Agent may wish to contact the TAM for any changes, without the 942 device itself needing any particular change. 944 4. ProcessError: A notification that the TEEP Broker could not 945 deliver an outbound TEEP message to a TAM. 947 For comparison, similar APIs may exist on the TAM side, where a 948 Broker may or may not exist (depending on whether the TAM uses a TEE 949 or not): 951 1. ProcessConnect: A notification that an incoming TEEP session is 952 being requested by a TEEP Agent. 954 2. ProcessTeepMessage: A message arriving from the network, to be 955 delivered to the TAM for processing. 957 For further discussion on these APIs, see 958 [I-D.ietf-teep-otrp-over-http]. 960 6.2.2. TEEP Broker Distribution 962 The Broker installation is commonly carried out at OEM time. A user 963 can dynamically download and install a Broker on-demand. 965 6.2.3. Number of TEEP Brokers 967 There should be generally only one shared TEEP Broker in a device. 968 The device's TEE vendor will most probably supply one Broker. When 969 multiple TEEs are present in a device, one TEEP Broker per TEE may be 970 used. 972 When only one Broker is used per device, the Broker provider is 973 responsible to allow multiple TAMs and TEE providers to achieve 974 interoperability. With a standard Broker interface, each TAM can 975 implement its own SDK for its SP Untrusted Applications to work with 976 this Broker. 978 Multiple independent Broker providers can be used as long as they 979 have standard interface to an Untrusted Application or TAM SDK. Only 980 one Broker is generally expected in a device. 982 7. Attestation 984 Attestation is the process through which one entity (an Attester) 985 presents "evidence", in the form of a series of claims, to another 986 entity (a Verifier), and provides sufficient proof that the claims 987 are true. Different verifiers may have different standards for 988 attestation proofs and not all attestations are acceptable to every 989 verifier. A third entity (a Relying Party) can then use "attestation 990 results", in the form of another series of claims, from a Verifier to 991 make authorization decisions. 993 In TEEP, as depicted in Figure 5, the primary purpose of an 994 attestation is to allow a device (the Attester) to prove to TAMs (the 995 Relying Parties) that a TEE in the device has particular properties, 996 was built by a particular manufacturer, or is executing a particular 997 TA. Other claims are possible; TEEP does not limit the claims that 998 may appear in evidence or attestation results, but defines a minimal 999 set of attestation result claims required for TEEP to operate 1000 properly. Extensions to these claims are possible. Other standards 1001 or groups may define the format and semantics of extended claims. 1003 +----------------+ 1004 | Device | +----------+ 1005 | +------------+ | Evidence | TAM | Evidence +----------+ 1006 | | TEE |------------->| (Relying |-------------->| Verifier | 1007 | | (Attester) | | | Party) |<--------------| | 1008 | +------------+ | +----------+ Attestation +----------+ 1009 +----------------+ Result 1011 Figure 5: TEEP Attestation Roles 1013 As of the writing of this specification, device and TEE attestations 1014 have not been standardized across the market. Different devices, 1015 manufacturers, and TEEs support different attestation algorithms and 1016 mechanisms. In order for TEEP to be inclusive, it is agnostic to the 1017 format of evidence, allowing proprietary or standardized formats to 1018 be used between a TEE and a verifier (which may or may not be 1019 colocated in the TAM). However, it should be recognized that not all 1020 verifiers may be able to process all proprietary forms of attestation 1021 evidence. Similarly, the TEEP protocol is agnostic as to the format 1022 of attestation results, and the protocol (if any) used between the 1023 TAM and a verifier, as long as they convey at least the required set 1024 of claims in some format. 1026 The assumptions which may apply to an attestation have to do with the 1027 quality of the attestation and the quality and security provided by 1028 the TEE, the device, the manufacturer, or others involved in the 1029 device or TEE ecosystem. Some of the assumptions that might apply to 1030 an attestations include (this may not be a comprehensive list): 1032 - Assumptions regarding the security measures a manufacturer takes 1033 when provisioning keys into devices/TEEs; 1035 - Assumptions regarding what hardware and software components have 1036 access to the Attestation keys of the TEE; 1038 - Assumptions related to the source or local verification of claims 1039 within an attestation prior to a TEE signing a set of claims; 1041 - Assumptions regarding the level of protection afforded to 1042 attestation keys against exfiltration, modification, and side 1043 channel attacks; 1045 - Assumptions regarding the limitations of use applied to TEE 1046 Attestation keys; 1048 - Assumptions regarding the processes in place to discover or detect 1049 TEE breeches; and 1051 - Assumptions regarding the revocation and recovery process of TEE 1052 attestation keys. 1054 TAMs must be comfortable with the assumptions that are inherently 1055 part of any attestation result they accept. Alternatively, any TAM 1056 may choose not to accept an attestation result generated using 1057 evidence from a particular manufacturer or device's TEE based on the 1058 inherent assumptions. The choice and policy decisions are left up to 1059 the particular TAM. 1061 Some TAMs may require additional claims in order to properly 1062 authorize a device or TEE. These additional claims may help clear up 1063 any assumptions for which the TAM wants to alleviate. The specific 1064 format for these additional claims are outside the scope of this 1065 specification, but the TEEP protocol allows these additional claims 1066 to be included in the attestation messages. 1068 7.1. Information Required in TEEP Claims 1070 - Device Identifying Info: TEEP attestations may need to uniquely 1071 identify a device to the TAM and SP. Unique device identification 1072 allows the TAM to provide services to the device, such as managing 1073 installed TAs, and providing subscriptions to services, and 1074 locating device-specific keying material to communicate with or 1075 authenticate the device. In some use cases it may be sufficient 1076 to identify only the class of the device. The security and 1077 privacy requirements regarding device identification will vary 1078 with the type of TA provisioned to the TEE. 1080 - TEE Identifying info: The type of TEE that generated this 1081 attestation must be identified. Standard TEE types are identified 1082 by an IANA number, but also must include version identification 1083 information such as the hardware, firmware, and software version 1084 of the TEE, as applicable by the TEE type. TEE manufacturer 1085 information for the TEE is required in order to disambiguate the 1086 same TEE type created by different manufacturers and resolve 1087 potential assumptions around manufacturer provisioning, keying and 1088 support for the TEE. 1090 - Liveness Proof: A claim that includes liveness information must be 1091 included, such as a nonce or timestamp. 1093 - Requested Components: A list of zero or more components (TAs or 1094 other dependencies needed by a TEE) that are requested by some 1095 depending app, but which are not currently installed in the TEE. 1097 8. Algorithm and Attestation Agility 1099 RFC 7696 [RFC7696] outlines the requirements to migrate from one 1100 mandatory-to-implement algorithm suite to another over time. This 1101 feature is also known as crypto agility. Protocol evolution is 1102 greatly simplified when crypto agility is already considered during 1103 the design of the protocol. In the case of the Trusted Execution 1104 Provisioning (TEEP) Protocol the diverse range of use cases, from 1105 trusted app updates for smart phones and tablets to updates of code 1106 on higher-end IoT devices, creates the need for different mandatory- 1107 to-implement algorithms already from the start. 1109 Crypto agility in TEEP concerns the use of symmetric as well as 1110 asymmetric algorithms. Symmetric algorithms are used for encryption 1111 of content whereas the asymmetric algorithms are mostly used for 1112 signing messages. 1114 In addition to the use of cryptographic algorithms in TEEP there is 1115 also the need to make use of different attestation technologies. A 1116 Device must provide techniques to inform a TAM about the attestation 1117 technology it supports. For many deployment cases it is more likely 1118 for the TAM to support one or more attestation techniques whereas the 1119 Device may only support one. 1121 9. Security Considerations 1123 9.1. TA Trust Check at TEE 1125 A TA binary is signed by a TA signer certificate. This TA signing 1126 certificate/private key belongs to the SP, and may be self-signed 1127 (i.e., it need not participate in a trust hierarchy). It is the 1128 responsibility of the TAM to only allow verified TAs from trusted SPs 1129 into the system. Delivery of that TA to the TEE is then the 1130 responsibility of the TEE, using the security mechanisms provided by 1131 the protocol. 1133 We allow a way for an Untrusted Application to check the 1134 trustworthiness of a TA. A TEEP Broker has a function to allow an 1135 application to query the information about a TA. 1137 An Untrusted Application may perform verification of the TA by 1138 verifying the signature of the TA. An application can do additional 1139 trust checks on the certificate returned for this TA. It might trust 1140 the TAM, or require additional SP signer trust chaining. 1142 9.2. One TA Multiple SP Case 1144 A TA for multiple SPs must have a different identifier per SP. They 1145 should appear as different TAs when they are installed in the same 1146 device. 1148 9.3. Broker Trust Model 1150 A TEEP Broker could be malware in the vulnerable REE. An Untrusted 1151 Application will connect its TAM provider for required TA 1152 installation. It gets command messages from the TAM, and passes the 1153 message to the Broker. 1155 The architecture enables the TAM to communicate with the device's TEE 1156 to manage TAs. All TAM messages are signed and sensitive data is 1157 encrypted such that the TEEP Broker cannot modify or capture 1158 sensitive data. 1160 9.4. Data Protection at TAM and TEE 1162 The TEE implementation provides protection of data on the device. It 1163 is the responsibility of the TAM to protect data on its servers. 1165 9.5. Compromised CA 1167 A root CA for TAM certificates might get compromised. Some TEE Trust 1168 Anchor update mechanism is expected from device OEMs. TEEs are 1169 responsible for validating certificate revocation about a TAM 1170 certificate chain. 1172 If the root CA of some TEE device certificates is compromised, these 1173 devices might be rejected by a TAM, which is a decision of the TAM 1174 implementation and policy choice. TAMs are responsible for 1175 validating any intermediate CA for TEE device certificates. 1177 9.6. Compromised TAM 1179 Device TEEs are responsible for validating the supplied TAM 1180 certificates to determine that the TAM is trustworthy. 1182 9.7. Certificate Renewal 1184 TEE device certificates are expected to be long lived, longer than 1185 the lifetime of a device. A TAM certificate usually has a moderate 1186 lifetime of 2 to 5 years. A TAM should get renewed or rekeyed 1187 certificates. The root CA certificates for a TAM, which are embedded 1188 into the Trust Anchor store in a device, should have long lifetimes 1189 that don't require device Trust Anchor update. On the other hand, it 1190 is imperative that OEMs or device providers plan for support of Trust 1191 Anchor update in their shipped devices. 1193 9.8. Keeping Secrets from the TAM 1195 In some scenarios, it is desirable to protect the TA binary or 1196 configuration from being disclosed to the TAM that distributes them. 1197 In such a scenario, the files can be encrypted end-to-end between an 1198 SP and a TEE. However, there must be some means of provisioning the 1199 decryption key into the TEE and/or some means of the SP securely 1200 learning a public key of the TEE that it can use to encrypt. One way 1201 to do this is for the SP to run its own TAM, merely to distribute the 1202 decryption key via the TEEP protocol, and the key file can be a 1203 dependency in the manifest of the encrypted TA. Thus, the TEEP Agent 1204 would look at the TA manifest, determine there is a dependency with a 1205 TAM URI of the SP's TAM. The Agent would then install the 1206 dependency, and then continue with the TA installation steps, 1207 including decrypting the TA binary with the relevant key. 1209 10. IANA Considerations 1211 This document does not require actions by IANA. 1213 11. Contributors 1215 - Andrew Atyeo 1217 - Intercede 1219 - andrew.atyeo@intercede.com 1221 - Liu Dapeng 1223 - Alibaba Group 1225 - maxpassion@gmail.com 1227 12. Acknowledgements 1229 We would like to thank Nick Cook, Minho Yoo, Brian Witten, Tyler Kim, 1230 Alin Mutu, Juergen Schoenwaelder, Nicolae Paladi, Sorin Faibish, Ned 1231 Smith, Russ Housley, Jeremy O'Donoghue, and Anders Rundgren for their 1232 feedback. 1234 13. Informative References 1236 [GPTEE] Global Platform, "GlobalPlatform Device Technology: TEE 1237 System Architecture, v1.1", Global Platform GPD_SPE_009, 1238 January 2017, . 1241 [I-D.ietf-suit-manifest] 1242 Moran, B., Tschofenig, H., and H. Birkholz, "A Concise 1243 Binary Object Representation (CBOR)-based Serialization 1244 Format for the Software Updates for Internet of Things 1245 (SUIT) Manifest", draft-ietf-suit-manifest-02 (work in 1246 progress), November 2019. 1248 [I-D.ietf-teep-otrp-over-http] 1249 Thaler, D., "HTTP Transport for Trusted Execution 1250 Environment Provisioning: Agent-to- TAM Communication", 1251 draft-ietf-teep-otrp-over-http-03 (work in progress), 1252 November 2019. 1254 [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management 1255 Requirements", RFC 6024, DOI 10.17487/RFC6024, October 1256 2010, . 1258 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 1259 Agility and Selecting Mandatory-to-Implement Algorithms", 1260 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 1261 . 1263 Authors' Addresses 1265 Mingliang Pei 1266 Symantec 1268 EMail: mingliang_pei@symantec.com 1270 Hannes Tschofenig 1271 Arm Limited 1273 EMail: hannes.tschofenig@arm.com 1275 Dave Thaler 1276 Microsoft 1278 EMail: dthaler@microsoft.com 1280 David Wheeler 1281 Intel 1283 EMail: david.m.wheeler@intel.com