draft-ietf-teep-architecture-04.txt   draft-ietf-teep-architecture-05.txt 
TEEP M. Pei TEEP M. Pei
Internet-Draft Symantec Internet-Draft Symantec
Intended status: Informational H. Tschofenig Intended status: Informational H. Tschofenig
Expires: June 8, 2020 Arm Limited Expires: June 14, 2020 Arm Limited
D. Thaler
Microsoft
D. Wheeler D. Wheeler
Intel Intel
A. Atyeo December 12, 2019
Intercede
L. Dapeng
Alibaba Group
December 06, 2019
Trusted Execution Environment Provisioning (TEEP) Architecture Trusted Execution Environment Provisioning (TEEP) Architecture
draft-ietf-teep-architecture-04 draft-ietf-teep-architecture-05
Abstract Abstract
A Trusted Execution Environment (TEE) is an environment that enforces A Trusted Execution Environment (TEE) is an environment that enforces
that only authorized code can execute with that environment, and that that only authorized code can execute with that environment, and that
any data used by such code cannot be read or tampered with by any any data used by such code cannot be read or tampered with by any
code outside that environment. This architecture document motivates code outside that environment. This architecture document motivates
the design and standardization of a protocol for managing the the design and standardization of a protocol for managing the
lifecycle of trusted applications running inside a TEE. lifecycle of trusted applications running inside a TEE.
skipping to change at page 1, line 42 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 June 8, 2020. This Internet-Draft will expire on June 14, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 35 skipping to change at page 2, line 31
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 7 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 7
3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 7 3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 7
3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 8 3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 7
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. System Components . . . . . . . . . . . . . . . . . . . . 8 4.1. System Components . . . . . . . . . . . . . . . . . . . . 8
4.2. Different Renditions of TEEP Architecture . . . . . . . . 10 4.2. Different Renditions of TEEP Architecture . . . . . . . . 10
4.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 12 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 . 13
4.5. Examples of Application Delivery Mechanisms in Existing 4.5. Examples of Application Delivery Mechanisms in Existing
TEEs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 TEEs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.6. Entity Relations . . . . . . . . . . . . . . . . . . . . 15 4.6. Entity Relations . . . . . . . . . . . . . . . . . . . . 15
5. Keys and Certificate Types . . . . . . . . . . . . . . . . . 17 5. Keys and Certificate Types . . . . . . . . . . . . . . . . . 17
5.1. Trust Anchors in TEE . . . . . . . . . . . . . . . . . . 18 5.1. Trust Anchors in TEE . . . . . . . . . . . . . . . . . . 18
5.2. Trust Anchors in TAM . . . . . . . . . . . . . . . . . . 18 5.2. Trust Anchors in TAM . . . . . . . . . . . . . . . . . . 19
5.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 18 5.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 19
5.4. Message Security . . . . . . . . . . . . . . . . . . . . 19 5.4. Message Security . . . . . . . . . . . . . . . . . . . . 19
6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 20 6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 20
6.2. TEEP Broker Implementation Consideration . . . . . . . . 20 6.2. TEEP Broker Implementation Consideration . . . . . . . . 20
6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 20 6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 20
6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 21 6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 21
6.2.3. Number of TEEP Brokers . . . . . . . . . . . . . . . 21 6.2.3. Number of TEEP Brokers . . . . . . . . . . . . . . . 21
7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Information Required in TEEP Claims . . . . . . . . . . . 23 7.1. Information Required in TEEP Claims . . . . . . . . . . . 23
8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 24 8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9.1. TA Trust Check at TEE . . . . . . . . . . . . . . . . . . 24 9.1. TA Trust Check at TEE . . . . . . . . . . . . . . . . . . 25
9.2. One TA Multiple SP Case . . . . . . . . . . . . . . . . . 25 9.2. One TA Multiple SP Case . . . . . . . . . . . . . . . . . 25
9.3. Broker Trust Model . . . . . . . . . . . . . . . . . . . 25 9.3. Broker Trust Model . . . . . . . . . . . . . . . . . . . 25
9.4. Data Protection at TAM and TEE . . . . . . . . . . . . . 25 9.4. Data Protection at TAM and TEE . . . . . . . . . . . . . 25
9.5. Compromised CA . . . . . . . . . . . . . . . . . . . . . 25 9.5. Compromised CA . . . . . . . . . . . . . . . . . . . . . 26
9.6. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 25 9.6. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 26
9.7. Certificate Renewal . . . . . . . . . . . . . . . . . . . 26 9.7. Certificate Renewal . . . . . . . . . . . . . . . . . . . 26
9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 26 9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27
12. Informative References . . . . . . . . . . . . . . . . . . . 26 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 28 13. Informative References . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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 increase with the sources. The potential for attacks further increase with the
skipping to change at page 4, line 8 skipping to change at page 4, line 5
This separation reduces the possibility of a successful attack on This separation reduces the possibility of a successful attack on
application components and the data contained inside the TEE. application components and the data contained inside the TEE.
Typically, application components are chosen to execute inside a TEE Typically, application components are chosen to execute inside a TEE
because those application components perform security sensitive because those application components perform security sensitive
operations or operate on sensitive data. An application component operations or operate on sensitive data. An application component
running inside a TEE is referred to as a Trusted Application (TA), running inside a TEE is referred to as a Trusted Application (TA),
while an application running outside any TEE is referred to as an while an application running outside any TEE is referred to as an
Untrusted Application (UA). Untrusted Application (UA).
The TEE typically uses hardware to enforce protections on the TA and TEEs use hardware enforcement combined with software protection to
its data, but also presents a more limited set of services to secure TAs and its data. TEEs typically offer a more limited set of
applications inside the TEE than is normally available to Untrusted services to TAs than is normally available to Untrusted Applications.
Applications.
But not all TEEs are the same, and different vendors may have But not all TEEs are the same, and different vendors may have
different implementations of TEEs with different security properties, different implementations of TEEs with different security properties,
different features, and different control mechanisms to operate on different features, and different control mechanisms to operate on
TAs. Some vendors may themselves market multiple different TEEs with TAs. Some vendors may themselves market multiple different TEEs with
different properties attuned to different markets. A device vendor different properties attuned to different markets. A device vendor
may integrate one or more TEEs into their devices depending on market may integrate one or more TEEs into their devices depending on market
needs. needs.
To simplify the life of developers and service providers interacting To simplify the life of developers and service providers interacting
skipping to change at page 4, line 36 skipping to change at page 4, line 32
devices, and their TEEs. This trusted third party is the Trusted devices, and their TEEs. This trusted third party is the Trusted
Application Manager (TAM). Application Manager (TAM).
The Trusted Execution Provisioning (TEEP) protocol addresses the The Trusted Execution Provisioning (TEEP) protocol addresses the
following problems: following problems:
- A Service Provider (SP) intending to provide services through a TA - A Service Provider (SP) intending to provide services through a TA
to users of a device needs to determine security-relevant to users of a device needs to determine security-relevant
information of a device before provisioning their TA to the TEE information of a device before provisioning their TA to the TEE
within the device. An example is the verification of the type of within the device. An example is the verification of the type of
TEE included in a device. TEE included in a device and that it is capable of providing the
security protections required by a particular TA.
- A TEE in a device needs to determine whether a Service Provider - A TEE in a device needs to determine whether a Service Provider
(SP) that wants to manage a TA in the device is authorized to (SP) that wants to manage a TA in the device is authorized to
manage TAs in the TEE, and what TAs the SP is permitted to manage. manage TAs in the TEE, and what TAs the SP is permitted to manage.
- The parties involved in the protocol must be able to attest that a
TEE is genuine and capable of providing the security protections
required by a particular TA.
- A Service Provider (SP) must be able to determine if a TA exists - A Service Provider (SP) must be able to determine if a TA exists
(is installed) on a device (in the TEE), and if not, install the (is installed) on a device (in the TEE), and if not, install the
TA in the TEE. TA in the TEE.
- A Service Provider (SP) must be able to check whether a TA in a - A Service Provider (SP) must be able to check whether a TA in a
device's TEE is the most up-to-date version, and if not, update device's TEE is the most up-to-date version, and if not, update
the TA in the TEE. the TA in the TEE.
- A Service Provider (SP) must be able to remove a TA in a device's - A Service Provider (SP) must be able to remove a TA in a device's
TEE if the SP is no longer offering such services or the services TEE if the SP is no longer offering such services or the services
are being revoked from a particular user (or device). For are being revoked from a particular user (or device). For
example, if a subscription or contract for a particular service example, if a subscription or contract for a particular service
has expired, or a payment by the user has not been completed or has expired, or a payment by the user has not been completed or
has been rescinded. has been rescinded.
- A Service Provider (SP) must be able to define the relationship - A Service Provider (SP) must be able to define the relationship
between cooperating TAs under the SP's control, and specify between cooperating TAs under the SP's control, and specify
whether the TAs can communicate, share data, and/or share key whether the TAs can communicate, share data, and/or share key
material. material.
Note: The Service Provider requires the help of a TAM to provision
the Trusted Applications to remote devices and the TEEP protocol
exchanges messages between a Trusted Application Manager (TAM) and a
TEEP Agent via a TEEP Broker.
2. Terminology 2. Terminology
The following terms are used: The following terms are used:
- Untrusted Application: An application running in a Rich Execution - Untrusted Application: An application running in a Rich Execution
Environment, such as an Android, Windows, or iOS application. Environment, such as an Android, Windows, or iOS application.
- Trusted Application Manager (TAM): An entity that manages Trusted - Trusted Application Manager (TAM): An entity that manages Trusted
Applications (TAs) running in different TEEs of various devices. Applications (TAs) running in different TEEs of various devices.
skipping to change at page 5, line 50 skipping to change at page 5, line 44
Anchor to be removed or disabled. Anchor to be removed or disabled.
- Rich Execution Environment (REE): An environment that is provided - Rich Execution Environment (REE): An environment that is provided
and governed by a typical OS (e.g., Linux, Windows, Android, iOS), and governed by a typical OS (e.g., Linux, Windows, Android, iOS),
potentially in conjunction with other supporting operating systems potentially in conjunction with other supporting operating systems
and hypervisors; it is outside of any TEE. This environment and and hypervisors; it is outside of any TEE. This environment and
applications running on it are considered untrusted. applications running on it are considered untrusted.
- Service Provider (SP): An entity that wishes to provide a service - Service Provider (SP): An entity that wishes to provide a service
on Devices that requires the use of one or more Trusted on Devices that requires the use of one or more Trusted
Applications. A Service Provider requires the help of a TAM in Applications.
order to provision the Trusted Applications to remote devices.
- Device User: A human being that uses a device. Many devices have - Device User: A human being that uses a device. Many devices have
a single device user. Some devices have a primary device user a single device user. Some devices have a primary device user
with other human beings as secondary device users (e.g., parent with other human beings as secondary device users (e.g., parent
allowing children to use their tablet or laptop). Other devices allowing children to use their tablet or laptop). Other devices
are not used by a human being and hence have no device user. are not used by a human being and hence have no device user.
Relates to Device Owner and Device Administrator. Relates to Device Owner and Device Administrator.
- Device Owner: A device is always owned by someone. In some cases, - Device Owner: A device is always owned by someone. In some cases,
it is common for the (primary) device user to also own the device, it is common for the (primary) device user to also own the device,
skipping to change at page 7, line 27 skipping to change at page 7, line 18
3.1. Payment 3.1. Payment
A payment application in a mobile device requires high security and A payment application in a mobile device requires high security and
trust about the hosting device. Payments initiated from a mobile trust about the hosting device. Payments initiated from a mobile
device can use a Trusted Application to provide strong identification device can use a Trusted Application to provide strong identification
and proof of transaction. and proof of transaction.
For a mobile payment application, some biometric identification For a mobile payment application, some biometric identification
information could also be stored in a TEE. The mobile payment information could also be stored in a TEE. The mobile payment
application can use such information for authentication. application can use such information for unlocking the phone and for
local identification of the user.
A secure user interface (UI) may be used in a mobile device to A trusted user interface (UI) may be used in a mobile device to
prevent malicious software from stealing sensitive user input data. prevent malicious software from stealing sensitive user input data.
Such an application implementation often relies on a TEE for user Such an implementation often relies on a TEE for providing access to
input protection. peripherals, such as PIN input.
3.2. Authentication 3.2. Authentication
For better security of authentication, a device may store its For better security of authentication, a device may store its keys
sensitive authentication keys inside a TEE, providing TEE-protected and cryptographic libraries inside a TEE limiting access to
security key strength and trusted code execution. cryptographic functions via a well-defined interface and thereby
reducing access to keying material.
3.3. Internet of Things 3.3. Internet of Things
The Internet of Things (IoT) has been posing threats to networks and The Internet of Things (IoT) has been posing threats to critical
national infrastructures because of existing weak security in infrastructure because of weak security in devices. It is desirable
devices. It is very desirable that IoT devices can prevent malware that IoT devices can prevent malware from manipulating actuators
from manipulating actuators (e.g., unlocking a door), or stealing or (e.g., unlocking a door), or stealing or modifying sensitive data,
modifying sensitive data such as authentication credentials in the such as authentication credentials in the device. A TEE can be the
device. A TEE can be the best way to implement such IoT security best way to implement such IoT security functions.
functions.
TEEs could be used to store variety of sensitive data for IoT
devices. For example, a TEE could be used in smart door locks to
store a user's biometric information for identification, and for
protecting access the locking mechanism.
3.4. Confidential Cloud Computing 3.4. Confidential Cloud Computing
A tenant can store sensitive data in a TEE in a cloud computing A tenant can store sensitive data in a TEE in a cloud computing
server such that only the tenant can access the data, preventing the server such that only the tenant can access the data, preventing the
cloud hosting provider from accessing the data. A tenant can run TAs cloud hosting provider from accessing the data. A tenant can run TAs
inside a server TEE for secure operation and enhanced data security. inside a server TEE for secure operation and enhanced data security.
This provides benefits not only to tenants with better data security This provides benefits not only to tenants with better data security
but also to cloud hosting provider for reduced liability and but also to cloud hosting provider for reduced liability and
increased cloud adoption. increased cloud adoption.
skipping to change at page 9, line 18 skipping to change at page 9, line 4
performing lifecycle management activity on TA's on behalf of performing lifecycle management activity on TA's on behalf of
Service Providers and Device Administrators. This includes Service Providers and Device Administrators. This includes
creation and deletion of TA's, and may include, for example, over- creation and deletion of TA's, and may include, for example, over-
the-air updates to keep an SP's TAs up-to-date and clean up when a the-air updates to keep an SP's TAs up-to-date and clean up when a
version should be removed. TAMs may provide services that make it version should be removed. TAMs may provide services that make it
easier for SPs or DAs to use the TAM's service to manage multiple easier for SPs or DAs to use the TAM's service to manage multiple
devices, although that is not required of a TAM. devices, although that is not required of a TAM.
The TAM performs its management of TA's through an interaction The TAM performs its management of TA's through an interaction
with a Device's TEEP Broker. As shown in Figure 1, the TAM cannot with a Device's TEEP Broker. As shown in Figure 1, the TAM cannot
directly contact a Device, but must wait for the TEEP Broker to directly contact a TEEP Agent, but must wait for the TEEP Broker
contact the TAM requesting a particular service. This to contact the TAM requesting a particular service. This
architecture is intentional in order to accommodate network and architecture is intentional in order to accommodate network and
application firewalls that normally protect user and enterprise application firewalls that normally protect user and enterprise
devices from arbitrary connections from external network entities. devices from arbitrary connections from external network entities.
A TAM may be publicly available for use by many SPs, or a TAM may A TAM may be publicly available for use by many SPs, or a TAM may
be private, and accessible by only one or a limited number of SPs. be private, and accessible by only one or a limited number of SPs.
It is expected that manufacturers and carriers will run their own It is expected that manufacturers and carriers will run their own
private TAM. Another example of a private TAM is a TAM running as private TAM. Another example of a private TAM is a TAM running as
a Software-as-a-Service (SaaS) within an SP. a Software-as-a-Service (SaaS) within an SP.
skipping to change at page 10, line 40 skipping to change at page 10, line 27
There is nothing prohibiting a device from implementing multiple There is nothing prohibiting a device from implementing multiple
TEEs. In addition, some TEEs (for example, SGX) present themselves TEEs. In addition, some TEEs (for example, SGX) present themselves
as separate containers within memory without a controlling manager as separate containers within memory without a controlling manager
within the TEE. In these cases, the Rich Execution Environment hosts within the TEE. In these cases, the Rich Execution Environment hosts
multiple TEEP brokers, where each Broker manages a particular TEE or multiple TEEP brokers, where each Broker manages a particular TEE or
set of TEEs. Enumeration and access to the appropriate TEEP Broker set of TEEs. Enumeration and access to the appropriate TEEP Broker
is up to the Rich Execution Environment and the Untrusted is up to the Rich Execution Environment and the Untrusted
Applications. Verification that the correct TA has been reached then Applications. Verification that the correct TA has been reached then
becomes a matter of properly verifying TA attestations, which are becomes a matter of properly verifying TA attestations, which are
unforgeable. The multiple TEE approach is shown in the diagram unforgeable. The multiple TEEP Broker approach is shown in the
below. For brevity, TEEP Broker 2 is shown interacting with only one diagram below. For brevity, TEEP Broker 2 is shown interacting with
TAM and UA, but no such limitation is intended to be implied in the only one TAM and UA, but no such limitation is intended to be implied
architecture. in the architecture.
+-------------------------------------------+ +-------------------------------------------+
| Device | | Device |
| +--------+ | Service Provider | +--------+ | Service Provider
| | |----------+ | | | |----------+ |
| +-------------+ | TEEP |---------+| | | +-------------+ | TEEP |---------+| |
| | TEE-1 | +---| Broker | | || +--------+ | | | TEE-1 | +---| Broker | | || +--------+ |
| | | | | 1 |<---+ | |+-->| |<-+ | | | | | 1 |<---+ | |+-->| |<-+
| | +-------+ | | | | | | | | | | | +-------+ | | | | | | | | |
| | | TEEP | | | | | | | | | | | | | TEEP | | | | | | | | | |
skipping to change at page 14, line 7 skipping to change at page 14, line 7
uses one or more TA's in a TEE appears no different from any other uses one or more TA's in a TEE appears no different from any other
Untrusted Application in the REE. However, the way the Untrusted Untrusted Application in the REE. However, the way the Untrusted
Application and its corresponding TA's are packaged, delivered, and Application and its corresponding TA's are packaged, delivered, and
installed on the device can vary. The variations depend on whether installed on the device can vary. The variations depend on whether
the Untrusted Application and TA are bundled together or are provided the Untrusted Application and TA are bundled together or are provided
separately, and this has implications to the management of the TAs in separately, and this has implications to the management of the TAs in
the TEE. In addition to the Untrusted Application and TA, the TA the TEE. In addition to the Untrusted Application and TA, the TA
and/or TEE may require some additional data to personalize the TA to and/or TEE may require some additional data to personalize the TA to
the service provider or the device or a user. This personalization the service provider or the device or a user. This personalization
data is dependent on the TEE, the TA and the SP; an example of data is dependent on the TEE, the TA and the SP; an example of
personalization data might be username and password of an account personalization data might be a secret symmetric key used by the TA
with the SP, or a secret symmetric key used by the TA to communicate to communicate with the SP. The personalization data must be
with the SP. The personalization data must be encrypted to preserve encrypted to preserve the confidentiality of potentially sensitive
the confidentiality of potentially sensitive data contained within data contained within it. Other than this requirement to support
it. Other than this requirement to support confidentiality, TEEP confidentiality, TEEP place no limitations or requirements on the
place no limitations or requirements on the personalization data. personalization data.
There are three possible cases for bundling of the Untrusted There are three possible cases for bundling of the Untrusted
Application, TA, and personalization data: Application, TA, and personalization data:
1. The Untrusted Application, TA, and personalization data are all 1. The Untrusted Application, TA, and personalization data are all
bundled together in a single package by the SP and provided to bundled together in a single package by the SP and provided to
the TEEP Broker through the TAM. the TEEP Broker through the TAM.
2. The Untrusted Application and the TA are bundled together in a 2. The Untrusted Application and the TA are bundled together in a
single package, which a TAM or a publicly accessible app store single package, which a TAM or a publicly accessible app store
skipping to change at page 15, line 33 skipping to change at page 15, line 33
otherwise there is a significant problem in getting the SGX enclave otherwise there is a significant problem in getting the SGX enclave
code (the TA) from the TEE, through the installer and into the code (the TA) from the TEE, through the installer and into the
Untrusted Application in a trusted fashion. Finally, the Untrusted Application in a trusted fashion. Finally, the
personalization data would need to be sent out of the TEE (encrypted personalization data would need to be sent out of the TEE (encrypted
in an SGX encalve-to-enclave manner) to the REE's installation app, in an SGX encalve-to-enclave manner) to the REE's installation app,
which would pass this data to the installed Untrusted Application, which would pass this data to the installed Untrusted Application,
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.
In ARM TrustZone based environments, the Untrusted Application and TA In Arm TrustZone for A- and R-class devices, the Untrusted
may or may not be bundled together. This differs from SGX since in Application and TA may or may not be bundled together. This differs
TrustZone the TA lifetime is not inherently tied to a specific from SGX since in TrustZone the TA lifetime is not inherently tied to
Untrused Application process lifetime as occurs in SGX. A TA is a specific Untrused Application process lifetime as occurs in SGX. A
loaded by a trusted OS running in the TEE, where the trusted OS is TA is loaded by a trusted OS running in the TEE, where the trusted OS
separate from the OS in the REE. Thus Cases 2 and 3 are equally 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 applicable. In addition, it is possible for TAs to communicate with
each other without involving the Untrusted Application, and so the each other without involving the Untrusted Application, and so the
complexity of Case 1 is lower than in the SGX example, and so Case 1 complexity of Case 1 is lower than in the SGX example, and so Case 1
is possible as well though still more complex than Cases 2 and 3. is possible as well though still more complex than Cases 2 and 3.
4.6. Entity Relations 4.6. Entity Relations
This architecture leverages asymmetric cryptography to authenticate a This architecture leverages asymmetric cryptography to authenticate a
device to a TAM. Additionally, a TEE in a device authenticates a TAM device to a TAM. Additionally, a TEE in a device authenticates a TAM
and TA signer. The provisioning of Trust Anchors to a device may be and TA signer. The provisioning of Trust Anchors to a device may be
skipping to change at page 16, line 27 skipping to change at page 16, line 27
Untrusted Application Untrusted Application
TA TA
| |
| |
Untrusted Application -- 2a. --> | ----- 3. Install -------> | Untrusted Application -- 2a. --> | ----- 3. Install -------> |
TA ----------------- 2b. Supply ------> | 4. Messaging-->| TA ----------------- 2b. Supply ------> | 4. Messaging-->|
| | | | | | | |
Figure 3: Developer Experience Figure 3: Developer Experience
Note that Figure 3 shows the app developer as a TA signer and not the
SP. However, the App Developer is either closely associated with the
SP or the SP delegates the signing authority to the app developer.
For the purpose of this document there is no difference between the
SP and the app developer.
Figure 3 shows an application developer building two applications: 1) Figure 3 shows an application developer building two applications: 1)
an Untrusted Application; 2) a TA that provides some security an Untrusted Application; 2) a TA that provides some security
functions to be run inside a TEE. At step 2, the application functions to be run inside a TEE. At step 2, the application
developer uploads the Untrusted Application (2a) to an Application developer uploads the Untrusted Application (2a) to an Application
Store. The Untrusted Application may optionally bundle the TA Store. The Untrusted Application may optionally bundle the TA
binary. Meanwhile, the application developer may provide its TA to a binary. Meanwhile, the application developer may provide its TA to a
TAM provider that will be managing the TA in various devices. 3. A TAM provider that will be managing the TA in various devices. 3. A
user will go to an Application Store to download the Untrusted user will go to an Application Store to download the Untrusted
Application. The Untrusted Application will trigger TA installation Application. The Untrusted Application will trigger TA installation
by initiating communication with a TAM. This is the step 4. The by initiating communication with a TAM. This is the step 4. The
skipping to change at page 17, line 18 skipping to change at page 17, line 25
with different TAMs and different TEEs in different devices. This is with different TAMs and different TEEs in different devices. This is
the role of the Broker, which is a software component that bridges the role of the Broker, which is a software component that bridges
communication between a TAM and a TEE. Furthermore the Broker communication between a TAM and a TEE. Furthermore the Broker
communicates with a Agent inside a TEE that is responsible to process communicates with a Agent inside a TEE that is responsible to process
TAM requests. The Broker in REE does not need to know the actual TAM requests. The Broker in REE does not need to know the actual
content of messages except for the TEE routing information. content of messages except for the TEE routing information.
5. Keys and Certificate Types 5. Keys and Certificate Types
This architecture leverages the following credentials, which allow This architecture leverages the following credentials, which allow
delivering end-to-end security between a TAM and a TEEP Agent, delivering end-to-end security between a TAM and a TEEP Agent.
without relying on any transport security.
Figure 4 summarizes the relationships between various keys and where Figure 4 summarizes the relationships between various keys and where
they are stored. Each public/private key identifies an SP, TAM, or they are stored. Each public/private key identifies an SP, TAM, or
TEE, and gets a certificate that chains up to some CA. A list of TEE, and gets a certificate that chains up to some CA. A list of
trusted certificates is then used to check a presented certificate trusted certificates is then used to check a presented certificate
against. against.
Different CAs can be used for different types of certificates. TEEP Different CAs can be used for different types of certificates. TEEP
messages are always signed, where the signer key is the message messages are always signed, where the signer key is the message
originator's private key such as that of a TAM, or a TEE's private originator's private key such as that of a TAM, or a TEE's private
skipping to change at page 17, line 46 skipping to change at page 18, line 5
Purpose Private Key Signs CA Certs Purpose Private Key Signs CA Certs
------------------ ----------- ------------- ------------- ------------------ ----------- ------------- -------------
Authenticating TEE 1 per TEE TEEP responses TAM Authenticating TEE 1 per TEE TEEP responses TAM
Authenticating TAM 1 per TAM TEEP requests TEEP Agent Authenticating TAM 1 per TAM TEEP requests TEEP Agent
Code Signing 1 per SP TA binary TEE Code Signing 1 per SP TA binary TEE
Figure 4: Keys 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 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 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 TEE manufacturer and the key pair and its certificate are valid for
the expected lifetime of the TEE. A TAM provider is responsible for the expected lifetime of the TEE. A TAM provider is responsible for
configuring its TAM with the manufacturer certificates or CAs that configuring its TAM with the manufacturer certificates or CAs that
are used to sign TEE keys. are used to sign TEE keys.
The TAM key pair and certificate are used for authenticating a TAM to The TAM key pair and certificate are used for authenticating a TAM to
a remote TEE. A TAM provider is responsible for acquiring a a remote TEE. A TAM provider is responsible for acquiring a
certificate from a CA that is trusted by the TEEs it manages. certificate from a CA that is trusted by the TEEs it manages.
skipping to change at page 23, line 34 skipping to change at page 23, line 45
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. These additional claims may help clear up authorize a device or TEE. These additional claims may help clear up
any assumptions for which the TAM wants to alleviate. The specific any assumptions for which the TAM wants to alleviate. The specific
format for these additional claims are outside the scope of this format for these additional claims are outside the scope of this
specification, but the TEEP protocol allows these additional claims specification, but the TEEP protocol allows these additional claims
to be included in the attestation messages. to be included in the attestation messages.
7.1. Information Required in TEEP Claims 7.1. Information Required in TEEP Claims
- Device Identifying Info: TEEP attestations must uniquely identify - Device Identifying Info: TEEP attestations may need to uniquely
a device to the TAM and SP. This identifier allows the TAM to identify a device to the TAM and SP. Unique device identification
provide services unique to the device, such as managing installed allows the TAM to provide services to the device, such as managing
TAs, and providing subscriptions to services, and locating device- installed TAs, and providing subscriptions to services, and
specific keying material to communicate with or authenticate the locating device-specific keying material to communicate with or
device. Additionally, device manufacturer information must be authenticate the device. In some use cases it may be sufficient
provided to provide better universal uniqueness qualities without to identify only the class of the device. The security and
requiring globally unique identifiers for all devices. 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 info: The type of TEE that generated this
attestation must be identified. Standard TEE types are identified attestation must be identified. Standard TEE types are identified
by an IANA number, but also must include version identification by an IANA number, but also must include 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 resolve same TEE type created by different manufacturers and resolve
potential assumptions around manufacturer provisioning, keying and potential assumptions around manufacturer provisioning, keying and
support for the TEE. support for the TEE.
skipping to change at page 26, line 36 skipping to change at page 27, line 9
dependency in the manifest of the encrypted TA. Thus, the TEEP Agent dependency in the manifest of the encrypted TA. Thus, the TEEP Agent
would look at the TA manifest, determine there is a dependency with a would look at the TA manifest, determine there is a dependency with a
TAM URI of the SP's TAM. The Agent would then install the TAM URI of the SP's TAM. The Agent would then install the
dependency, and then continue with the TA installation steps, dependency, and then continue with the TA installation steps,
including decrypting the TA binary with the relevant key. including decrypting the TA binary with the relevant key.
10. IANA Considerations 10. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
11. Acknowledgements 11. Contributors
Some content of this document is based on text in a previous OTrP - Andrew Atyeo
protocol document [I-D.ietf-teep-opentrustprotocol]. We thank the
former co-authors Nick Cook and Minho Yoo for the initial document
content, and contributors Brian Witten, Tyler Kim, and Alin Mutu.
12. Informative References - Intercede
- andrew.atyeo@intercede.com
- Liu Dapeng
- Alibaba Group
- maxpassion@gmail.com
12. Acknowledgements
We would like to thank Nick Cook, Minho Yoo, Brian Witten, Tyler Kim,
Alin Mutu, Juergen Schoenwaelder, Nicolae Paladi, Sorin Faibish, Ned
Smith, Russ Housley, Jeremy O'Donoghue, and Anders Rundgren for their
feedback.
13. Informative References
[GPTEE] Global Platform, "GlobalPlatform Device Technology: TEE [GPTEE] Global Platform, "GlobalPlatform Device Technology: TEE
System Architecture, v1.1", Global Platform GPD_SPE_009, System Architecture, v1.1", Global Platform GPD_SPE_009,
January 2017, <https://globalplatform.org/specs-library/ January 2017, <https://globalplatform.org/specs-library/
tee-system-architecture-v1-1/>. tee-system-architecture-v1-1/>.
[I-D.ietf-suit-manifest] [I-D.ietf-suit-manifest]
Moran, B., Tschofenig, H., and H. Birkholz, "A Concise Moran, B., Tschofenig, H., and H. Birkholz, "A Concise
Binary Object Representation (CBOR)-based Serialization Binary Object Representation (CBOR)-based Serialization
Format for the Software Updates for Internet of Things Format for the Software Updates for Internet of Things
(SUIT) Manifest", draft-ietf-suit-manifest-02 (work in (SUIT) Manifest", draft-ietf-suit-manifest-02 (work in
progress), November 2019. progress), November 2019.
[I-D.ietf-teep-opentrustprotocol]
Pei, M., Atyeo, A., Cook, N., Yoo, M., and H. Tschofenig,
"The Open Trust Protocol (OTrP)", draft-ietf-teep-
opentrustprotocol-03 (work in progress), May 2019.
[I-D.ietf-teep-otrp-over-http] [I-D.ietf-teep-otrp-over-http]
Thaler, D., "HTTP Transport for Trusted Execution Thaler, D., "HTTP Transport for Trusted Execution
Environment Provisioning: Agent-to- TAM Communication", Environment Provisioning: Agent-to- TAM Communication",
draft-ietf-teep-otrp-over-http-03 (work in progress), draft-ietf-teep-otrp-over-http-03 (work in progress),
November 2019. November 2019.
[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management
Requirements", RFC 6024, DOI 10.17487/RFC6024, October Requirements", RFC 6024, DOI 10.17487/RFC6024, October
2010, <https://www.rfc-editor.org/info/rfc6024>. 2010, <https://www.rfc-editor.org/info/rfc6024>.
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting Mandatory-to-Implement Algorithms", Agility and Selecting Mandatory-to-Implement Algorithms",
BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
<https://www.rfc-editor.org/info/rfc7696>. <https://www.rfc-editor.org/info/rfc7696>.
Appendix A. History
RFC EDITOR: PLEASE REMOVE THIS SECTION
IETF Drafts
draft-00: - Initial working group document
Authors' Addresses Authors' Addresses
Mingliang Pei Mingliang Pei
Symantec Symantec
EMail: mingliang_pei@symantec.com EMail: mingliang_pei@symantec.com
Hannes Tschofenig Hannes Tschofenig
Arm Limited Arm Limited
EMail: hannes.tschofenig@arm.com EMail: hannes.tschofenig@arm.com
Dave Thaler
Microsoft
EMail: dthaler@microsoft.com
David Wheeler David Wheeler
Intel Intel
EMail: david.m.wheeler@intel.com EMail: david.m.wheeler@intel.com
Andrew Atyeo
Intercede
EMail: andrew.atyeo@intercede.com
Liu Dapeng
Alibaba Group
EMail: maxpassion@gmail.com
 End of changes. 35 change blocks. 
97 lines changed or deleted 107 lines changed or added

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