--- 1/draft-ietf-teep-architecture-06.txt 2020-03-07 19:13:43.570957605 -0800 +++ 2/draft-ietf-teep-architecture-07.txt 2020-03-07 19:13:43.638959330 -0800 @@ -1,23 +1,23 @@ TEEP M. Pei Internet-Draft Symantec Intended status: Informational H. Tschofenig -Expires: August 11, 2020 Arm Limited +Expires: September 8, 2020 Arm Limited D. Thaler Microsoft D. Wheeler Intel - February 08, 2020 + March 07, 2020 Trusted Execution Environment Provisioning (TEEP) Architecture - draft-ietf-teep-architecture-06 + draft-ietf-teep-architecture-07 Abstract A Trusted Execution Environment (TEE) is an environment that enforces that only authorized code can execute within that environment, 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,21 +29,21 @@ 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 http://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 August 11, 2020. + This Internet-Draft will expire on September 8, 2020. Copyright Notice Copyright (c) 2020 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -71,26 +71,26 @@ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 7 3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 7 3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 8 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. System Components . . . . . . . . . . . . . . . . . . . . 8 4.2. Multiple TEEs in a Device . . . . . . . . . . . . . . . . 10 4.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 12 - 4.4. Untrusted Apps, Trusted Apps, and Personalization Data . 13 + 4.4. Untrusted Apps, Trusted Apps, and Personalization Data . 14 4.4.1. Examples of Application Delivery Mechanisms in - Existing TEEs . . . . . . . . . . . . . . . . . . . . 14 + Existing TEEs . . . . . . . . . . . . . . . . . . . . 15 4.5. Entity Relations . . . . . . . . . . . . . . . . . . . . 16 5. Keys and Certificate Types . . . . . . . . . . . . . . . . . 17 - 5.1. Trust Anchors in a TEEP Agent . . . . . . . . . . . . . . 18 + 5.1. Trust Anchors in a TEEP Agent . . . . . . . . . . . . . . 19 5.2. Trust Anchors in a TEE . . . . . . . . . . . . . . . . . 19 5.3. Trust Anchors in a TAM . . . . . . . . . . . . . . . . . 19 5.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 19 5.5. Message Security . . . . . . . . . . . . . . . . . . . . 20 6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 20 6.2. TEEP Broker Implementation Consideration . . . . . . . . 21 6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 21 6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 22 7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 22 @@ -98,25 +98,25 @@ 8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 25 9.2. Data Protection at TAM and TEE . . . . . . . . . . . . . 25 9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 25 9.4. Compromised CA . . . . . . . . . . . . . . . . . . . . . 26 9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 26 9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 26 9.7. Certificate Renewal . . . . . . . . . . . . . . . . . . . 27 9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 27 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 - 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 + 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 13. Informative References . . . . . . . . . . . . . . . . . . . 28 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction Applications executing in a device are exposed to many different attacks intended to compromise the execution of the application or reveal the data upon which those applications are operating. These attacks increase with the number of other applications on the device, with such other applications coming from potentially untrustworthy sources. The potential for attacks further increases with the complexity of features and applications on devices, and the @@ -246,21 +246,21 @@ with other human beings as secondary device users (e.g., parent allowing children to use their tablet or laptop). Other devices are not used by a human being and hence have no device user. Relates to Device Owner and Device Administrator. - Rich Execution Environment (REE): An environment that is provided and governed by a typical OS (e.g., Linux, Windows, Android, iOS), potentially in conjunction with other supporting operating systems and hypervisors; it is outside of any TEE. This environment and applications running on it are considered untrusted (or more - precisely, less trusted than the TEE). + precisely, less trusted than a TEE). - Trust Anchor: As defined in [RFC6024] and [I-D.ietf-suit-manifest], "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 along with additional data if necessary such as its public key algorithm and parameters. @@ -428,23 +428,25 @@ keys in their device's Trust Anchor list. Alternatively, a TAM may publish its certificate and allow Device Administrators to install the TAM's certificate in their devices as an after-market- action. - TEEP Broker: A TEEP Broker is an application component running in a Rich Execution Environment (REE) that enables the message protocol exchange between a TAM and a TEE in a device. A TEEP Broker does not process messages on behalf of a TEE, but merely is responsible for relaying messages from the TAM to the TEE, and for - returning the TEE's responses to the TAM. In devices with no REE, - the TEEP Broker would be absent and instead the TEEP protocol - transport would be implemented inside the TEE itself. + returning the TEE's responses to the TAM. In devices with no REE + (e.g., a microcontroller where all code runs in an environment + that meets the definition of a Trusted Execution Environment in + Section 2), the TEEP Broker would be absent and instead the TEEP + protocol transport would be implemented inside the TEE itself. - TEEP Agent: The TEEP Agent is a processing module running inside a TEE that receives TAM requests (typically relayed via a TEEP Broker that runs in an REE). A TEEP Agent in the TEE may parse requests or forward requests to other processing modules in a TEE, which is up to a TEE provider's implementation. A response message corresponding to a TAM request is sent back to the TAM, again typically relayed via a TEEP Broker. - Certification Authority (CA): Certificate-based credentials used @@ -526,20 +528,24 @@ resource usage. 4.3. Multiple TAMs and Relationship to TAs As shown in Figure 2, a TEEP Broker provides communication between one or more TEEP Agents and one or more TAMs. The selection of which TAM to communicate with might be made with or without input from an Untrusted Application, but is ultimately the decision of a TEEP Agent. + A TEEP Agent is assumed to be able to determine, for any given TA, + whether that TA is installed (or minimally, is running) in a TEE with + which the TEEP Agent is associated. + Each TA is digitally signed, protecting its integrity, and linking the TA back to the signer. The signer is usually the TA software author, but in some cases might be another party that the TA software author trusts, or a party to whom the code has been licensed (in which case the same code might be signed by multiple licensees and distributed as if it were different TAs). A TA author or signer selects one or more TAMs through which to offer their TA(s), and communicates the TA(s) to the TAM. In this document, we use the term "TA developer" to refer to the entity that @@ -808,32 +814,41 @@ Code Signing 1 per TA TA binary TEE developer Figure 4: Keys Note that personalization data is not included in the table above. The use of personalization data is dependent on how TAs are used and what their security requirements are. - The TEE key pair and certificate are used for authenticating the TEE - to a remote TAM. Often, the key pair is burned into the TEE by the - TEE manufacturer and the key pair and its certificate are valid for - the expected lifetime of the TEE. A TAM provider is responsible for - configuring the TAM's Trust Anchor Store with the manufacturer - certificates or CAs that are used to sign TEE keys. This is - discussed further in Section 5.3 below. + TEEP requests from a TAM to a TEEP Agent can be encrypted with the + TEE public key (to provide confidentiality), and are then signed with + the TAM private key (for authentication and integrity protection). + Conversely, TEEP responses from a TEEP Agent to a TAM can be + encrypted with the TAM public key, and are then signed with the TEE + private key. + + The TEE key pair and certificate are thus used for authenticating the + TEE to a remote TAM, and for sending private data to the TEE. Often, + the key pair is burned into the TEE by the TEE manufacturer and the + key pair and its certificate are valid for the expected lifetime of + the TEE. A TAM provider is responsible for configuring the TAM's + Trust Anchor Store with the manufacturer certificates or CAs that are + used to sign TEE keys. This is discussed further in Section 5.3 + below. The TAM key pair and certificate are used for authenticating a TAM to - a remote TEE. A TAM provider is responsible for acquiring a - certificate from a CA that is trusted by the TEEs it manages. This - is discussed further in Section 5.1 below. + a remote TEE, and for sending private data to the TAM. A TAM + provider is responsible for acquiring a certificate from a CA that is + trusted by the TEEs it manages. This is discussed further in + Section 5.1 below. The TA developer key pair and certificate are used to sign TAs that the TEE will consider authorized to execute. TEEs must be configured with the certificates or keys that it considers authorized to sign TAs that it will execute. This is discussed further in Section 5.2 below. 5.1. Trust Anchors in a TEEP Agent A TEEP Agent's Trust Anchor Store contains a list of Trust Anchors, @@ -1132,21 +1147,22 @@ 9. Security Considerations 9.1. Broker Trust Model The architecture enables the TAM to communicate, via a TEEP Broker, with the device's TEE to manage TAs. Since the TEEP Broker runs in a potentially vulnerable REE, the TEEP Broker could, however, be (or be infected by) malware. As such, all TAM messages are signed and sensitive data is encrypted such that the TEEP Broker cannot modify - or capture sensitive data. + or capture sensitive data, but the TEEP Broker can still conduct DoS + attacks as discussed in Section 9.3. A TEEP Agent in a TEE is responsible for protecting against potential attacks from a compromised TEEP Broker or rogue malware in the REE. A rogue TEEP Broker might send corrupted data to the TEEP Agent, or launch a DoS attack by sending a flood of TEEP protocol requests. The TEEP Agent validates the signature of each TEEP protocol request and checks the signing certificate against its Trust Anchors. To mitigate DoS attacks, it might also add some protection scheme such as a threshold on repeated requests or number of TAs that can be installed. @@ -1154,22 +1170,23 @@ 9.2. Data Protection at TAM and TEE The TEE implementation provides protection of data on the device. It is the responsibility of the TAM to protect data on its servers. 9.3. Compromised REE It is possible that the REE of a device is compromised. If the REE is compromised, several DoS attacks may be launched. The compromised REE may terminate the TEEP Broker such that TEEP transactions cannot - reach the TEE. However, while a DoS attack cannot be prevented, the - REE cannot access anything in the TEE if it is implemented correctly. + 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 it 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 have such 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 TA. A TA 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. @@ -1215,21 +1232,30 @@ It may happen that a TA was previously considered trustworthy but is later found to be buggy or compromised. In this case, the TAM can initiate the removal of the TA by notifying devices to remove the TA (and potentially the REE or device owner to remove any Untrusted Application that depend on the TA). If the TAM does not currently have a connection to the TEEP Agent on a device, such a notification would occur the next time connectivity does exist. Furthermore the policy in the Verifier in an attestation process can be updated so that any evidence that includes the malicious TA would - result in an attestation failure. + result in an attestation failure. There is, however, a time window + 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 5 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 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 update. On the other hand, it is imperative that OEMs or device providers plan for support of Trust @@ -1284,22 +1310,22 @@ [I-D.ietf-suit-manifest] Moran, B., Tschofenig, H., and H. Birkholz, "A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest", draft-ietf-suit-manifest-03 (work in progress), February 2020. [I-D.ietf-teep-otrp-over-http] Thaler, D., "HTTP Transport for Trusted Execution Environment Provisioning: Agent-to- TAM Communication", - draft-ietf-teep-otrp-over-http-03 (work in progress), - November 2019. + draft-ietf-teep-otrp-over-http-04 (work in progress), + February 2020. [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management Requirements", RFC 6024, DOI 10.17487/RFC6024, October 2010, . [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, .