< draft-ietf-teep-architecture-10.txt   draft-ietf-teep-architecture-11.txt >
TEEP M. Pei TEEP M. Pei
Internet-Draft Broadcom Internet-Draft Broadcom
Intended status: Informational H. Tschofenig Intended status: Informational H. Tschofenig
Expires: December 21, 2020 Arm Limited Expires: January 3, 2021 Arm Limited
D. Thaler D. Thaler
Microsoft Microsoft
D. Wheeler D. Wheeler
Intel Intel
June 19, 2020 July 02, 2020
Trusted Execution Environment Provisioning (TEEP) Architecture Trusted Execution Environment Provisioning (TEEP) Architecture
draft-ietf-teep-architecture-10 draft-ietf-teep-architecture-11
Abstract Abstract
A Trusted Execution Environment (TEE) is an environment that enforces A Trusted Execution Environment (TEE) is an environment that enforces
that any code within that environment cannot be tampered with, and 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 that any data used by such code cannot be read or tampered with by
any code outside that environment. This architecture document any code outside that environment. This architecture document
motivates the design and standardization of a protocol for managing motivates the design and standardization of a protocol for managing
the lifecycle of trusted applications running inside such a TEE. the lifecycle of trusted applications running inside such a TEE.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 40 skipping to change at page 2, line 40
3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 8 3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 8
3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 8 3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 8
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. System Components . . . . . . . . . . . . . . . . . . . . 8 4.1. System Components . . . . . . . . . . . . . . . . . . . . 8
4.2. Multiple TEEs in a Device . . . . . . . . . . . . . . . . 11 4.2. Multiple TEEs in a Device . . . . . . . . . . . . . . . . 11
4.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 13 4.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 13
4.4. Untrusted Apps, Trusted Apps, and Personalization Data . 14 4.4. Untrusted Apps, Trusted Apps, and Personalization Data . 14
4.4.1. Example: Application Delivery Mechanisms in Intel SGX 15 4.4.1. Example: Application Delivery Mechanisms in Intel SGX 15
4.4.2. Example: Application Delivery Mechanisms in Arm 4.4.2. Example: Application Delivery Mechanisms in Arm
TrustZone . . . . . . . . . . . . . . . . . . . . . . 16 TrustZone . . . . . . . . . . . . . . . . . . . . . . 16
4.5. Entity Relations . . . . . . . . . . . . . . . . . . . . 16 4.5. Entity Relations . . . . . . . . . . . . . . . . . . . . 17
5. Keys and Certificate Types . . . . . . . . . . . . . . . . . 18 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.2. Trust Anchors in a TEE . . . . . . . . . . . . . . . . . 20
5.3. Trust Anchors in a TAM . . . . . . . . . . . . . . . . . 20 5.3. Trust Anchors in a TAM . . . . . . . . . . . . . . . . . 20
5.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 20 5.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 20
5.5. Message Security . . . . . . . . . . . . . . . . . . . . 20 5.5. Message Security . . . . . . . . . . . . . . . . . . . . 21
6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 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. TEEP Broker Implementation Consideration . . . . . . . . 22
6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 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. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Information Required in TEEP Claims . . . . . . . . . . . 24 7.1. Information Required in TEEP Claims . . . . . . . . . . . 25
8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 25 8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 25 9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 26
9.2. Data Protection . . . . . . . . . . . . . . . . . . . . . 26 9.2. Data Protection . . . . . . . . . . . . . . . . . . . . . 26
9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 26 9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 27
9.4. Compromised CA . . . . . . . . . . . . . . . . . . . . . 27 9.4. Compromised CA . . . . . . . . . . . . . . . . . . . . . 27
9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 27 9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 28
9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 27 9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 28
9.7. Certificate Expiry and Renewal . . . . . . . . . . . . . 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 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
13. Informative References . . . . . . . . . . . . . . . . . . . 29 13. Informative References . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
Applications executing in a device are exposed to many different Applications executing in a device are exposed to many different
attacks intended to compromise the execution of the application or attacks intended to compromise the execution of the application or
reveal the data upon which those applications are operating. These reveal the data upon which those applications are operating. These
attacks increase with the number of other applications on the device, attacks increase with the number of other applications on the device,
with such other applications coming from potentially untrustworthy with such other applications coming from potentially untrustworthy
sources. The potential for attacks further increases with the sources. The potential for attacks further increases with the
complexity of features and applications on devices, and the complexity of features and applications on devices, and the
skipping to change at page 16, line 40 skipping to change at page 16, line 40
which would in turn send this data to the SGX enclave (TA). This 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 complexity is due to the fact that each SGX enclave is separate and
does not have direct communication to other SGX enclaves. does not have direct communication to other SGX enclaves.
4.4.2. Example: Application Delivery Mechanisms in Arm TrustZone 4.4.2. Example: Application Delivery Mechanisms in Arm TrustZone
In Arm TrustZone [TrustZone] for A-class devices, the Untrusted In Arm TrustZone [TrustZone] for A-class devices, the Untrusted
Application and TA may or may not be bundled together. This differs 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 from SGX since in TrustZone the TA lifetime is not inherently tied to
a specific Untrused Application process lifetime as occurs in SGX. A 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 TA is loaded by a trusted OS running in the TEE such as a
is separate from the OS in the REE. Thus Cases 2 and 3 are equally GlobalPlatform compliant TEE, where the trusted OS is separate from
applicable. In addition, it is possible for TAs to communicate with the OS in the REE. Thus Cases 2 and 3 are equally applicable. In
each other without involving any Untrusted Application, and so the addition, it is possible for TAs to communicate with each other
complexity of Case 1 is lower than in the SGX example. Thus, Case 1 without involving any Untrusted Application, and so the complexity of
is possible as well, though still more complex than Cases 2 and 3. 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 4.5. Entity Relations
This architecture leverages asymmetric cryptography to authenticate a This architecture leverages asymmetric cryptography to authenticate a
device to a TAM. Additionally, a TEEP Agent in a device device to a TAM. Additionally, a TEEP Agent in a device
authenticates a TAM. The provisioning of Trust Anchors to 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 may be different from one use case to the other. A Device
Administrator may want to have the capability to control what TAs are Administrator may want to have the capability to control what TAs are
allowed. A device manufacturer enables verification by one or more allowed. A device manufacturer enables verification by one or more
TAMs and by TA Signers; it may embed a list of default Trust Anchors TAMs and by TA Signers; it may embed a list of default Trust Anchors
skipping to change at page 24, line 25 skipping to change at page 24, line 51
attestation keys of the TEE; attestation keys of the TEE;
- The source or local verification of claims within an attestation - The source or local verification of claims within an attestation
prior to a TEE signing a set of claims; prior to a TEE signing a set of claims;
- The level of protection afforded to attestation keys against - The level of protection afforded to attestation keys against
exfiltration, modification, and side channel attacks; exfiltration, modification, and side channel attacks;
- The limitations of use applied to TEE attestation keys; - 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. - The revocation and recovery process of TEE attestation keys.
Some TAMs may require additional claims in order to properly Some TAMs may require additional claims in order to properly
authorize a device or TEE. The specific format for these additional authorize a device or TEE. The specific format for these additional
claims are outside the scope of this specification, but the TEEP claims are outside the scope of this specification, but the TEEP
protocol allows these additional claims to be included in the protocol allows these additional claims to be included in the
attestation messages. attestation messages.
For more discussion of the attestation and appraisal process, see the For more discussion of the attestation and appraisal process, see the
RATS Architecture [I-D.ietf-rats-architecture]. RATS Architecture [I-D.ietf-rats-architecture].
7.1. Information Required in TEEP Claims 7.1. Information Required in TEEP Claims
- Device Identifying Info: TEEP attestations may need to uniquely - Device Identifying Information: TEEP attestations may need to
identify a device to the TAM. Unique device identification allows uniquely identify a device to the TAM. Unique device
the TAM to provide services to the device, such as managing identification allows the TAM to provide services to the device,
installed TAs, and providing subscriptions to services, and such as managing installed TAs, and providing subscriptions to
locating device-specific keying material to communicate with or services, and locating device-specific keying material to
authenticate the device. In some use cases it may be sufficient communicate with or authenticate the device. In some use cases it
to identify only the class of the device. The security and may be sufficient to identify only the class of the device. The
privacy requirements regarding device identification will vary security and privacy requirements regarding device identification
with the type of TA provisioned to the TEE. 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 attestation must be identified, including version identification
information such as the hardware, firmware, and software version information such as the hardware, firmware, and software version
of the TEE, as applicable by the TEE type. TEE manufacturer of the TEE, as applicable by the TEE type. TEE manufacturer
information for the TEE is required in order to disambiguate the information for the TEE is required in order to disambiguate the
same TEE type created by different manufacturers and address same TEE type created by different manufacturers and address
considerations around manufacturer provisioning, keying and considerations around manufacturer provisioning, keying and
support for the TEE. support for the TEE.
- Freshness Proof: A claim that includes freshness information must - Freshness Proof: A claim that includes freshness information must
be included, such as a nonce or timestamp. be included, such as a nonce or timestamp.
 End of changes. 19 change blocks. 
36 lines changed or deleted 36 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/