< draft-ietf-teep-architecture-02.txt   draft-ietf-teep-architecture-03.txt >
TEEP M. Pei TEEP M. Pei
Internet-Draft Symantec Internet-Draft Symantec
Intended status: Informational H. Tschofenig Intended status: Informational H. Tschofenig
Expires: September 12, 2019 Arm Limited Expires: January 9, 2020 Arm Limited
D. Wheeler D. Wheeler
Intel Intel
A. Atyeo A. Atyeo
Intercede Intercede
L. Dapeng L. Dapeng
Alibaba Group Alibaba Group
March 11, 2019 July 08, 2019
Trusted Execution Environment Provisioning (TEEP) Architecture Trusted Execution Environment Provisioning (TEEP) Architecture
draft-ietf-teep-architecture-02 draft-ietf-teep-architecture-03
Abstract Abstract
A Trusted Execution Environment (TEE) is designed to provide a A Trusted Execution Environment (TEE) is designed to provide a
hardware-isolation mechanism to separate a regular operating system hardware-isolation mechanism to separate a regular operating system
from security-sensitive application components. from security-sensitive application components.
This architecture document motivates the design and standardization This architecture document motivates the design and standardization
of a protocol for managing the lifecycle of trusted applications of a protocol for managing the lifecycle of trusted applications
running inside a TEE. running inside a TEE.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 September 12, 2019. This Internet-Draft will expire on January 9, 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Authentication . . . . . . . . . . . . . . . . . . . . . 9 4.2. Authentication . . . . . . . . . . . . . . . . . . . . . 9
4.3. Internet of Things . . . . . . . . . . . . . . . . . . . 9 4.3. Internet of Things . . . . . . . . . . . . . . . . . . . 9
4.4. Confidential Cloud Computing . . . . . . . . . . . . . . 9 4.4. Confidential Cloud Computing . . . . . . . . . . . . . . 9
5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. System Components . . . . . . . . . . . . . . . . . . . . 9 5.1. System Components . . . . . . . . . . . . . . . . . . . . 9
5.2. Different Renditions of TEEP Architecture . . . . . . . . 12 5.2. Different Renditions of TEEP Architecture . . . . . . . . 12
5.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 13 5.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 14
5.4. Client Apps, Trusted Apps, and Personalization Data . . . 15 5.4. Client Apps, Trusted Apps, and Personalization Data . . . 15
5.5. Examples of Application Delivery Mechanisms in Existing 5.5. Examples of Application Delivery Mechanisms in Existing
TEEs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 TEEs . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.6. TEEP Architectural Support for Client App, TA, and 5.6. TEEP Architectural Support for Client App, TA, and
Personalization Data Delivery . . . . . . . . . . . . . . 17 Personalization Data Delivery . . . . . . . . . . . . . . 17
5.7. Entity Relations . . . . . . . . . . . . . . . . . . . . 17 5.7. Entity Relations . . . . . . . . . . . . . . . . . . . . 17
5.8. Trust Anchors in TEE . . . . . . . . . . . . . . . . . . 20 5.8. Trust Anchors in TEE . . . . . . . . . . . . . . . . . . 20
5.9. Trust Anchors in TAM . . . . . . . . . . . . . . . . . . 20 5.9. Trust Anchors in TAM . . . . . . . . . . . . . . . . . . 20
5.10. Keys and Certificate Types . . . . . . . . . . . . . . . 20 5.10. Keys and Certificate Types . . . . . . . . . . . . . . . 21
5.11. Scalability . . . . . . . . . . . . . . . . . . . . . . . 23 5.11. Scalability . . . . . . . . . . . . . . . . . . . . . . . 23
5.12. Message Security . . . . . . . . . . . . . . . . . . . . 23 5.12. Message Security . . . . . . . . . . . . . . . . . . . . 23
5.13. Security Domain Hierarchy and Ownership . . . . . . . . . 23 5.13. Security Domain . . . . . . . . . . . . . . . . . . . . . 23
5.14. SD Owner Identification and TAM Certificate Requirements 24 5.14. A Sample Device Setup Flow . . . . . . . . . . . . . . . 23
5.15. Service Provider Container . . . . . . . . . . . . . . . 25 6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.16. A Sample Device Setup Flow . . . . . . . . . . . . . . . 25 6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 25
6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.2. TEEP Broker Implementation Consideration . . . . . . . . 25
6.1. Role of the Agent . . . . . . . . . . . . . . . . . . . . 27 6.2.1. TEEP Broker Distribution . . . . . . . . . . . . . . 26
6.2. Agent Implementation Consideration . . . . . . . . . . . 27 6.2.2. Number of TEEP Brokers . . . . . . . . . . . . . . . 26
6.2.1. Agent Distribution . . . . . . . . . . . . . . . . . 27 7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2.2. Number of Agents . . . . . . . . . . . . . . . . . . 27 7.1. Attestation Cryptographic Properties . . . . . . . . . . 28
7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.2. TEEP Attestation Structure . . . . . . . . . . . . . . . 29
7.1. Attestation Cryptographic Properties . . . . . . . . . . 30 7.3. TEEP Attestation Claims . . . . . . . . . . . . . . . . . 31
7.2. TEEP Attestation Structure . . . . . . . . . . . . . . . 31 7.4. TEEP Attestation Flow . . . . . . . . . . . . . . . . . . 31
7.3. TEEP Attestation Claims . . . . . . . . . . . . . . . . . 32 7.5. Attestation Key Example . . . . . . . . . . . . . . . . . 31
7.4. TEEP Attestation Flow . . . . . . . . . . . . . . . . . . 33 7.5.1. Attestation Hierarchy Establishment: Manufacture . . 32
7.5. Attestation Key Example . . . . . . . . . . . . . . . . . 33 7.5.2. Attestation Hierarchy Establishment: Device Boot . . 32
7.5.1. Attestation Hierarchy Establishment: Manufacture . . 33 7.5.3. Attestation Hierarchy Establishment: TAM . . . . . . 32
7.5.2. Attestation Hierarchy Establishment: Device Boot . . 34 8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 32
7.5.3. Attestation Hierarchy Establishment: TAM . . . . . . 34 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33
8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 34 9.1. TA Trust Check at TEE . . . . . . . . . . . . . . . . . . 33
9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 9.2. One TA Multiple SP Case . . . . . . . . . . . . . . . . . 33
9.1. TA Trust Check at TEE . . . . . . . . . . . . . . . . . . 35 9.3. Broker Trust Model . . . . . . . . . . . . . . . . . . . 34
9.2. One TA Multiple SP Case . . . . . . . . . . . . . . . . . 35 9.4. Data Protection at TAM and TEE . . . . . . . . . . . . . 34
9.3. Agent Trust Model . . . . . . . . . . . . . . . . . . . . 35 9.5. Compromised CA . . . . . . . . . . . . . . . . . . . . . 34
9.4. Data Protection at TAM and TEE . . . . . . . . . . . . . 36 9.6. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 34
9.5. Compromised CA . . . . . . . . . . . . . . . . . . . . . 36 9.7. Certificate Renewal . . . . . . . . . . . . . . . . . . . 34
9.6. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 36 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
9.7. Certificate Renewal . . . . . . . . . . . . . . . . . . . 36 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 12.1. Normative References . . . . . . . . . . . . . . . . . . 35
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 12.2. Informative References . . . . . . . . . . . . . . . . . 35
12.1. Normative References . . . . . . . . . . . . . . . . . . 37 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 37
12.2. Informative References . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
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
complexity of features and applications on devices, and the complexity of features and applications on devices, and the
skipping to change at page 5, line 9 skipping to change at page 5, line 9
device 'root of trust' and the type of TEE included in a device. device 'root of trust' and the type of TEE included in a device.
- 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 - The parties involved in the protocol must be able to attest that a
TEE is genuine and capable of providing the security protections TEE is genuine and capable of providing the security protections
required by a particular TA. required by a particular TA.
- A Service Provider (SP) must be able to deterine 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 recinded. 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.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
skipping to change at page 10, line 8 skipping to change at page 10, line 8
5.1. System Components 5.1. System Components
The following are the main components in the system. Full The following are the main components in the system. Full
descriptions of components not previously defined are provided below. descriptions of components not previously defined are provided below.
Interactions of all components are further explained in the following Interactions of all components are further explained in the following
paragraphs. paragraphs.
+-------------------------------------------+ +-------------------------------------------+
| Device | | Device |
| +--------+ | Service Provider | +--------+ | Service Provider
| | |----------+ | | +-------------+ | |----------+ |
| +-------------+ | TEEP |---------+| | | | TEE-1 | | TEEP |---------+| |
| | TEE-1 |<------| Broker | | || +--------+ | | | +--------+ | +----| Broker | | || +--------+ |
| | | | |<---+ | |+-->| |<-+ | | | TEEP | | | | |<---+ | |+-->| |<-+
| | | | | | | | +-| TAM-1 | | | | Agent |<----+ | | | | | +-| TAM-1 |
| | | | |<-+ | | +->| | |<-+ | | +--------+ | | |<-+ | | +->| | |<-+
| | +---+ +---+ | +--------+ | | | | +--------+ | | | | +--------+ | | | | +--------+ |
| | |TA1| |TA2| | | | | | TAM-2 | | | | +---+ +---+ | | | | | TAM-2 | |
| +-->| | | | | +-------+ | | | +--------+ | | +-->|TA1| |TA2| | +-------+ | | | +--------+ |
| | | | | | |<---------| App-2 |--+ | | | | | | | | | |<---------| App-2 |--+ | | |
| | | +---+ +---+ | +-------+ | | | Device Administrator | | | +---+ +---+ | +-------+ | | | Device Administrator
| | +-------------+ | App-1 | | | | | | +-------------+ | App-1 | | | |
| | | | | | | | | | | | | |
| +--------------------| |---+ | | | +--------------------| |---+ | |
| | |--------+ | | | |--------+ |
| +-------+ | | +-------+ |
+-------------------------------------------+ +-------------------------------------------+
Figure 1: Notional Architecture of TEEP Figure 1: Notional Architecture of TEEP
- Service Providers (SP) and Device Administrators (DA) utilize the - Service Providers (SP) and Device Administrators (DA) utilize the
services of a TAM to manage TAs on Devices. SPs do not directly services of a TAM to manage TAs on Devices. SPs do not directly
interact with devices. DAs may elect to use a TAM for remote interact with devices. DAs may elect to use a TAM for remote
administration of TAs instead of managing each device directly. administration of TAs instead of managing each device directly.
- TAM: A TAM is responsible for performing lifecycle management - TAM: A TAM is responsible for performing lifecycle management
activity on TA's and SD's on behalf of Service Providers and activity on TA's on behalf of Service Providers and Device
Device Administrators. This includes creation and deletion of Administrators. This includes creation and deletion of TA's, and
TA's and SD's, and may include, for example, over-the-air updates may include, for example, over-the-air updates to keep an SP's TAs
to keep an SP's TAs up-to-date and clean up when a version should up-to-date and clean up when a version should be removed. TAMs
be removed. TAMs may provide services that make it easier for SPs may provide services that make it easier for SPs or DAs to use the
or DAs to use the TAM's service to manage multiple devices, TAM's service to manage multiple devices, although that is not
although that is not required of a TAM. required of a TAM.
The TAM performs its management of TA's and SD's through an The TAM performs its management of TA's through an interaction
interaction with a Device's TEEP Broker. As shown in with a Device's TEEP Broker. As shown in #notionalarch, the TAM
#notionalarch, the TAM cannot directly contact a Device, but must cannot directly contact a Device, but must wait for a the TEEP
wait for a the TEEP Broker or a Client Application to contact the Broker or a Client Application to contact the TAM requesting a
TAM requesting a particular service. This architecture is particular service. This architecture is intentional in order to
intentional in order to accommodate network and application accommodate network and application firewalls that normally
firewalls that normally protect user and enterprise devices from protect user and enterprise devices from arbitrary connections
arbitrary connections from external network entities. 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.
A SP or Device Administrator chooses a particular TAM based on A SP or Device Administrator chooses a particular TAM based on
whether the TAM is trusted by a Device or set of Devices. The TAM whether the TAM is trusted by a Device or set of Devices. The TAM
skipping to change at page 11, line 33 skipping to change at page 11, line 33
Any entity is free to operate a TAM. For a TAM to be successful, Any entity is free to operate a TAM. For a TAM to be successful,
it must have its public key or certificate installed in Devices it must have its public key or certificate installed in Devices
Trust Anchor list. A TAM may set up a relationship with device Trust Anchor list. A TAM may set up a relationship with device
manufacturers or carriers to have them install the TAM's keys in manufacturers or carriers to have them install the TAM's keys in
their device's Trust Anchor list. Alternatively, a TAM may their device's Trust Anchor list. Alternatively, a TAM may
publish its certificate and allow Device Administrators to install publish its certificate and allow Device Administrators to install
the TAM's certificate in their devices as an after-market-action. the TAM's certificate in their devices as an after-market-action.
- TEEP Broker: The TEEP Broker is an application running in a Rich - TEEP Broker: The TEEP Broker is an application running in a Rich
Execution Environment that enables the message protocol exchange Execution Environment (REE) that enables the message protocol
between a TAM and a TEE in a device. The TEEP Broker does not exchange between a TAM and a TEE in a device. The TEEP Broker
process messages on behalf of a TEE, but merely is responsible for does not process messages on behalf of a TEE, but merely is
relaying messages from the TAM to the TEE, and for returning the responsible for relaying messages from the TAM to the TEE, and for
TEE's responses to the TAM. returning the TEE's responses to the TAM.
A Client Application is expected to communicate with a TAM to A Client Application is expected to communicate with a TAM to
request TAs that it needs to use. The Client Application needs to request TAs that it needs to use. The Client Application needs to
pass the messages from the TAM to TEEs in the device. This calls pass the messages from the TAM to TEEs in the device. This calls
for a component in the REE that Client Applications can use to for a component in the REE that Client Applications can use to
pass messages to TEEs. An Agent is thus an application in the REE pass messages to TEEs. The TEEP Broker is thus an application in
or software library that can relay messages from a Client the REE or software library that can relay messages from a Client
Application to a TEE in the device. A device usually comes with Application to a TEE in the device. A device usually comes with
only one active TEE. A TEE may provide such an Agent to the only one active TEE. A TEE may provide such a Broker to the
device manufacturer to be bundled in devices. Such a TEE must device manufacturer to be bundled in devices. Such a TEE must
also include an Agent counterpart, namely, a processing module also include a Broker counterpart, namely, a TEEP Agent inside the
inside the TEE, to parse TAM messages sent through the Agent. An TEE, to parse TAM messages sent through the Broker. A TEEP Broker
Agent is generally acting as a dummy relaying box with just the is generally acting as a dummy relaying box with just the TEE
TEE interacting capability; it doesn't need and shouldn't parse interacting capability; it doesn't need and shouldn't parse
protocol messages. protocol messages.
- TEEP Agent: the TEEP Agent is a processing module running inside a
TEE that receives TAM requests that are 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 by a TEEP Agent back to a
TEEP Broker.
- Certification Authority (CA): Certificate-based credentials used - Certification Authority (CA): Certificate-based credentials used
for authenticating a device, a TAM and an SP. A device embeds a for authenticating a device, a TAM and an SP. A device embeds a
list of root certificates (Trust Anchors), from trusted CAs that a list of root certificates (Trust Anchors), from trusted CAs that a
TAM will be validated against. A TAM will remotely attest a TAM will be validated against. A TAM will remotely attest a
device by checking whether a device comes with a certificate from device by checking whether a device comes with a certificate from
a CA that the TAM trusts. The CAs do not need to be the same; a CA that the TAM trusts. The CAs do not need to be the same;
different CAs can be chosen by each TAM, and different device CAs different CAs can be chosen by each TAM, and different device CAs
can be used by different device manufacturers. can be used by different device manufacturers.
5.2. Different Renditions of TEEP Architecture 5.2. Different Renditions of TEEP Architecture
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 operating system hosts within the TEE. In these cases, the rich operating system 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 broker is up set of TEEs. Enumeration and access to the appropriate broker is up
to the rich OS and the applications. Verification that the correct to the rich OS and the applications. Verification that the correct
TA has been reached then becomes a matter of properly verifying TA TA has been reached then becomes a matter of properly verifying TA
attestations, which are unforgeable. The multiple TEE approach is attestations, which are unforgeable. The multiple TEE approach is
shown in the diagram below. For brevity, TEEP Broker 2 is shown shown in the diagram below. For brevity, TEEP Broker 2 is shown
interacting with only one TAM and UA, but no such limitation is interacting with only one TAM and UA, but no such limitation is
intended to be implied in the architecture. intended to be implied in the architecture.
+-------------------------------------------+ +-------------------------------------------+
| Device | | Device |
| +--------+ | Service Provider | +--------+ | Service Provider
| | |----------+ | | | |----------+ |
| +-------------+ | TEEP |---------+| | | +-------------+ | TEEP |---------+| |
| | TEE-1 |<------| Broker | | || +--------+ | | | TEE-1 | +---| Broker | | || +--------+ |
| | | | 1 |<---+ | |+-->| |<-+ | | | | | 1 |<---+ | |+-->| |<-+
| | +-------+ | | | | | | | | |
| | | TEEP | | | | | | | | | |
| | | Agent |<------+ | | | | | | |
| | | 1 | | | | | | | | |
| | +-------+ | | | | | | | |
| | | | | | | | | |
| | +---+ +---+ | | | | | | +-| TAM-1 | | | +---+ +---+ | | | | | | +-| TAM-1 |
| | |TA1| |TA2| | | |<-+ | | +->| | |<-+ | | |TA1| |TA2| | | |<-+ | | +->| | |<-+
| +-->| | | |<---+ +--------+ | | | | +--------+ | | +-->| | | |<---+ +--------+ | | | | +--------+ |
| | | +---+ +---+ | | | | | | TAM-2 | | | | | +---+ +---+ | | | | | | TAM-2 | |
| | | | | +-------+ | | | +--------+ | | | | | | +-------+ | | | +--------+ |
| | +-------------+ +-----| App-2 |--+ | | ^ | | | +-------------+ +-----| App-2 |--+ | | ^ |
| | +-------+ | | | | Device | | +-------+ | | | | Device
| +--------------------| App-1 | | | | | Administrator | +--------------------| App-1 | | | | | Administrator
| +------| | | | | | | +------| | | | | |
| +-----------|-+ | |---+ | | | | +-----------|-+ | |---+ | | |
| | TEE-2 | | | |--------+ | | | | TEE-2 | | | |--------+ | |
| | | | | |------+ | | | | +------+ | | | |------+ | |
| | +---+ | | +-------+ | | | | | | TEEP | | | +-------+ | | |
| | |TA3|<----+ | +----------+ | | | | | | Agent|<-----+ | | |
| | | | | | TEEP |<--+ | | | | | 2 | | | | | | |
| | +---+ |<---| Broker |----------------+ | | +------+ | | | | | |
| | | | | | | |
| | +---+ | | | | | |
| | |TA3|<----+ | | +----------+ | | |
| | | | | | | TEEP |<--+ | |
| | +---+ | +--| Broker |----------------+
| | | | 2 | | | | | | 2 | |
| | | | | |
| +-------------+ +----------+ | | +-------------+ +----------+ |
| | | |
+-------------------------------------------+ +-------------------------------------------+
Figure 2: Notional Architecture of TEEP wtih multiple TEEs Figure 2: Notional Architecture of TEEP wtih multiple TEEs
In the diagram above, TEEP Broker 1 controls interactions with the In the diagram above, TEEP Broker 1 controls interactions with the
TA's in TEE-1, and TEEP Broker 2 controls interactions with the TA's TA's in TEE-1, and TEEP Broker 2 controls interactions with the TA's
in TEE-2. This presents some challenges for a TAM in completely in TEE-2. This presents some challenges for a TAM in completely
managing the device, since a TAM may not interact with all the TEEP managing the device, since a TAM may not interact with all the TEEP
skipping to change at page 14, line 36 skipping to change at page 14, line 46
situations, an SP may use only a single TAM - this is likely the case situations, an SP may use only a single TAM - this is likely the case
for enterprise applications or SPs serving a closed community. For for enterprise applications or SPs serving a closed community. For
broad public apps, there will likely be multiple TAMs in the manifest broad public apps, there will likely be multiple TAMs in the manifest
- one servicing one brand of mobile device and another servicing a - one servicing one brand of mobile device and another servicing a
different manufacturer, etc. Because different devices and different different manufacturer, etc. Because different devices and different
manufacturers trust different TAMs, the manifest will include manufacturers trust different TAMs, the manifest will include
different TAMs that support this SP's client app and TA. Multiple different TAMs that support this SP's client app and TA. Multiple
TAMs allow the SP to provide thier service and this app (and TA) to TAMs allow the SP to provide thier service and this app (and TA) to
multiple different devices. multiple different devices.
When the TEEP Broker recieves a request to contact the TAM for a When the TEEP Broker receives a request to contact the TAM for a
Client App in order to install a TA, a list of TAMs may be provided. Client App in order to install a TA, a list of TAMs may be provided.
The TEEP Broker selects a single TAM that is consistent with the list The TEEP Broker selects a single TAM that is consistent with the list
of trusted TAMs (trust anchors) provisioned on the device. For any of trusted TAMs (trust anchors) provisioned on the device. For any
client app, there should be only a single TAM for the TEEP Broker to client app, there should be only a single TAM for the TEEP Broker to
contact. This is also the case when a Client App uses multiple TAs, contact. This is also the case when a Client App uses multiple TAs,
or when one TA depends on anther TA in a software dependency (see or when one TA depends on anther TA in a software dependency (see
section TBD). The reason is that the SP should provide each TAM that section TBD). The reason is that the SP should provide each TAM that
it places in the Client App's manifest all the TAs that the app it places in the Client App's manifest all the TAs that the app
requires. There is no benefit to going to multiple different TAMs, requires. There is no benefit to going to multiple different TAMs,
and there is no need for a special TAM to be contacted for a specific and there is no need for a special TAM to be contacted for a specific
skipping to change at page 15, line 39 skipping to change at page 15, line 49
user. This personalization data is dependent on the TEE, the TA and user. This personalization data is dependent on the TEE, the TA and
the SP; an example of personalization data might be username and the SP; an example of personalization data might be username and
password of the device user's account with the SP, or a secret password of the device user's account with the SP, or a secret
symmetric key used to by the TA to communicate with the SP. The symmetric key used to by the TA to communicate with the SP. The
personalization data must be encrypted to preserve the personalization data must be encrypted to preserve the
confidentiality of potentially sensitive data contained within it. confidentiality of potentially sensitive data contained within it.
Other than this requirement to support confidentiality, TEEP place no Other than this requirement to support confidentiality, TEEP place no
limitations or requirements on the personalization data. limitations or requirements on the personalization data.
There are three possible cases for bundling of the Client App, TA, There are three possible cases for bundling of the Client App, TA,
and personalizaiton data: and personalization data:
1. The Client App, TA, and personnalization data are all bundled 1. The Client App, TA, and personalization data are all bundled
together in a single package by the SP and provided to the TEEP together in a single package by the SP and provided to the TEEP
Broker through the TAM. Broker through the TAM.
2. The Client App and the TA are bundled together in a single 2. The Client App and the TA are bundled together in a single
binary, which the TAM or a publicly accessible app store binary, which the TAM or a publicly accessible app store
maintains in repository, and the personalization data is maintains in repository, and the personalization data is
separately provided by the SP. In this case, the personalization separately provided by the SP. In this case, the personalization
data is collected by the TAM and included in the InstallTA data is collected by the TAM and included in the InstallTA
message to the TEEP Broker. message to the TEEP Broker.
skipping to change at page 17, line 15 skipping to change at page 17, line 24
5.6. TEEP Architectural Support for Client App, TA, and Personalization 5.6. TEEP Architectural Support for Client App, TA, and Personalization
Data Delivery Data Delivery
This section defines TEEP support for the three different cases for This section defines TEEP support for the three different cases for
delivery of the Client App, TA, and personalization data. delivery of the Client App, TA, and personalization data.
[Note: discussion of format of this single binary, and who/what is [Note: discussion of format of this single binary, and who/what is
responsible for splitting these things apart, and installing the responsible for splitting these things apart, and installing the
client app into the REE, the TA into the TEE, and the personalization client app into the REE, the TA into the TEE, and the personalization
data into the TEE or TA. Obviously the decryption must be done by data into the TEE or TA. Obviously the decryption must be done by
the TEE but this may not be suported by all TAs.] the TEE but this may not be supported by all TAs.]
5.7. Entity Relations 5.7. 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 and TA signer. The provisioning of Trust Anchors to a device may
different from one use case to the other. A device administrator may different from one use case to the other. A device administrator may
want to have the capability to control what TAs are allowed. A want to have the capability to control what TAs are allowed. A
device manufacturer enables verification of the TA signers and TAM device manufacturer enables verification of the TA signers and TAM
providers; it may embed a list of default Trust Anchors that the providers; it may embed a list of default Trust Anchors that the
skipping to change at page 19, line 12 skipping to change at page 19, line 12
The following diagram shows a system diagram about the entity The following diagram shows a system diagram about the entity
relationships between CAs, TAMs, SPs and devices. relationships between CAs, TAMs, SPs and devices.
------- Message Protocol ----- ------- Message Protocol -----
| | | |
| | | |
-------------------- --------------- ---------- -------------------- --------------- ----------
| REE | TEE | | TAM | | SP | | REE | TEE | | TAM | | SP |
| --- | --- | | --- | | -- | | --- | --- | | --- | | -- |
| | | | | | | | | | | | | |
| Client | SD (TAs)| | SD / TA | | TA | | Client | TEEP | | TA | | TA |
| Apps | | | Mgmt | | | | Apps | Agent | | Mgmt | | |
| | | | | | | | | | | | | | | |
| | | List of | | List of | | | | | | TAs | | | | |
| TEEP | | | | | |
| Broker | List of | | List of | | |
| | Trusted | | Trusted | | | | | Trusted | | Trusted | | |
| Agent | TAM/SP | | FW/TEE | | | | | TAM/SP | | FW/TEE | | |
| | CAs | | CAs | | | | | CAs | | CAs | | |
| | | | | | | | | | | | | |
| |TEE Key/ | | TAM Key/ | |SP Key/ | | |TEE Key/ | | TAM Key/ | |SP Key/ |
| | Cert | | Cert | | Cert | | | Cert | | Cert | | Cert |
| | FW Key/ | | | | | | | FW Key/ | | | | |
| | Cert | | | | | | | Cert | | | | |
-------------------- --------------- ---------- -------------------- --------------- ----------
| | | | | |
| | | | | |
------------- ---------- --------- ------------- ---------- ---------
skipping to change at page 19, line 39 skipping to change at page 19, line 41
------------- ---------- --------- ------------- ---------- ---------
Figure 5: Keys Figure 5: Keys
In the previous diagram, different CAs can be used for different In the previous diagram, different CAs can be used for different
types of certificates. Messages are always signed, where the signer types of certificates. Messages are always signed, where the signer
key is the message originator's private key such as that of a TAM, key is the message originator's private key such as that of a TAM,
the private key of trusted firmware (TFW), or a TEE's private key. the private key of trusted firmware (TFW), or a TEE's private key.
The main components consist of a set of standard messages created by The main components consist of a set of standard messages created by
a TAM to deliver device SD and TA management commands to a device, a TAM to deliver TA management commands to a device, and device
and device attestation and response messages created by a TEE that attestation and response messages created by a TEE that responds to a
responds to a TAM's message. TAM's message.
It should be noted that network communication capability is generally It should be noted that network communication capability is generally
not available in TAs in today's TEE-powered devices. The networking not available in TAs in today's TEE-powered devices. The networking
functionality must be delegated to a rich Client Application. Client functionality must be delegated to a rich Client Application. Client
Applications will need to rely on an agent in the REE to interact Applications will need to rely on an agent in the REE to interact
with a TEE for message exchanges. Consequently, a TAM generally with a TEE for message exchanges. Consequently, a TAM generally
communicates with a Client Application about how it gets messages communicates with a Client Application about how it gets messages
that originate from a TEE inside a device. Similarly, a TA or TEE that originate from a TEE inside a device. Similarly, a TA or TEE
generally gets messages from a TAM via some Client Application, generally gets messages from a TAM via some Client Application,
namely, an agent in this protocol architecture, not directly from the namely, a TEEP Broker in this protocol architecture, not directly
network. from the network.
It is imperative to have an interoperable protocol to communicate It is imperative to have an interoperable protocol to communicate
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 agent, 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. The agent does not need to communication between a TAM and a TEE. Furthermore the Broker
know the actual content of messages except for the TEE routing communicates with a Agent inside a TEE that is responsible to process
information. TAM requests. The Broker in REE does not need to know the actual
content of messages except for the TEE routing information.
5.8. Trust Anchors in TEE 5.8. Trust Anchors in TEE
Each TEE comes with a trust store that contains a whitelist of Trust Each TEE comes with a trust store that contains a whitelist of Trust
Anchors that are used to validate a TAM's certificate. A TEE will Anchors that are used to validate a TAM's certificate. A TEE will
accept a TAM to create new Security Domains and install new TAs on accept a TAM to create new Security Domains and install new TAs on
behalf of an SP only if the TAM's certificate is chained to one of behalf of an SP only if the TAM's certificate is chained to one of
the root CA certificates in the TEE's trust store. the root CA certificates in the TEE's trust store.
A TEE's trust store is typically preloaded at manufacturing time. It A TEE's trust store is typically preloaded at manufacturing time. It
skipping to change at page 21, line 30 skipping to change at page 21, line 36
| certificate | | a root | embedded in TEE | can be used | | certificate | | a root | embedded in TEE | can be used |
| | | CA | | by a TAM | | | | CA | | by a TAM |
| | | | | | | | | | | |
| 4. SP key | SP | SP | A SP uses a TAM. | 1 or | | 4. SP key | SP | SP | A SP uses a TAM. | 1 or |
| pair and | | signer | TA is signed by a | multiple | | pair and | | signer | TA is signed by a | multiple |
| certificate | | CA | SP signer. TEE | can be used | | certificate | | CA | SP signer. TEE | can be used |
| | | | delegates trust | by a TAM | | | | | delegates trust | by a TAM |
| | | | of TA to TAM. SP | | | | | | of TA to TAM. SP | |
| | | | signer is | | | | | | signer is | |
| | | | associated with a | | | | | | associated with a | |
| | | | SD as the owner. | | | | | | TA as the owner. | |
+-------------+----------+--------+-------------------+-------------+ +-------------+----------+--------+-------------------+-------------+
Figure 6: Key and Certificate Types Figure 6: Key and Certificate Types
1. TFW key pair and certificate: A key pair and certificate for 1. TFW key pair and certificate: A key pair and certificate for
evidence of trustworthy firmware in a device. This key pair is evidence of trustworthy firmware in a device. This key pair is
optional for TEEP architecture. Some TEE may present its trusted optional for TEEP architecture. Some TEE may present its trusted
attributes to a TAM using signed attestation with a TFW key. For attributes to a TAM using signed attestation with a TFW key. For
example, a platform that uses a hardware based TEE can have example, a platform that uses a hardware based TEE can have
attestation data signed by a hardware protected TFW key. attestation data signed by a hardware protected TFW key.
skipping to change at page 23, line 26 skipping to change at page 23, line 29
existing roots without requiring that TAMs are updated with existing roots without requiring that TAMs are updated with
information about the new device factory. Likewise, new TAMs can information about the new device factory. Likewise, new TAMs can
join the ecosystem, providing they are issued a TAM certificate that join the ecosystem, providing they are issued a TAM certificate that
chains to an existing root whereby existing TEEs will be allowed to chains to an existing root whereby existing TEEs will be allowed to
be personalized by the TAM without requiring changes to the TEE be personalized by the TAM without requiring changes to the TEE
itself. This enables the ecosystem to scale, and avoids the need for itself. This enables the ecosystem to scale, and avoids the need for
centralized databases of all TEEs produced or all TAMs that exist. centralized databases of all TEEs produced or all TAMs that exist.
5.12. Message Security 5.12. Message Security
Messages created by a TAM are used to deliver device SD and TA Messages created by a TAM are used to deliver TA management commands
management commands to a device, and device attestation and messages to a device, and device attestation and messages created by the
created by the device TEE to respond to TAM messages. device TEE to respond to TAM messages.
These messages are signed end-to-end and are typically encrypted such These messages are signed end-to-end and are typically encrypted such
that only the targeted device TEE or TAM is able to decrypt and view that only the targeted device TEE or TAM is able to decrypt and view
the actual content. the actual content.
5.13. Security Domain Hierarchy and Ownership 5.13. Security Domain
The primary job of a TAM is to help an SP to manage its trusted
applications. A TA is typically installed in an SD. An SD is
commonly created for an SP.
When an SP delegates its SD and TA management to a TAM, an SD is
created on behalf of a TAM in a TEE and the owner of the SD is
assigned to the TAM. An SD may be associated with an SP but the TAM
has full privilege to manage the SD for the SP.
Each SD for an SP is associated with only one TAM. When an SP
changes TAM, a new SP SD must be created to associate with the new
TAM. The TEE will maintain a registry of TAM ID and SP SD ID
mapping.
From an SD ownership perspective, the SD tree is flat and there is
only one level. An SD is associated with its owner. It is up to the
TEE implementation how it maintains SD binding information for a TAM
and different SPs under the same TAM.
It is an important decision in this architecture that a TEE doesn't
need to know whether a TAM is authorized to manage the SD for an SP.
This authorization is implicitly triggered by an SP Client
Application, which instructs what TAM it wants to use. An SD is
always associated with a TAM in addition to its SP ID. A rogue TAM
isn't able to do anything on an unauthorized SP's SD managed by
another TAM.
Since a TAM may support multiple SPs, sharing the same SD name for
different SPs creates a dependency in deleting an SD. An SD can be
deleted only after all TAs associated with the SD are deleted. An SP
cannot delete a Security Domain on its own with a TAM if a TAM
decides to introduce such sharing. There are cases where multiple
virtual SPs belong to the same organization, and a TAM chooses to use
the same SD name for those SPs. This is totally up to the TAM
implementation and out of scope of this specification.
5.14. SD Owner Identification and TAM Certificate Requirements
There is a need of cryptographically binding proof about the owner of
an SD in a device. When an SD is created on behalf of a TAM, a
future request from the TAM must present itself as a way that the TEE
can verify it is the true owner. The certificate itself cannot
reliably used as the owner because TAM may change its certificate.
** need to handle the normal key roll-over case, as well as the less
frequent key compromise case
To this end, each TAM will be associated with a trusted identifier
defined as an attribute in the TAM certificate. This field is kept
the same when the TAM renew its certificates. A TAM CA is
responsible to vet the requested TAM attribute value.
This identifier value must not collide among different TAM providers,
and one TAM shouldn't be able to claim the identifier used by another
TAM provider.
The certificate extension name to carry the identifier can initially
use SubjectAltName:registeredID. A dedicated new extension name may
be registered later.
One common choice of the identifier value is the TAM's service URL.
A CA can verify the domain ownership of the URL with the TAM in the
certificate enrollment process.
A TEE can assign this certificate attribute value as the TAM owner ID
for the SDs that are created for the TAM.
An alternative way to represent an SD ownership by a TAM is to have a
unique secret key upon SD creation such that only the creator TAM is
able to produce a proof-of-possession (PoP) data with the secret.
5.15. Service Provider Container
A sample Security Domain hierarchy for the TEE is shown in Figure 7.
----------
| TEE |
----------
|
| ----------
|----------| SP1 SD1 |
| ----------
| ----------
|----------| SP1 SD2 |
| ----------
| ----------
|----------| SP2 SD1 |
----------
Figure 7: Security Domain Hierarchy
The architecture separates SDs and TAs such that a TAM can only No security domain (SD) is explicitly assumed in a TEE for TA
manage or retrieve data for SDs and TAs that it previously created management. Some TEE, for example, some TEE compliant with Global
for the SPs it represents. Platform (GP), may continue to choose to use SD to organize resource
partition and security boundaries. It is up to a TEE implementation
to decide how a SD is attached to a TA installation, for example, one
SD could be created per TA.
5.16. A Sample Device Setup Flow 5.14. A Sample Device Setup Flow
Step 1: Prepare Images for Devices Step 1: Prepare Images for Devices
1. [TEE vendor] Deliver TEE Image (CODE Binary) to device OEM 1. [TEE vendor] Deliver TEE Image (CODE Binary) to device OEM
2. [CA] Deliver root CA Whitelist 2. [CA] Deliver root CA Whitelist
3. [Soc] Deliver TFW Image 3. [Soc] Deliver TFW Image
Step 2: Inject Key Pairs and Images to Devices Step 2: Inject Key Pairs and Images to Devices
1. [OEM] Generate TFW Key Pair (May be shared among multiple 1. [OEM] Generate TFW Key Pair (May be shared among multiple
devices) devices)
2. [OEM] Flash signed TFW Image and signed TEE Image onto devices 2. [OEM] Flash signed TFW Image and signed TEE Image onto devices
skipping to change at page 26, line 34 skipping to change at page 24, line 45
[GPTEE] specifies one such architecture. This calls for a software [GPTEE] specifies one such architecture. This calls for a software
module in the REE world to handle the network communication. Each module in the REE world to handle the network communication. Each
Client Application in the REE might carry this communication Client Application in the REE might carry this communication
functionality but such functionality must also interact with the TEE functionality but such functionality must also interact with the TEE
for the message exchange. for the message exchange.
The TEE interaction will vary according to different TEEs. In order The TEE interaction will vary according to different TEEs. In order
for a Client Application to transparently support different TEEs, it for a Client Application to transparently support different TEEs, it
is imperative to have a common interface for a Client Application to is imperative to have a common interface for a Client Application to
invoke for exchanging messages with TEEs. invoke for exchanging messages with TEEs.
A shared agent comes to meet this need. An agent is an application A shared module in REE comes to meet this need. A TEEP broker is an
running in the REE of the device or an SDK that facilitates application running in the REE of the device or an SDK that
communication between a TAM and a TEE. It also provides interfaces facilitates communication between a TAM and a TEE. It also provides
for Client Applications to query and trigger TA installation that the interfaces for Client Applications to query and trigger TA
application needs to use. installation that the application needs to use.
It isn't always that a Client Application directly calls such an It isn't always that a Client Application directly calls such a
agent to interact with a TEE. A REE Application Installer might Broker to interact with a TEE. A REE Application Installer might
carry out TEE and TAM interaction to install all required TAs that a carry out TEE and TAM interaction to install all required TAs that a
Client Application depends. A Client Application may have a metadata Client Application depends. A Client Application may have a metadata
file that describes the TAs it depends on and the associated TAM that file that describes the TAs it depends on and the associated TAM that
each TA installation goes to use. The REE Application Installer can each TA installation goes to use. The REE Application Installer can
inspect the application metadata file and installs TAs on behalf of inspect the application metadata file and installs TAs on behalf of
the Client Application without requiring the Client Application to the Client Application without requiring the Client Application to
run first. run first.
This interface for Client Applications or Application Installers may This interface for Client Applications or Application Installers may
be commonly an OS service call for an REE OS. A Client Application be commonly in a form of an OS service call for an REE OS. A Client
or an Application Installer interacts with the device TEE and the Application or an Application Installer interacts with the device TEE
TAMs. and the TAMs.
6.1. Role of the Agent 6.1. Role of the TEEP Broker
An agent abstracts the message exchanges with the TEE in a device. A TEEP Broker abstracts the message exchanges with a TEE in a device.
The input data is originated from a TAM or the first initialization The input data is originated from a TAM or the first initialization
call to trigger a TA installation. call to trigger a TA installation.
The agent may internally process a message from a TAM. At least, it The Broker doesn't need to parse a message content received from a
needs to know where to route a message, e.g., TEE instance. It does TAM that should be processed by a TEE. When a device has more than
not need to process or verify message content. one TEE, one TEEP Broker per TEE could be present in REE. A TEEP
Broker interacts with a TEEP Agent inside a TEE.
The agent returns TEE / TFW generated response messages to the A TAM message may indicate the target TEE where a TA should be
caller. The agent is not expected to handle any network connection installed. A compliant TEEP protocol should include a target TEE
with an application or TAM. identifier for a TEEP Broker when multiple TEEs are present.
The agent only needs to return an agent error message if the TEE is The Broker relays the response messages generated from a TEEP Agent
not reachable for some reason. Other errors are represented as in a TEE to the TAM. The Broker is not expected to handle any
response messages returned from the TEE which will then be passed to network connection with an application or TAM.
the TAM.
6.2. Agent Implementation Consideration The Broker only needs to return an error message if the TEE is not
reachable for some reason. Other errors are represented as response
messages returned from the TEE which will then be passed to the TAM.
6.2. TEEP Broker Implementation Consideration
A Provider should consider methods of distribution, scope and A Provider should consider methods of distribution, scope and
concurrency on devices and runtime options when implementing an concurrency on devices and runtime options when implementing a TEEP
agent. Several non-exhaustive options are discussed below. Broker. Several non-exhaustive options are discussed below.
Providers are encouraged to take advantage of the latest Providers are encouraged to take advantage of the latest
communication and platform capabilities to offer the best user communication and platform capabilities to offer the best user
experience. experience.
6.2.1. Agent Distribution 6.2.1. TEEP Broker Distribution
The agent installation is commonly carried out at OEM time. A user
can dynamically download and install an agent on-demand.
It is important to ensure a legitimate agent is installed and used.
If an agent is compromised it may drop messages and thereby introduce
a denial of service.
6.2.2. Number of Agents The Broker installation is commonly carried out at OEM time. A user
can dynamically download and install a Broker on-demand.
We anticipate only one shared agent instance in a device. The 6.2.2. Number of TEEP Brokers
device's TEE vendor will most probably supply one agent.
With one shared agent, the agent provider is responsible to allow There should be generally only one shared TEEP Broker in a device.
multiple TAMs and TEE providers to achieve interoperability. With a The device's TEE vendor will most probably supply one Broker. When
standard agent interface, each TAM can implement its own SDK for its multiple TEEs are present in a device, one TEEP Broker per TEE may be
SP Client Applications to work with this agent. used.
Multiple independent agent providers can be used as long as they have When only one Broker is used per device, the Broker provider is
standard interface to a Client Application or TAM SDK. Only one responsible to allow multiple TAMs and TEE providers to achieve
agent is expected in a device. interoperability. With a standard Broker interface, each TAM can
implement its own SDK for its SP Client Applications to work with
this Broker.
TAM providers are generally expected to provide an SDK for SP Multiple independent Broker providers can be used as long as they
applications to interact with an agent for the TAM and TEE have standard interface to a Client Application or TAM SDK. Only one
interaction. Broker is generally expected in a device.
7. Attestation 7. Attestation
Attestation is the process through which one entity (an attestor) Attestation is the process through which one entity (an attestor)
presents a series of claims to another entity (a verifier), and presents a series of claims to another entity (a verifier), and
provides sufficient proof that the claims are true. Different provides sufficient proof that the claims are true. Different
verifiers may have different standards for attestation proofs and not verifiers may have different standards for attestation proofs and not
all attestations are acceptable to every verifier. TEEP attestations all attestations are acceptable to every verifier. TEEP attestations
are based upon the use of an asymmetric key pair under the control of are based upon the use of an asymmetric key pair under the control of
the TEE to create digital signatures across a well-defined claim set. the TEE to create digital signatures across a well-defined claim set.
In TEEP, the primary purpose of an attestation is to allow a device In TEEP, the primary purpose of an attestation is to allow a device
to prove to TAMs and SPs that a TEE in the device has particular to prove to TAMs and SPs that a TEE in the device has particular
properities, was built by a particular manufacturer, or is executing properties, was built by a particular manufacturer, or is executing a
a particular TA. Other claims are possible; this architecture particular TA. Other claims are possible; this architecture
specification does not limit the attestation claims, but defines a specification does not limit the attestation claims, but defines a
minimal set of claims required for TEEP to operate properly. minimal set of claims required for TEEP to operate properly.
Extensions to these claims are possible, but are not defined in the Extensions to these claims are possible, but are not defined in the
TEEP specifications. Other standards or groups may define the format TEEP specifications. Other standards or groups may define the format
and semantics of extended claims. The TEEP specification defines the and semantics of extended claims. The TEEP specification defines the
claims format such that these extended claims may be easily included claims format such that these extended claims may be easily included
in a TEEP attestation message. in a TEEP attestation message.
As of the writing of this specification, device and TEE attestations As of the writing of this specification, device and TEE attestations
have not been standardized across the market. Different devices, have not been standardized across the market. Different devices,
manufacturers, and TEEs support different attestation algorithms and manufacturers, and TEEs support different attestation algorithms and
mechanisms. In order for TEEP to be inclusive, the attestation mechanisms. In order for TEEP to be inclusive, the attestation
format shall allow for both proprietary attestation signatures, as format shall allow for both proprietary attestation signatures, as
well as a standardized form of attestation signature. Either form of well as a standardized form of attestation signature. Either form of
attesation signature may be applied to a set of TEEP claims, and both attestation signature may be applied to a set of TEEP claims, and
forms of attestation shall be considered conformant with TEEP. both forms of attestation shall be considered conformant with TEEP.
However, it should be recognized that not all TAMs or SPs may be able However, it should be recognized that not all TAMs or SPs may be able
to process all proprietary forms of attestations. All TAMs and SPs to process all proprietary forms of attestations. All TAMs and SPs
MUST be able to process the TEEP standard attestation format and MUST be able to process the TEEP standard attestation format and
attached signature. attached signature.
The attestation formats and mechanisms described and mandated by TEEP The attestation formats and mechanisms described and mandated by TEEP
shall convey a particular set of cryptographic properties based on shall convey a particular set of cryptographic properties based on
minimal assumptions. The cryptographic properties are conveyed by minimal assumptions. The cryptographic properties are conveyed by
the attestation; however the assumptions are not conveyed within the the attestation; however the assumptions are not conveyed within the
attestation itself. attestation itself.
skipping to change at page 30, line 21 skipping to change at page 28, line 33
properties from the attestor to the verifier; in the case of TEEP, properties from the attestor to the verifier; in the case of TEEP,
the attestation must convey properties from the device to the TAM the attestation must convey properties from the device to the TAM
and/or SP. The properties required by TEEP include: and/or SP. The properties required by TEEP include:
- Non-repudiation, Unique Proof of Source - the cryptographic - Non-repudiation, Unique Proof of Source - the cryptographic
digital signature across the attestation, and optionally along digital signature across the attestation, and optionally along
with information in the attestion itself SHALL uniquely identify a with information in the attestion itself SHALL uniquely identify a
specific TEE in a specific device. specific TEE in a specific device.
- Integrity of claims - the cryptographic digital signature across - Integrity of claims - the cryptographic digital signature across
the attestation SHALL cover the entire attesation including all the attestation SHALL cover the entire attestation including all
meta data and all the claims in the attestation, ensuring that the meta data and all the claims in the attestation, ensuring that the
attestation has not be modified since the TEE signed the attestation has not be modified since the TEE signed the
attestation. attestation.
Standard public key algorithms such as RSA and ECDSA digital Standard public key algorithms such as RSA and ECDSA digital
signatures convey these properties. Group public key algorithms such signatures convey these properties. Group public key algorithms such
as EPID can also convey these properties, if the attestation includes as EPID can also convey these properties, if the attestation includes
a unique device identifier and an identifier for the TEE. Other a unique device identifier and an identifier for the TEE. Other
cryptographic operations used in other attestation schemes may also cryptographic operations used in other attestation schemes may also
convey these properties. convey these properties.
skipping to change at page 31, line 34 skipping to change at page 29, line 47
| |
+------------+--(Contains)------+-----------------+--------------+ +------------+--(Contains)------+-----------------+--------------+
| | | | | | | | | |
V V V V V V V V V V
+-------------+ +-------------+ +----------+ +-----------------+ +------------+ +-------------+ +-------------+ +----------+ +-----------------+ +------------+
| Device | | TEE | | | | Action or | | Additional | | Device | | TEE | | | | Action or | | Additional |
| Identifying | | Identifying | | Liveness | | Operation | | or optional| | Identifying | | Identifying | | Liveness | | Operation | | or optional|
| Info | | Info | | Proof | | Specific claims | | Claims | | Info | | Info | | Proof | | Specific claims | | Claims |
+-------------+ +-------------+ +----------+ +-----------------+ +------------+ +-------------+ +-------------+ +----------+ +-----------------+ +------------+
Figure 8: Structure of TEEP Attestation Figure 7: Structure of TEEP Attestation
The Attestation Header SHALL identify the "Attestation Type" and the The Attestation Header SHALL identify the "Attestation Type" and the
"Attestation Signature Type" along with an "Attestation Format "Attestation Signature Type" along with an "Attestation Format
Version Number." The "Attestation Type" identifies the minimal set Version Number." The "Attestation Type" identifies the minimal set
of claims that MUST be included in the attestation; this is an of claims that MUST be included in the attestation; this is an
identifier for a profile that defines the claims that should be identifier for a profile that defines the claims that should be
included in the attestation as part of the "Action or Operation included in the attestation as part of the "Action or Operation
Specific Claims." The "Attestation Signature Type" identifies the Specific Claims." The "Attestation Signature Type" identifies the
type of attestation signature that is attached. The type of type of attestation signature that is attached. The type of
attestation signature SHALL be one of the standard signatures types attestation signature SHALL be one of the standard signatures types
skipping to change at page 35, line 25 skipping to change at page 33, line 36
A TA binary is signed by a TA signer certificate. This TA signing A TA binary is signed by a TA signer certificate. This TA signing
certificate/private key belongs to the SP, and may be self-signed certificate/private key belongs to the SP, and may be self-signed
(i.e., it need not participate in a trust hierarchy). It is the (i.e., it need not participate in a trust hierarchy). It is the
responsibility of the TAM to only allow verified TAs from trusted SPs responsibility of the TAM to only allow verified TAs from trusted SPs
into the system. Delivery of that TA to the TEE is then the into the system. Delivery of that TA to the TEE is then the
responsibility of the TEE, using the security mechanisms provided by responsibility of the TEE, using the security mechanisms provided by
the protocol. the protocol.
We allow a way for an (untrusted) application to check the We allow a way for an (untrusted) application to check the
trustworthiness of a TA. An agent has a function to allow an trustworthiness of a TA. A TEEP Broker has a function to allow an
application to query the information about a TA. application to query the information about a TA.
An application in the Rich O/S may perform verification of the TA by An application in the Rich O/S may perform verification of the TA by
verifying the signature of the TA. The GetTAInformation function is verifying the signature of the TA. The GetTAInformation function is
available to return the TEE supplied TA signer and TAM signer available to return the TEE supplied TA signer and TAM signer
information to the application. An application can do additional information to the application. An application can do additional
trust checks on the certificate returned for this TA. It might trust trust checks on the certificate returned for this TA. It might trust
the TAM, or require additional SP signer trust chaining. the TAM, or require additional SP signer trust chaining.
9.2. One TA Multiple SP Case 9.2. One TA Multiple SP Case
A TA for multiple SPs must have a different identifier per SP. A TA A TA for multiple SPs must have a different identifier per SP. They
will be installed in a different SD for each respective SP. should appear as different TAs when they are installed in the same
device.
9.3. Agent Trust Model 9.3. Broker Trust Model
An agent could be malware in the vulnerable REE. A Client A TEEP Broker could be malware in the vulnerable REE. A Client
Application will connect its TAM provider for required TA Application will connect its TAM provider for required TA
installation. It gets command messages from the TAM, and passes the installation. It gets command messages from the TAM, and passes the
message to the agent. message to the Broker.
The architecture enables the TAM to communicate with the device's TEE The architecture enables the TAM to communicate with the device's TEE
to manage SDs and TAs. All TAM messages are signed and sensitive to manage TAs. All TAM messages are signed and sensitive data is
data is encrypted such that the agent cannot modify or capture encrypted such that the TEEP Broker cannot modify or capture
sensitive data. sensitive data.
9.4. Data Protection at TAM and TEE 9.4. Data Protection at TAM and TEE
The TEE implementation provides protection of data on the device. It The TEE implementation provides protection of data on the device. It
is the responsibility of the TAM to protect data on its servers. is the responsibility of the TAM to protect data on its servers.
9.5. Compromised CA 9.5. Compromised CA
A root CA for TAM certificates might get compromised. Some TEE trust A root CA for TAM certificates might get compromised. Some TEE trust
skipping to change at page 37, line 37 skipping to change at page 35, line 45
12.2. Informative References 12.2. 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-teep-opentrustprotocol] [I-D.ietf-teep-opentrustprotocol]
Pei, M., Atyeo, A., Cook, N., Yoo, M., and H. Tschofenig, Pei, M., Atyeo, A., Cook, N., Yoo, M., and H. Tschofenig,
"The Open Trust Protocol (OTrP)", draft-ietf-teep- "The Open Trust Protocol (OTrP)", draft-ietf-teep-
opentrustprotocol-02 (work in progress), October 2018. opentrustprotocol-03 (work in progress), May 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>.
 End of changes. 64 change blocks. 
266 lines changed or deleted 196 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/