--- 1/draft-ietf-teep-architecture-16.txt 2022-04-19 12:13:12.267870035 -0700 +++ 2/draft-ietf-teep-architecture-17.txt 2022-04-19 12:13:12.343871954 -0700 @@ -1,23 +1,23 @@ TEEP M. Pei Internet-Draft Broadcom Intended status: Informational H. Tschofenig -Expires: 1 September 2022 Arm Limited +Expires: 21 October 2022 Arm Limited D. Thaler Microsoft D. Wheeler Amazon - 28 February 2022 + 19 April 2022 Trusted Execution Environment Provisioning (TEEP) Architecture - draft-ietf-teep-architecture-16 + draft-ietf-teep-architecture-17 Abstract A Trusted Execution Environment (TEE) is an environment that enforces that any code within that environment cannot be tampered with, and that any data used by such code cannot be read or tampered with by any code outside that environment. This architecture document motivates the design and standardization of a protocol for managing the lifecycle of trusted applications running inside such a TEE. @@ -29,46 +29,46 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 1 September 2022. + This Internet-Draft will expire on 21 October 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components - extracted from this document must include Simplified BSD License text - as described in Section 4.e of the Trust Legal Provisions and are - provided without warranty as described in the Simplified BSD License. + extracted from this document must include Revised BSD License text as + described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 8 3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 8 - 3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 9 + 3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 8 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. System Components . . . . . . . . . . . . . . . . . . . . 9 4.2. Multiple TEEs in a Device . . . . . . . . . . . . . . . . 11 4.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 13 4.4. Untrusted Apps, Trusted Apps, and Personalization Data . 15 4.4.1. Example: Application Delivery Mechanisms in Intel SGX . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.4.2. Example: Application Delivery Mechanisms in Arm TrustZone . . . . . . . . . . . . . . . . . . . . . . 17 4.5. Entity Relations . . . . . . . . . . . . . . . . . . . . 17 @@ -85,21 +85,21 @@ 6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 25 7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 28 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 28 9.2. Data Protection . . . . . . . . . . . . . . . . . . . . . 29 9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 30 9.4. CA Compromise or Expiry of CA Certificate . . . . . . . . 31 9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 31 9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 31 - 9.7. Certificate Expiry and Renewal . . . . . . . . . . . . . 32 + 9.7. TEE Certificate Expiry and Renewal . . . . . . . . . . . 32 9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 33 9.9. REE Privacy . . . . . . . . . . . . . . . . . . . . . . . 33 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 13. Informative References . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction @@ -146,26 +146,26 @@ TEEs are typically used in cases where a software or data asset needs to be protected from unauthorized entities that may include the owner (or pwner) or possesser of a device. This situation arises for example in gaming consoles where anti-cheat protection is a concern, devices such as ATMs or IoT devices placed in locations where attackers might have physical access, cell phones or other devices used for mobile payments, and hosted cloud environments. Such environments can be thought of as hybrid devices where one user or administrator controls the REE and a different (remote) user or - administrator controls a TEE in the same physical device. It may - also be the case in some constrained devices that there is no REE - (only a TEE) and there may be no local "user" per se, only a remote - TEE administrator. For further discussion of such confidential - computing use cases and threat model, see [CC-Overview] and - [CC-Technical-Analysis]. + administrator controls a TEE in the same physical device. + It may also be the case in some constrained devices that there is no + REE (only a TEE) and there may be no local "user" per se, only a + remote TEE administrator. For further discussion of such + confidential computing use cases and threat model, see [CC-Overview] + and [CC-Technical-Analysis]. TEEs use hardware enforcement combined with software protection to secure TAs and its data. TEEs typically offer a more limited set of services to TAs than is normally available to Untrusted Applications. Not all TEEs are the same, however, and different vendors may have different implementations of TEEs with different security properties, different features, and different control mechanisms to operate on TAs. Some vendors may themselves market multiple different TEEs with different properties attuned to different markets. A device vendor @@ -211,29 +211,33 @@ the TEE. * A Device Administrator wants to remove a TA from a device's TEE if the TA developer is no longer maintaining that TA, when the TA has been revoked, or is not used for other reasons anymore (e.g., due to an expired subscription). For TEEs that simply verify and load signed TA's from an untrusted filesystem, classic application distribution protocols can be used without modification. The problems in the bullets above, on the - other hand, require a new protocol, i.e., the TEEP protocol, for TEEs - that can install and enumerate TAs in a TEE-secured location and - where another domain-specific protocol standard (e.g., [GSMA], - [OTRP]) that meets the needs is not already in use. + other hand, require a new protocol, i.e., the TEEP protocol. The + TEEP protocol is a solution for TEEs that can install and enumerate + TAs in a TEE-secured location where another domain-specific protocol + standard (e.g., [GSMA], [OTRP]) that meets the needs is not already + in use. 2. Terminology The following terms are used: + * App Store: An online location from which Untrusted Applications + can be downloaded. + * Device: A physical piece of hardware that hosts one or more TEEs, often along with an REE. * Device Administrator: An entity that is responsible for administration of a device, which could be the Device Owner. A Device Administrator has privileges on the device to install and remove Untrusted Applications and TAs, approve or reject Trust Anchors, and approve or reject TA developers, among possibly other privileges on the device. A Device Administrator can manage the list of allowed TAMs by modifying the list of Trust Anchors on the @@ -276,21 +280,23 @@ and hypervisors; it is outside of the TEE(s) managed by the TEEP protocol. This environment and applications running on it are considered untrusted (or more precisely, less trusted than a TEE). * Trust Anchor: As defined in [RFC6024] and [I-D.ietf-suit-architecture], "A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative." The Trust Anchor may be - a certificate or it may be a raw public key. + a certificate, a raw public key or other structure, as + appropriate. It can be a non-root certificate when it is a + certificate. * Trust Anchor Store: As defined in [RFC6024], "A trust anchor store is a set of one or more trust anchors stored in a device... A device may have more than one trust anchor store, each of which may be used by one or more applications." As noted in [I-D.ietf-suit-architecture], a Trust Anchor Store must resist modification against unauthorized insertion, deletion, and modification. * Trusted Application (TA): An application (or, in some @@ -355,25 +361,26 @@ 3.2. Authentication For better security of authentication, a device may store its keys and cryptographic libraries inside a TEE limiting access to cryptographic functions via a well-defined interface and thereby reducing access to keying material. 3.3. Internet of Things Weak security in Internet of Things (IoT) devices has been posing - threats to critical infrastructure that relies upon such devices. It - is desirable that IoT devices can prevent malware from manipulating - actuators (e.g., unlocking a door), or stealing or modifying - sensitive data, such as authentication credentials in the device. A - TEE can be the best way to implement such IoT security functions. + threats to critical infrastructure, i.e., assets that are essential + for the functioning of a society and economy. It is desirable that + IoT devices can prevent malware from manipulating actuators (e.g., + unlocking a door), or stealing or modifying sensitive data, such as + authentication credentials in the device. A TEE can be the best way + to implement such IoT security functions. 3.4. Confidential Cloud Computing A tenant can store sensitive data, such as customer details or credit card numbers, in a TEE in a cloud computing server such that only the tenant can access the data, preventing the cloud hosting provider from accessing the data. A tenant can run TAs inside a server TEE for secure operation and enhanced data security. This provides benefits not only to tenants with better data security but also to cloud hosting providers for reduced liability and increased cloud @@ -667,24 +674,23 @@ Untrusted Application in an REE and one or more TAs in a TEE, as shown in Figure 2. For most purposes, an Untrusted Application that uses one or more TAs in a TEE appears no different from any other Untrusted Application in the REE. However, the way the Untrusted Application and its corresponding TAs are packaged, delivered, and installed on the device can vary. The variations depend on whether the Untrusted Application and TA are bundled together or are provided separately, and this has implications to the management of the TAs in a TEE. In addition to the Untrusted Application and TA(s), the TA(s) and/or TEE may also require additional data to personalize the TA to - the device or a user. Implementations must support encryption of - such Personalization Data to preserve the confidentiality of - potentially sensitive data contained within it, and must support - integrity protection of the Personalization Data. Other than the + the device or a user. Implementations must support encryption to + preserve the confidentiality and integrity of such Personalized Data, + which may potentially contain sensitive data. Other than the requirement to support confidentiality and integrity protection, the TEEP architecture places no limitations or requirements on the Personalization Data. There are multiple possible cases for bundling of an Untrusted Application, TA(s), and Personalization Data. Such cases include (possibly among others): 1. The Untrusted Application, TA(s), and Personalization Data are all bundled together in a single package by a Trusted Component @@ -1355,26 +1361,26 @@ 9.3. Compromised REE It is possible that the REE of a device is compromised. We have already seen examples of attacks on the public Internet with billions of compromised devices being used to mount DDoS attacks. A compromised REE can be used for such an attack but it cannot tamper with the TEE's code or data in doing so. A compromised REE can, however, launch DoS attacks against the TEE. The compromised REE may terminate the TEEP Broker such that TEEP - transactions cannot reach the TEE, or might drop or delay messages - between a TAM and a TEEP Agent. However, while a DoS attack cannot - be prevented, the REE cannot access anything in the TEE if the TEE is - implemented correctly. Some TEEs may have some watchdog scheme to - observe REE state and mitigate DoS attacks against it but most TEEs - don't have such a capability. + transactions cannot reach the TEE, or might drop, replay, or delay + messages between a TAM and a TEEP Agent. However, while a DoS attack + cannot be prevented, the REE cannot access anything in the TEE if the + TEE is implemented correctly. Some TEEs may have some watchdog + scheme to observe REE state and mitigate DoS attacks against it but + most TEEs don't have such a capability. In some other scenarios, the compromised REE may ask a TEEP Broker to make repeated requests to a TEEP Agent in a TEE to install or uninstall a Trusted Component. An installation or uninstallation request constructed by the TEEP Broker or REE will be rejected by the TEEP Agent because the request won't have the correct signature from a TAM to pass the request signature validation. This can become a DoS attack by exhausting resources in a TEE with repeated requests. In general, a DoS attack threat exists when the @@ -1460,21 +1466,21 @@ during which a malicious TA might be able to operate successfully, which is the validity time of the previous attestation result. For example, if the Verifier in Figure 6 is updated to treat a previously valid TA as no longer trustworthy, any attestation result it previously generated saying that the TA is valid will continue to be used until the attestation result expires. As such, the TAM's Verifier should take into account the acceptable time window when generating attestation results. See [I-D.ietf-rats-architecture] for further discussion. -9.7. Certificate Expiry and Renewal +9.7. TEE Certificate Expiry and Renewal TEE device certificates are expected to be long lived, longer than the lifetime of a device. A TAM certificate usually has a moderate lifetime of 2 to 5 years. A TAM should get renewed or rekeyed certificates. The root CA certificates for a TAM, which are embedded into the Trust Anchor Store in a device, should have long lifetimes that don't require device Trust Anchor updates. On the other hand, it is imperative that OEMs or device providers plan for support of Trust Anchor update in their shipped devices. @@ -1599,23 +1605,23 @@ Environment Provisioning: Agent Initiated Communication", Work in Progress, Internet-Draft, draft-ietf-teep-otrp- over-http-13, 28 February 2022, . [I-D.ietf-teep-protocol] Tschofenig, H., Pei, M., Wheeler, D., Thaler, D., and A. Tsukamoto, "Trusted Execution Environment Provisioning (TEEP) Protocol", Work in Progress, Internet-Draft, draft- - ietf-teep-protocol-07, 25 October 2021, + ietf-teep-protocol-08, 7 March 2022, . + 08.txt>. [OTRP] GlobalPlatform, "Open Trust Protocol (OTrP) Profile v1.1", GlobalPlatform GPD_SPE_123, July 2020, . [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, .