--- 1/draft-ietf-teep-architecture-10.txt 2020-07-02 16:13:12.025908263 -0700 +++ 2/draft-ietf-teep-architecture-11.txt 2020-07-02 16:13:12.093909983 -0700 @@ -1,23 +1,23 @@ TEEP M. Pei Internet-Draft Broadcom Intended status: Informational H. Tschofenig -Expires: December 21, 2020 Arm Limited +Expires: January 3, 2021 Arm Limited D. Thaler Microsoft D. Wheeler Intel - June 19, 2020 + July 02, 2020 Trusted Execution Environment Provisioning (TEEP) Architecture - draft-ietf-teep-architecture-10 + draft-ietf-teep-architecture-11 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,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 December 21, 2020. + This Internet-Draft will expire on January 3, 2021. 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 @@ -75,50 +75,50 @@ 3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 8 3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 8 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. System Components . . . . . . . . . . . . . . . . . . . . 8 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 . 14 4.4.1. Example: Application Delivery Mechanisms in Intel SGX 15 4.4.2. Example: Application Delivery Mechanisms in Arm TrustZone . . . . . . . . . . . . . . . . . . . . . . 16 - 4.5. Entity Relations . . . . . . . . . . . . . . . . . . . . 16 + 4.5. Entity Relations . . . . . . . . . . . . . . . . . . . . 17 5. Keys and Certificate Types . . . . . . . . . . . . . . . . . 18 - 5.1. Trust Anchors in a TEEP Agent . . . . . . . . . . . . . . 19 + 5.1. Trust Anchors in a TEEP Agent . . . . . . . . . . . . . . 20 5.2. Trust Anchors in a TEE . . . . . . . . . . . . . . . . . 20 5.3. Trust Anchors in a TAM . . . . . . . . . . . . . . . . . 20 5.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 20 - 5.5. Message Security . . . . . . . . . . . . . . . . . . . . 20 + 5.5. Message Security . . . . . . . . . . . . . . . . . . . . 21 6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 21 + 6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 22 6.2. TEEP Broker Implementation Consideration . . . . . . . . 22 6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 22 - 6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 22 + 6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 23 7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 7.1. Information Required in TEEP Claims . . . . . . . . . . . 24 + 7.1. Information Required in TEEP Claims . . . . . . . . . . . 25 8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 25 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 - 9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 25 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 + 9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 26 9.2. Data Protection . . . . . . . . . . . . . . . . . . . . . 26 - 9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 26 + 9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 27 9.4. Compromised CA . . . . . . . . . . . . . . . . . . . . . 27 - 9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 27 - 9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 27 + 9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 28 + 9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 28 9.7. Certificate Expiry and Renewal . . . . . . . . . . . . . 28 - 9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 28 + 9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 29 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 - 13. Informative References . . . . . . . . . . . . . . . . . . . 29 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 + 13. Informative References . . . . . . . . . . . . . . . . . . . 30 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 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 @@ -721,26 +721,27 @@ which would in turn send this data to the SGX enclave (TA). This complexity is due to the fact that each SGX enclave is separate and does not have direct communication to other SGX enclaves. 4.4.2. Example: Application Delivery Mechanisms in Arm TrustZone In Arm TrustZone [TrustZone] for A-class devices, the Untrusted Application and TA may or may not be bundled together. This differs from SGX since in TrustZone the TA lifetime is not inherently tied to a specific Untrused Application process lifetime as occurs in SGX. A - TA is loaded by a trusted OS running in the TEE, where the trusted OS - is separate from the OS in the REE. Thus Cases 2 and 3 are equally - applicable. In addition, it is possible for TAs to communicate with - each other without involving any Untrusted Application, and so the - complexity of Case 1 is lower than in the SGX example. Thus, Case 1 - is possible as well, though still more complex than Cases 2 and 3. + TA is loaded by a trusted OS running in the TEE such as a + GlobalPlatform compliant TEE, where the trusted OS is separate from + the OS in the REE. Thus Cases 2 and 3 are equally applicable. In + addition, it is possible for TAs to communicate with each other + without involving any Untrusted Application, and so the complexity of + Case 1 is lower than in the SGX example. Thus, Case 1 is possible as + well, though still more complex than Cases 2 and 3. 4.5. Entity Relations This architecture leverages asymmetric cryptography to authenticate a device to a TAM. Additionally, a TEEP Agent in a device authenticates a TAM. The provisioning of Trust Anchors to a device may be different from one use case to the other. A Device Administrator may want to have the capability to control what TAs are allowed. A device manufacturer enables verification by one or more TAMs and by TA Signers; it may embed a list of default Trust Anchors @@ -1089,46 +1090,45 @@ attestation keys of the TEE; - The source or local verification of claims within an attestation prior to a TEE signing a set of claims; - The level of protection afforded to attestation keys against exfiltration, modification, and side channel attacks; - The limitations of use applied to TEE attestation keys; - - The processes in place to discover or detect TEE breeches; and - + - The processes in place to discover or detect TEE breaches; and - The revocation and recovery process of TEE attestation keys. Some TAMs may require additional claims in order to properly authorize a device or TEE. The specific format for these additional claims are outside the scope of this specification, but the TEEP protocol allows these additional claims to be included in the attestation messages. For more discussion of the attestation and appraisal process, see the RATS Architecture [I-D.ietf-rats-architecture]. 7.1. Information Required in TEEP Claims - - Device Identifying Info: TEEP attestations may need to uniquely - identify a device to the TAM. Unique device identification allows - the TAM to provide services to the device, such as managing - installed TAs, and providing subscriptions to services, and - locating device-specific keying material to communicate with or - authenticate the device. In some use cases it may be sufficient - to identify only the class of the device. The security and - privacy requirements regarding device identification will vary - with the type of TA provisioned to the TEE. + - Device Identifying Information: TEEP attestations may need to + uniquely identify a device to the TAM. Unique device + identification allows the TAM to provide services to the device, + such as managing installed TAs, and providing subscriptions to + services, and locating device-specific keying material to + communicate with or authenticate the device. In some use cases it + may be sufficient to identify only the class of the device. The + security and privacy requirements regarding device identification + will vary with the type of TA provisioned to the TEE. - - TEE Identifying info: The type of TEE that generated this + - TEE Identifying Information: The type of TEE that generated this attestation must be identified, including version identification information such as the hardware, firmware, and software version of the TEE, as applicable by the TEE type. TEE manufacturer information for the TEE is required in order to disambiguate the same TEE type created by different manufacturers and address considerations around manufacturer provisioning, keying and support for the TEE. - Freshness Proof: A claim that includes freshness information must be included, such as a nonce or timestamp.