< draft-ietf-teep-architecture-01.txt   draft-ietf-teep-architecture-02.txt >
TEEP M. Pei TEEP M. Pei
Internet-Draft Symantec Internet-Draft Symantec
Intended status: Informational H. Tschofenig Intended status: Informational H. Tschofenig
Expires: April 26, 2019 Arm Limited Expires: September 12, 2019 Arm Limited
D. Wheeler D. Wheeler
Intel Intel
A. Atyeo A. Atyeo
Intercede Intercede
L. Dapeng L. Dapeng
Alibaba Group Alibaba Group
October 23, 2018 March 11, 2019
Trusted Execution Environment Provisioning (TEEP) Architecture Trusted Execution Environment Provisioning (TEEP) Architecture
draft-ietf-teep-architecture-01 draft-ietf-teep-architecture-02
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 April 26, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 31 skipping to change at page 2, line 31
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Scope and Assumptions . . . . . . . . . . . . . . . . . . . . 7 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Authentication . . . . . . . . . . . . . . . . . . . . . 8 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. Entity Relations . . . . . . . . . . . . . . . . . . . . 12 5.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 13
5.4. Trust Anchors in TEE . . . . . . . . . . . . . . . . . . 15 5.4. Client Apps, Trusted Apps, and Personalization Data . . . 15
5.5. Trust Anchors in TAM . . . . . . . . . . . . . . . . . . 15 5.5. Examples of Application Delivery Mechanisms in Existing
5.6. Keys and Certificate Types . . . . . . . . . . . . . . . 15 TEEs . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.7. Scalability . . . . . . . . . . . . . . . . . . . . . . . 18 5.6. TEEP Architectural Support for Client App, TA, and
5.8. Message Security . . . . . . . . . . . . . . . . . . . . 18 Personalization Data Delivery . . . . . . . . . . . . . . 17
5.9. Security Domain Hierarchy and Ownership . . . . . . . . . 18 5.7. Entity Relations . . . . . . . . . . . . . . . . . . . . 17
5.10. SD Owner Identification and TAM Certificate Requirements 19 5.8. Trust Anchors in TEE . . . . . . . . . . . . . . . . . . 20
5.11. Service Provider Container . . . . . . . . . . . . . . . 20 5.9. Trust Anchors in TAM . . . . . . . . . . . . . . . . . . 20
5.12. A Sample Device Setup Flow . . . . . . . . . . . . . . . 20 5.10. Keys and Certificate Types . . . . . . . . . . . . . . . 20
6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.11. Scalability . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. Role of the Agent . . . . . . . . . . . . . . . . . . . . 22 5.12. Message Security . . . . . . . . . . . . . . . . . . . . 23
6.2. Agent Implementation Consideration . . . . . . . . . . . 22 5.13. Security Domain Hierarchy and Ownership . . . . . . . . . 23
6.2.1. Agent Distribution . . . . . . . . . . . . . . . . . 22 5.14. SD Owner Identification and TAM Certificate Requirements 24
6.2.2. Number of Agents . . . . . . . . . . . . . . . . . . 23 5.15. Service Provider Container . . . . . . . . . . . . . . . 25
7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.16. A Sample Device Setup Flow . . . . . . . . . . . . . . . 25
7.1. Attestation Hierarchy . . . . . . . . . . . . . . . . . . 23 6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1.1. Attestation Hierarchy Establishment: Manufacture . . 23 6.1. Role of the Agent . . . . . . . . . . . . . . . . . . . . 27
7.1.2. Attestation Hierarchy Establishment: Device Boot . . 24 6.2. Agent Implementation Consideration . . . . . . . . . . . 27
7.1.3. Attestation Hierarchy Establishment: TAM . . . . . . 24 6.2.1. Agent Distribution . . . . . . . . . . . . . . . . . 27
8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 24 6.2.2. Number of Agents . . . . . . . . . . . . . . . . . . 27
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. TA Trust Check at TEE . . . . . . . . . . . . . . . . . . 25 7.1. Attestation Cryptographic Properties . . . . . . . . . . 30
9.2. One TA Multiple SP Case . . . . . . . . . . . . . . . . . 25 7.2. TEEP Attestation Structure . . . . . . . . . . . . . . . 31
9.3. Agent Trust Model . . . . . . . . . . . . . . . . . . . . 25 7.3. TEEP Attestation Claims . . . . . . . . . . . . . . . . . 32
9.4. Data Protection at TAM and TEE . . . . . . . . . . . . . 26 7.4. TEEP Attestation Flow . . . . . . . . . . . . . . . . . . 33
9.5. Compromised CA . . . . . . . . . . . . . . . . . . . . . 26 7.5. Attestation Key Example . . . . . . . . . . . . . . . . . 33
9.6. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 26 7.5.1. Attestation Hierarchy Establishment: Manufacture . . 33
9.7. Certificate Renewal . . . . . . . . . . . . . . . . . . . 26 7.5.2. Attestation Hierarchy Establishment: Device Boot . . 34
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 7.5.3. Attestation Hierarchy Establishment: TAM . . . . . . 34
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 34
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35
12.1. Normative References . . . . . . . . . . . . . . . . . . 27 9.1. TA Trust Check at TEE . . . . . . . . . . . . . . . . . . 35
12.2. Informative References . . . . . . . . . . . . . . . . . 27 9.2. One TA Multiple SP Case . . . . . . . . . . . . . . . . . 35
Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 28 9.3. Agent Trust Model . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 9.4. Data Protection at TAM and TEE . . . . . . . . . . . . . 36
9.5. Compromised CA . . . . . . . . . . . . . . . . . . . . . 36
9.6. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 36
9.7. Certificate Renewal . . . . . . . . . . . . . . . . . . . 36
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
12.1. Normative References . . . . . . . . . . . . . . . . . . 37
12.2. Informative References . . . . . . . . . . . . . . . . . 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 32 skipping to change at page 5, line 40
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
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The following terms are used: The following terms are used:
- Client Application: An application running in a Rich Execution - Client 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. We
sometimes refer to this as the 'Client App'.
- Device: A physical piece of hardware that hosts a TEE along with a - Device: A physical piece of hardware that hosts a TEE along with a
Rich Execution Environment. A Device contains a default list of Rich Execution Environment. A Device contains a default list of
Trust Anchors that identify entities (e.g., TAMs) that are trusted Trust Anchors that identify entities (e.g., TAMs) that are trusted
by the Device. This list is normally set by the Device by the Device. This list is normally set by the Device
Manufacturer, and may be governed by the Device's network carrier. Manufacturer, and may be governed by the Device's network carrier.
The list of Trust Anchors is normally modifiable by the Device's The list of Trust Anchors is normally modifiable by the Device's
owner or Device Administrator. However the Device manufacturer owner or Device Administrator. However the Device manufacturer
and network carrier may restrict some modifications, for example, and network carrier may restrict some modifications, for example,
by not allowing the manufacturer or carrier's Trust Anchor to be by not allowing the manufacturer or carrier's Trust Anchor to be
skipping to change at page 6, line 7 skipping to change at page 6, line 16
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 the TEE. This environment and and hypervisors; it is outside of the TEE. This environment and
applications running on it are considered un-trusted. applications running on it are considered un-trusted.
- 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. A Service Provider requires the help of a TAM in
order to provision the Trusted Applications to remote devices. order to provision the Trusted Applications to remote devices.
- Device Administrator: An entity that owns or is responsible for - Device User: A human being that uses a device. Many devices have
administration of a Device. A Device Administrator has privileges a single device user. Some devices have a primary device user
on the Device to install and remove applications and TAs, approve with other human beings as secondary device users (e.g., parent
or reject Trust Anchors, and approve or reject Service Providers, allowing children to use their tablet or laptop). Relates to
among possibly other privileges on the Device. A device owner can Device Owner and Device Administrator.
manage the list of allowed TAMs by modifying the list of Trust
Anchors on the Device. Although a Device Administrator may have - Device Owner: A device is always owned by someone. It is common
privileges and Device-specific controls to locally administer a for the (primary) device user to also own the device, making the
device, the Device Administrator may choose to remotely device user/owner also the device administrator. In enterprise
administrate a device through a TAM. environments it is more common for the enterprise to own the
device, and device users have no or limited administration rights.
In this case, the enterprise appoints a device administrator that
is not the device owner.
- Device Administrator (DA): An entity that is responsible for
administration of a Device, which could be the device owner. A
Device Administrator has privileges on the Device to install and
remove applications and TAs, approve or reject Trust Anchors, and
approve or reject Service Providers, among possibly other
privileges on the Device. A Device Administrator can manage the
list of allowed TAMs by modifying the list of Trust Anchors on the
Device. Although a Device Administrator may have privileges and
Device-specific controls to locally administer a device, the
Device Administrator may choose to remotely administrate a device
through a TAM.
- Trust Anchor: A public key in a device whose corresponding private - Trust Anchor: A public key in a device whose corresponding private
key is held by an entity implicitly trusted by the device. The key is held by an entity implicitly trusted by the device. The
Trust Anchor may be a certificate or it may be a raw public key. Trust Anchor may be a certificate or it may be a raw public key
The trust anchor is normally stored in a location that resists along with additional data if necessary such as its public key
unauthorized modification, insertion, or replacement. algorithm and parameters. The Trust Anchor is normally stored in
The trust anchor private key owner can sign certificates of other a location that resists unauthorized modification, insertion, or
public keys, which conveys trust about those keys to the device. replacement. The digital fingerprint of a Trust Anchor may be
A certificate signed by the trust anchor communicates that the stored along with the Trust Anchor certificate or public key. A
private key holder of the signed certificate is trusted by the device can use the fingerprint to uniquely identify a Trust
trust anchor holder, and can therefore be trusted by the device. Anchor. The Trust Anchor private key owner can sign certificates
of other public keys, which conveys trust about those keys to the
device. A certificate signed by the Trust Anchor communicates
that the private key holder of the signed certificate is trusted
by the Trust Anchor holder, and can therefore be trusted by the
device. Trust Anchors in a device may be updated by an authorized
party when a Trust Anchor should be deprecated or a new Trust
Anchor should be added.
- Trusted Application (TA): An application component that runs in a - Trusted Application (TA): An application component that runs in a
TEE. TEE.
- Trusted Execution Environment (TEE): An execution environment that - Trusted Execution Environment (TEE): An execution environment that
runs alongside of, but is isolated from, an REE. A TEE has runs alongside of, but is isolated from, an REE. A TEE has
security capabilities and meets certain security-related security capabilities and meets certain security-related
requirements. It protects TEE assets from general software requirements. It protects TEE assets from general software
attacks, defines rigid safeguards as to data and functions that a attacks, defines rigid safeguards as to data and functions that a
program can access, and resists a set of defined threats. It program can access, and resists a set of defined threats. It
skipping to change at page 7, line 6 skipping to change at page 7, line 36
(c) Memory that cannot be read by code outside the TEE. (c) Memory that cannot be read by code outside the TEE.
There are multiple technologies that can be used to implement a There are multiple technologies that can be used to implement a
TEE, and the level of security achieved varies accordingly. TEE, and the level of security achieved varies accordingly.
- Root-of-Trust (RoT): A hardware or software component in a device - Root-of-Trust (RoT): A hardware or software component in a device
that is inherently trusted to perform a certain security-critical that is inherently trusted to perform a certain security-critical
function. A RoT should be secure by design, small, and protected function. A RoT should be secure by design, small, and protected
by hardware against modification or interference. Examples of by hardware against modification or interference. Examples of
RoTs include software/firmware measurement and verification using RoTs include software/firmware measurement and verification using
a trust anchor (RoT for Verification), provide signed assertions a Trust Anchor (RoT for Verification), provide signed assertions
using a protected attestation key (RoT for Reporting), or protect using a protected attestation key (RoT for Reporting), or protect
the storage and/or use of cryptographic keys (RoT for Storage). the storage and/or use of cryptographic keys (RoT for Storage).
Other RoTs are possible, including RoT for Integrity, and RoT for Other RoTs are possible, including RoT for Integrity, and RoT for
Measurement. Reference: NIST SP800-164 (Draft). Measurement. Reference: NIST SP800-164 (Draft).
- Trusted Firmware (TFW): A firmware in a device that can be - Trusted Firmware (TFW): A firmware in a device that can be
verified with a trust anchor by RoT for Verification. verified with a Trust Anchor by RoT for Verification.
- Bootloader key: This symmetric key is protected by - Bootloader key: This symmetric key is protected by
electronic fuse (eFUSE) technology. In this context it is used to electronic fuse (eFUSE) technology. In this context it is used to
decrypt a decrypt a
TFW private key, which belongs to a device-unique private/public TFW private key, which belongs to a device-unique private/public
key pair. Not every device is equipped with a bootloader key. key pair. Not every device is equipped with a bootloader key.
This document uses the following abbreviations: This document uses the following abbreviations:
- CA: Certificate Authority - CA: Certificate Authority
skipping to change at page 7, line 41 skipping to change at page 8, line 23
- SP: Service Provider - SP: Service Provider
- TA: Trusted Application - TA: Trusted Application
- TAM: Trusted Application Manager - TAM: Trusted Application Manager
- TEE: Trusted Execution Environment - TEE: Trusted Execution Environment
- TFW: Trusted Firmware - TFW: Trusted Firmware
3. Scope and Assumptions 3. Assumptions
This specification assumes that an applicable device is equipped with This specification assumes that an applicable device is equipped with
one or more TEEs and each TEE is pre-provisioned with a device-unique one or more TEEs and each TEE is pre-provisioned with a device-unique
public/private key pair, which is securely stored. This key pair is public/private key pair, which is securely stored.
referred to as the 'root of trust' for remote attestation of the
associated TEE in a device by an TAM.
New note: SD is for managing keys for TAs
A Security Domain (SD) concept is used as the security boundary
inside a TEE for trusted applications. Each SD is typically
associated with one TA provider as the owner, which is a logical
space that contains an SP's TAs. One TA provider may request to have
multiple SDs in a TEE. One SD may contain multiple TAs. Each
Security Domain requires the management operations of TAs in the form
of installation, update and deletion.
Each TA binary and configuration data can be from either of two
sources:
1. A TAM supplies the signed and encrypted TA binary and any
required configuration data
2. A Client Application supplies the TA binary
The architecture covers the first case where the TA binary and A TEE uses an isolation mechanism between Trusted Applications to
configuration data are delivered from a TAM. The second case calls ensure that one TA cannot read, modify or delete the data and code of
for an extension when a TAM is absent. another TA.
4. Use Cases 4. Use Cases
4.1. Payment 4.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.
skipping to change at page 10, line 28 skipping to change at page 10, line 28
| | | +---+ +---+ | +-------+ | | | Device Administrator | | | +---+ +---+ | +-------+ | | | Device Administrator
| | +-------------+ | App-1 | | | | | | +-------------+ | App-1 | | | |
| | | | | | | | | | | | | |
| +--------------------| |---+ | | | +--------------------| |---+ | |
| | |--------+ | | | |--------+ |
| +-------+ | | +-------+ |
+-------------------------------------------+ +-------------------------------------------+
Figure 1: Notional Architecture of TEEP Figure 1: Notional Architecture of TEEP
- Service Providers and Device Administrators utilize the services - Service Providers (SP) and Device Administrators (DA) utilize the
of a TAM to manage TAs on Devices. SPs do not directly interact services of a TAM to manage TAs on Devices. SPs do not directly
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 and SD's on behalf of Service Providers and
Device Administrators. This includes creation and deletion of Device Administrators. This includes creation and deletion of
TA's and SD's, and may include, for example, over-the-air updates TA's and SD's, and may include, for example, over-the-air updates
to keep an SP's TAs up-to-date and clean up when a version should 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 easier for SPs be removed. TAMs may provide services that make it easier for SPs
or DAs to use the TAM's service to manage multiple devices, or DAs to use the TAM's service to manage multiple devices,
although that is not required of a TAM. although that is not 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 and SD's through an
interaction with a Device's TEEP Broker. As shown in interaction with a Device's TEEP Broker. As shown in
#notionalarch, the TAM cannot directly contact a Device, but must #notionalarch, the TAM cannot directly contact a Device, but must
wait for a the TEEP Broker or a Client Application to contact the wait for a the TEEP Broker or a Client Application to contact the
TAM requesting a particular service. This architecture is TAM requesting a particular service. This architecture is
intentional in order to accommodate network and application intentional in order to accommodate network and application
firewalls that normally protect user and enterprise devices from firewalls that normally protect user and enterprise devices from
arbitrary connections from external network entities. arbitrary connections from external network entities.
A TAM may be publically available for use by many SPs, or a TAM A TAM may be publicly available for use by many SPs, or a TAM may
may be private, and accessible by only one or a limited number of be private, and accessible by only one or a limited number of SPs.
SPs. It is expected that manufacturers and carriers will run
their own private TAM. Another example of a private TAM is a TAM It is expected that manufacturers and carriers will run their own
running as a Software-as-a-Service (SaaS) within an SP. private TAM. Another example of a private TAM is a TAM running as
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
is trusted by a device if the TAM's public key is an authorized is trusted by a device if the TAM's public key is an authorized
Trust Anchor in the Device. A SP or Device Administrator may run Trust Anchor in the Device. A SP or Device Administrator may run
their own TAM, however the Devices they wish to manage must their own TAM, however the Devices they wish to manage must
include this TAM's pubic key in the Trust Anchor list. include this TAM's pubic key in the Trust Anchor list.
A SP or Device Administrator is free to utilize multiple TAMs. A SP or Device Administrator is free to utilize multiple TAMs.
This may be required for a SP to manage multiple different types This may be required for a SP to manage multiple different types
skipping to change at page 12, line 7 skipping to change at page 12, line 7
only one active TEE. A TEE may provide such an Agent to the only one active TEE. A TEE may provide such an Agent 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 an Agent counterpart, namely, a processing module
inside the TEE, to parse TAM messages sent through the Agent. An inside the TEE, to parse TAM messages sent through the Agent. An
Agent is generally acting as a dummy relaying box with just the Agent is generally acting as a dummy relaying box with just the
TEE interacting capability; it doesn't need and shouldn't parse TEE interacting capability; it doesn't need and shouldn't parse
protocol messages. protocol messages.
- 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
5.3. Entity Relations There is nothing prohibiting a device from implementing multiple
TEEs. In addition, some TEEs ( for example, SGX) present themselves
as separate containers within memory without a controlling manager
within the TEE. In these cases, the rich operating system hosts
multiple TEEP brokers, where each broker manages a particular TEE or
set of TEEs. Enumeration and access to the appropriate broker is up
to the rich OS and the applications. Verification that the correct
TA has been reached then becomes a matter of properly verifying TA
attestations, which are unforgeable. The multiple TEE approach is
shown in the diagram below. For brevity, TEEP Broker 2 is shown
interacting with only one TAM and UA, but no such limitation is
intended to be implied in the architecture.
+-------------------------------------------+
| Device |
| +--------+ | Service Provider
| | |----------+ |
| +-------------+ | TEEP |---------+| |
| | TEE-1 |<------| Broker | | || +--------+ |
| | | | 1 |<---+ | |+-->| |<-+
| | +---+ +---+ | | | | | | +-| TAM-1 |
| | |TA1| |TA2| | | |<-+ | | +->| | |<-+
| +-->| | | |<---+ +--------+ | | | | +--------+ |
| | | +---+ +---+ | | | | | | TAM-2 | |
| | | | | +-------+ | | | +--------+ |
| | +-------------+ +-----| App-2 |--+ | | ^ |
| | +-------+ | | | | Device
| +--------------------| App-1 | | | | | Administrator
| +------| | | | | |
| +-----------|-+ | |---+ | | |
| | TEE-2 | | | |--------+ | |
| | | | | |------+ | |
| | +---+ | | +-------+ | | |
| | |TA3|<----+ | +----------+ | | |
| | | | | | TEEP |<--+ | |
| | +---+ |<---| Broker |----------------+
| | | | 2 | |
| | | | | |
| +-------------+ +----------+ |
| |
+-------------------------------------------+
Figure 2: Notional Architecture of TEEP wtih multiple TEEs
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
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
Brokers on a particular platform. In addition, since TEE's may be
physically separated, with wholly different resources, there may be
no need for TEEP Brokers to share information on installed TAs or
resource usage. However, the architecture guarantees that the TAM
will receive all the relevant information from the TEEP Broker to
which it communicates.
5.3. Multiple TAMs and Relationship to TAs
As shown in Figure 2, the TEEP Broker provides connections from the
TEE and the Client App to one or more TAMs. The selection of which
TAM to communicate with is dependent on information from the Client
App and is directly related to the TA.
When a SP offers a service which requires a TA, the SP associates
that service with a specific TA. The TA itself is digitally signed,
protecting its integrity, but the signature also links the TA back to
the signer. The signer is usually the SP, but in some cases may be
another party that the SP trusts. The SP selects one or more TAMs
through which to offer their service, and communicates the
information of the service and the specific client apps and TAs to
the TAM.
The SP chooses TAMs based upon the markets into which the TAM can
provide access. There may be TAMs that provide services to specific
types of mobile devices, or mobile device operating systems, or
specific geographical regions or network carriers. A SP may be
motivated to utilize multiple TAMs for its service in order to
maximize market penetration and availability on multiple types of
devices. This likely means that the same service will be available
through multiple TAMs.
When the SP publishes the Client App to an app store or other app
repositories, the SP binds the Client App with a manifest that
identifies what TAMs can be contacted for the TA. In some
situations, an SP may use only a single TAM - this is likely the case
for enterprise applications or SPs serving a closed community. For
broad public apps, there will likely be multiple TAMs in the manifest
- one servicing one brand of mobile device and another servicing a
different manufacturer, etc. Because different devices and different
manufacturers trust different TAMs, the manifest will include
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
multiple different devices.
When the TEEP Broker recieves a request to contact the TAM for a
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
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
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
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
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
TA.
[Note: This should always be the case. When a particular device or
TEE supports only a special proprietary attestation mechanism, then a
specific TAM will be needed that supports that attestation scheme.
The TAM should also support standard atttestation signatures as well.
It is highly unlikely that a set of TAs would use different
proprietary attestation mechanisms since a TEE is likley to support
only one such proprietary scheme.]
[Note: This situation gets more complex in situations where a Client
App expects another application or a device to already have a
specific TA installed. This situation does not occur with SGX, but
could occur in situations where the secure world maintains an trusted
operating system and runs an entire trusted system with multiple TAs
running. This requires more discussion.]
5.4. Client Apps, Trusted Apps, and Personalization Data
In TEEP, there is an explicit relationship and dependence between the
client app in the REE and one or more TAs in the TEE, as shown in
Figure 2. From the perspective of a device user, a client app that
uses one or more TA's in a TEE appears no different from any other
untrusted application in the REE. However, the way the client app
and its corresponding TA's are packaged, delivered, and installed on
the device can vary. The variations depend on whether the client app
and TA are bundled together or are provided separately, and this has
implications to the management of the TAs in the TEE. In addition to
the client app and TA, the TA and/or TEE may require some additional
data to personalize the TA to the service provider or the device
user. This personalization data is dependent on the TEE, the TA 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
symmetric key used to by the TA to communicate with the SP. The
personalization data must be encrypted to preserve the
confidentiality of potentially sensitive data contained within it.
Other than this requirement to support confidentiality, TEEP place no
limitations or requirements on the personalization data.
There are three possible cases for bundling of the Client App, TA,
and personalizaiton data:
1. The Client App, TA, and personnalization data are all bundled
together in a single package by the SP and provided to the TEEP
Broker through the TAM.
2. The Client App and the TA are bundled together in a single
binary, which the TAM or a publicly accessible app store
maintains in repository, and the personalization data is
separately provided by the SP. In this case, the personalization
data is collected by the TAM and included in the InstallTA
message to the TEEP Broker.
3. All components are independent. The device user installs the
Client App through some independent or device-specific mechanism,
and the TAM provides the TA and personalization data from the SP.
Delivery of the TA and personalization data may be combined or
separate.
5.5. Examples of Application Delivery Mechanisms in Existing TEEs
In order to better understand these cases, it is helpful to review
actual implementations of TEEs and their application delivery
mechanisms.
In Intel Software Guard Extensions (SGX), the Client App and TA are
typically bound into the same binary (Case 2). The TA is compiled
into the Client App binary using SGX tools, and exists in the binary
as a shared library (.so or .dll). The Client App loads the TA into
an SGX enclave when the client needs the TA. This organization makes
it easy to maintain compatibility between the Client App and the TA,
since they are updated together. It is entirely possible to create a
Client App that loads an external TA into an SGX enclave and use that
TA (Case 3). In this case, the Client App would require a reference
to an external file or download such a file dynamically, place the
contents of the file into memory, and load that as a TA. Obviously,
such file or downloaded content must be properly formatted and signed
for it to be accepted by the SGX TEE. In SGX, for Case 2 and Case 3,
the personalization data is normally loaded into the SGX enclave (the
TA) after the TA has started. Although Case 1 is possible with SGX,
there are no instances of this known to be in use at this time, since
such a construction would required a special installation program and
SGX TA to recieve the encrypted binary, decrypt it, separate it into
the three different elements, and then install all three. This
installation is complex, because the Client App decrypted inside the
TEE must be passed out of the TEE to an installer in the REE which
would install the Client App; this assumes that the Client App binary
includes the TA code also, otherwise there is a significant problem
in getting the SGX encalve code (the TA) from the TEE, through the
installer and into the Client App in a trusted fashion. Finally, the
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,
which would pass this data to the installed Client App, which would
in turn send this data to the SGX enclave (TA). This complexity is
due to the fact that each SGX enclave is separate and does not have
direct communication to one another.
[NOTE: Need to add an equivalent discussion for an ARM/TZ
implementation]
5.6. TEEP Architectural Support for Client App, TA, and Personalization
Data Delivery
This section defines TEEP support for the three different cases for
delivery of the Client App, TA, and personalization data.
[Note: discussion of format of this single binary, and who/what is
responsible for splitting these things apart, and installing the
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
the TEE but this may not be suported by all TAs.]
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
signer of an allowed TA's signer certificate should chain to. A signer of an allowed TA's signer certificate should chain to. A
device administrator may choose to accept a subset of the allowed TAs device administrator may choose to accept a subset of the allowed TAs
via consent or action of downloading. via consent or action of downloading.
PKI CA -- CA CA -- PKI CA -- CA CA --
| | | | | |
| | | | | |
| | | | | |
Device | | --- Agent / Client App --- | Device | | --- Agent / Client App --- |
SW | | | | | SW | | | | |
| | | | | | | | | |
| | | | | | | | | |
| -- TEE TAM------- | -- TEE TAM-------
| |
| |
FW FW
Figure 2: Entities Figure 3: Entities
(App Developer) (App Store) (TAM) (Device with TEE) (CAs) (App Developer) (App Store) (TAM) (Device with TEE) (CAs)
| | | |
| --> (Embedded TEE cert) <-- | --> (Embedded TEE cert) <--
| | | |
| <------------------------------ Get an app cert ----- | | <------------------------------ Get an app cert ----- |
| | <-- Get a TAM cert ------ | | | <-- Get a TAM cert ------ |
| |
1. Build two apps: 1. Build two apps:
Client App Client App
TA TA
| |
| |
Client App -- 2a. --> | ----- 3. Install -------> | Client App -- 2a. --> | ----- 3. Install -------> |
TA ------- 2b. Supply ------> | 4. Messaging-->| TA ------- 2b. Supply ------> | 4. Messaging-->|
| | | | | | | |
Figure 3: Developer Experience Figure 4: Developer Experience
Figure 3 shows an application developer building two applications: 1) Figure 4 shows an application developer building two applications: 1)
a rich Client Application; 2) a TA that provides some security a rich Client 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 Client Application (2a) to an Application developer uploads the Client Application (2a) to an Application
Store. The Client Application may optionally bundle the TA binary. Store. The Client Application may optionally bundle the TA binary.
Meanwhile, the application developer may provide its TA to a TAM Meanwhile, the application developer may provide its TA to a TAM
provider that will be managing the TA in various devices. 3. A user provider that will be managing the TA in various devices. 3. A user
will go to an Application Store to download the Client Application. will go to an Application Store to download the Client Application.
The Client Application will trigger TA installation by initiating The Client Application will trigger TA installation by initiating
communication with a TAM. This is the step 4. The Client communication with a TAM. This is the step 4. The Client
Application will get messages from TAM, and interacts with device TEE Application will get messages from TAM, and interacts with device TEE
skipping to change at page 14, line 31 skipping to change at page 19, line 31
| | Cert | | Cert | | Cert | | | Cert | | Cert | | Cert |
| | FW Key/ | | | | | | | FW Key/ | | | | |
| | Cert | | | | | | | Cert | | | | |
-------------------- --------------- ---------- -------------------- --------------- ----------
| | | | | |
| | | | | |
------------- ---------- --------- ------------- ---------- ---------
| TEE CA | | TAM CA | | SP CA | | TEE CA | | TAM CA | | SP CA |
------------- ---------- --------- ------------- ---------- ---------
Figure 4: 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 device SD and TA management commands to a device,
and device attestation and response messages created by a TEE that and device attestation and response messages created by a TEE that
responds to a TAM's message. responds to a TAM's message.
skipping to change at page 15, line 12 skipping to change at page 20, line 12
namely, an agent in this protocol architecture, not directly from the namely, an agent in this protocol architecture, not directly from the
network. 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 agent, 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. The agent does not need to
know the actual content of messages except for the TEE routing know the actual content of messages except for the TEE routing
information. information.
5.4. Trust Anchors in TEE 5.8. Trust Anchors in TEE
Each TEE comes with a trust store that contains a whitelist of root Each TEE comes with a trust store that contains a whitelist of Trust
CA certificates that are used to validate a TAM's certificate. A TEE Anchors that are used to validate a TAM's certificate. A TEE will
will accept a TAM to create new Security Domains and install new TAs accept a TAM to create new Security Domains and install new TAs on
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
is out of the scope in this document to specify how the trust store is out of the scope in this document to specify how the trust anchors
should be updated when a new root certificate should be added or should be updated when a new root certificate should be added or
existing one should be updated or removed. A device manufacturer is existing one should be updated or removed. A device manufacturer is
expected to provide its TEE trust store live update or out-of-band expected to provide its TEE trust anchors live update or out-of-band
update to devices. update to Device Administrators.
When trust anchor update is carried out, it is imperative that any
update must maintain integrity where only authentic trust anchor list
from a device manufacturer or a Device Administrator is accepted.
This calls for a complete lifecycle flow in authorizing who can make
trust anchor update and whether a given trust anchor list are non-
tampered from the original provider. The signing of a trust anchor
list for integrity check and update authorization methods are
desirable to be developed. This can be addressed outside of this
architecture document.
Before a TAM can begin operation in the marketplace to support a Before a TAM can begin operation in the marketplace to support a
device with a particular TEE, it must obtain a TAM certificate from a device with a particular TEE, it must obtain a TAM certificate from a
CA that is listed in the trust store of the TEE. CA that is listed in the trust store of the TEE.
5.5. Trust Anchors in TAM 5.9. Trust Anchors in TAM
The trust anchor store in a TAM consists of a list of CA certificates The Trust Anchor store in a TAM consists of a list of CA certificates
that sign various device TEE certificates. A TAM decides what that sign various device TEE certificates. A TAM will accept a
devices it will trust the TEE in. device for TA management if the TEE in the device uses a TEE
certificate that is chained to a CA that the TAM trusts.
5.6. Keys and Certificate Types 5.10. 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 without relying on any transport delivering end-to-end security without relying on any transport
security. security.
+-------------+----------+--------+-------------------+-------------+ +-------------+----------+--------+-------------------+-------------+
| Key Entity | Location | Issuer | Checked Against | Cardinality | | Key Entity | Location | Issuer | Checked Against | Cardinality |
| Name | | | | | | Name | | | | |
+-------------+----------+--------+-------------------+-------------+ +-------------+----------+--------+-------------------+-------------+
| 1. TFW key | Device | FW CA | A whitelist of | 1 per | | 1. TFW key | Device | FW CA | A whitelist of | 1 per |
skipping to change at page 16, line 33 skipping to change at page 21, line 33
| 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. | | | | | | SD as the owner. | |
+-------------+----------+--------+-------------------+-------------+ +-------------+----------+--------+-------------------+-------------+
Figure 5: 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.
o Location: Device secure storage o Location: Device secure storage
skipping to change at page 18, line 7 skipping to change at page 23, line 7
sizes should be anticipated in future. sizes should be anticipated in future.
o Issuer: An SP signer CA that chains to a root CA o Issuer: An SP signer CA that chains to a root CA
o Checked Against: An SP uses a TAM. A TEE trusts an SP by o Checked Against: An SP uses a TAM. A TEE trusts an SP by
validating trust against a TAM that the SP uses. A TEE trusts validating trust against a TAM that the SP uses. A TEE trusts
a TAM to ensure that a TA is trustworthy. a TAM to ensure that a TA is trustworthy.
o Cardinality: One or multiple can be used by an SP o Cardinality: One or multiple can be used by an SP
5.7. Scalability 5.11. Scalability
This architecture uses a PKI. Trust anchors exist on the devices to This architecture uses a PKI. Trust Anchors exist on the devices to
enable the TEE to authenticate TAMs, and TAMs use trust anchors to enable the TEE to authenticate TAMs, and TAMs use Trust Anchors to
authenticate TEEs. Since a PKI is used, many intermediate CA authenticate TEEs. Since a PKI is used, many intermediate CA
certificates can chain to a root certificate, each of which can issue certificates can chain to a root certificate, each of which can issue
many certificates. This makes the protocol highly scalable. New many certificates. This makes the protocol highly scalable. New
factories that produce TEEs can join the ecosystem. In this case, factories that produce TEEs can join the ecosystem. In this case,
such a factory can get an intermediate CA certificate from one of the such a factory can get an intermediate CA certificate from one of the
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.8. 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 device SD and TA
management commands to a device, and device attestation and messages management commands to a device, and device attestation and messages
created by the device TEE to respond to TAM messages. created by the 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.9. Security Domain Hierarchy and Ownership 5.13. Security Domain Hierarchy and Ownership
The primary job of a TAM is to help an SP to manage its trusted 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 applications. A TA is typically installed in an SD. An SD is
commonly created for an SP. commonly created for an SP.
When an SP delegates its SD and TA management to a TAM, an SD is 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 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 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. has full privilege to manage the SD for the SP.
skipping to change at page 19, line 24 skipping to change at page 24, line 24
Since a TAM may support multiple SPs, sharing the same SD name for 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 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 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 cannot delete a Security Domain on its own with a TAM if a TAM
decides to introduce such sharing. There are cases where multiple decides to introduce such sharing. There are cases where multiple
virtual SPs belong to the same organization, and a TAM chooses to use 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 the same SD name for those SPs. This is totally up to the TAM
implementation and out of scope of this specification. implementation and out of scope of this specification.
5.10. SD Owner Identification and TAM Certificate Requirements 5.14. SD Owner Identification and TAM Certificate Requirements
There is a need of cryptographically binding proof about the owner of 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 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 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 can verify it is the true owner. The certificate itself cannot
reliably used as the owner because TAM may change its certificate. 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 ** need to handle the normal key roll-over case, as well as the less
frequent key compromise case frequent key compromise case
skipping to change at page 20, line 12 skipping to change at page 25, line 12
A CA can verify the domain ownership of the URL with the TAM in the A CA can verify the domain ownership of the URL with the TAM in the
certificate enrollment process. certificate enrollment process.
A TEE can assign this certificate attribute value as the TAM owner ID A TEE can assign this certificate attribute value as the TAM owner ID
for the SDs that are created for the TAM. for the SDs that are created for the TAM.
An alternative way to represent an SD ownership by a TAM is to have a 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 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. able to produce a proof-of-possession (PoP) data with the secret.
5.11. Service Provider Container 5.15. Service Provider Container
A sample Security Domain hierarchy for the TEE is shown in Figure 6. A sample Security Domain hierarchy for the TEE is shown in Figure 7.
---------- ----------
| TEE | | TEE |
---------- ----------
| |
| ---------- | ----------
|----------| SP1 SD1 | |----------| SP1 SD1 |
| ---------- | ----------
| ---------- | ----------
|----------| SP1 SD2 | |----------| SP1 SD2 |
| ---------- | ----------
| ---------- | ----------
|----------| SP2 SD1 | |----------| SP2 SD1 |
---------- ----------
Figure 6: Security Domain Hierarchy Figure 7: Security Domain Hierarchy
The architecture separates SDs and TAs such that a TAM can only The architecture separates SDs and TAs such that a TAM can only
manage or retrieve data for SDs and TAs that it previously created manage or retrieve data for SDs and TAs that it previously created
for the SPs it represents. for the SPs it represents.
5.12. A Sample Device Setup Flow 5.16. 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
-
1. [CA] Deliver root CA Whitelist
- 2. [CA] Deliver root CA Whitelist
1. [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)
-
1. [OEM] Flash signed TFW Image and signed TEE Image onto devices 2. [OEM] Flash signed TFW Image and signed TEE Image onto devices
(signed by TFW Key) (signed by TFW Key)
Step 3: Set up attestation key pairs in devices Step 3: Set up attestation key pairs in devices
- 1. [OEM] Flash TFW Public Key and a bootloader key.
1. [OEM] Flash TFW Public Key and a bootloader key.
-
1. [TFW/TEE] Generate a unique attestation key pair and get a
certificate for the device.
Step 4: Set up trust anchors in devices
- 2. [TFW/TEE] Generate a unique attestation key pair and get a
certificate for the device.
1. [TFW/TEE] Store the key and certificate encrypted with the Step 4: Set up Trust Anchors in devices
bootloader key
- 1. [TFW/TEE] Store the key and certificate encrypted with the
bootloader key
1. [TEE vendor or OEM] Store trusted CA certificate list into 2. [TEE vendor or OEM] Store trusted CA certificate list into
devices devices
6. TEEP Broker 6. TEEP Broker
A TEE and TAs do not generally have the capability to communicate to A TEE and TAs do not generally have the capability to communicate to
the outside of the hosting device. For example, GlobalPlatform the outside of the hosting device. For example, GlobalPlatform
[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. The TEE interaction will vary according to for the message exchange.
different TEEs. In order for a Client Application to transparently The TEE interaction will vary according to different TEEs. In order
support different TEEs, it is imperative to have a common interface for a Client Application to transparently support different TEEs, it
for a Client Application to invoke for exchanging messages with TEEs. is imperative to have a common interface for a Client Application to
invoke for exchanging messages with TEEs.
A shared agent comes to meet this need. An agent is an application A shared agent comes to meet this need. An agent is an application
running in the REE of the device or an SDK that facilitates running in the REE of the device or an SDK that facilitates
communication between a TAM and a TEE. It also provides interfaces communication between a TAM and a TEE. It also provides interfaces
for TAM SDK or Client Applications to query and trigger TA for Client Applications to query and trigger TA installation that the
installation that the application needs to use. application needs to use.
This interface for Client Applications may be commonly an OS service It isn't always that a Client Application directly calls such an
call for an REE OS. A Client Application interacts with a TAM, and agent to interact with a TEE. A REE Application Installer might
turns around to pass messages received from TAM to agent. carry out TEE and TAM interaction to install all required TAs that a
Client Application depends. A Client Application may have a metadata
file that describes the TAs it depends on and the associated TAM that
each TA installation goes to use. The REE Application Installer can
inspect the application metadata file and installs TAs on behalf of
the Client Application without requiring the Client Application to
run first.
In all cases, a Client Application needs to be able to identify an This interface for Client Applications or Application Installers may
agent that it can use. be commonly an OS service call for an REE OS. A Client Application
or an Application Installer interacts with the device TEE and the
TAMs.
6.1. Role of the Agent 6.1. Role of the Agent
An agent abstracts the message exchanges with the TEE in a device. An agent abstracts the message exchanges with the TEE in a device.
The input data is originated from a TAM to which a Client Application The input data is originated from a TAM or the first initialization
connects. A Client Application may also directly call an Agent for call to trigger a TA installation.
some TA query functions.
The agent may internally process a message from a TAM. At least, it The agent may internally process a message from a TAM. At least, it
needs to know where to route a message, e.g., TEE instance. It does needs to know where to route a message, e.g., TEE instance. It does
not need to process or verify message content. not need to process or verify message content.
The agent returns TEE / TFW generated response messages to the The agent returns TEE / TFW generated response messages to the
caller. The agent is not expected to handle any network connection caller. The agent is not expected to handle any network connection
with an application or TAM. with an application or TAM.
The agent only needs to return an agent error message if the TEE is The agent only needs to return an agent error message if the TEE is
skipping to change at page 23, line 25 skipping to change at page 28, line 17
Multiple independent agent providers can be used as long as they have Multiple independent agent providers can be used as long as they have
standard interface to a Client Application or TAM SDK. Only one standard interface to a Client Application or TAM SDK. Only one
agent is expected in a device. agent is expected in a device.
TAM providers are generally expected to provide an SDK for SP TAM providers are generally expected to provide an SDK for SP
applications to interact with an agent for the TAM and TEE applications to interact with an agent for the TAM and TEE
interaction. interaction.
7. Attestation 7. Attestation
7.1. Attestation Hierarchy Attestation is the process through which one entity (an attestor)
presents a series of claims to another entity (a verifier), and
provides sufficient proof that the claims are true. Different
verifiers may have different standards for attestation proofs and not
all attestations are acceptable to every verifier. TEEP attestations
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.
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
properities, was built by a particular manufacturer, or is executing
a particular TA. Other claims are possible; this architecture
specification does not limit the attestation claims, but defines a
minimal set of claims required for TEEP to operate properly.
Extensions to these claims are possible, but are not defined in the
TEEP specifications. Other standards or groups may define the format
and semantics of extended claims. The TEEP specification defines the
claims format such that these extended claims may be easily included
in a TEEP attestation message.
As of the writing of this specification, device and TEE attestations
have not been standardized across the market. Different devices,
manufacturers, and TEEs support different attestation algorithms and
mechanisms. In order for TEEP to be inclusive, the attestation
format shall allow for both proprietary attestation signatures, as
well as a standardized form of attestation signature. Either form of
attesation signature may be applied to a set of TEEP claims, and both
forms of attestation shall be considered conformant with TEEP.
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
MUST be able to process the TEEP standard attestation format and
attached signature.
The attestation formats and mechanisms described and mandated by TEEP
shall convey a particular set of cryptographic properties based on
minimal assumptions. The cryptographic properties are conveyed by
the attestation; however the assumptions are not conveyed within the
attestation itself.
The assumptions which may apply to an attestation have to do with the
quality of the attestation and the quality and security provided by
the TEE, the device, the manufacturer, or others involved in the
device or TEE ecosystem. Some of the assumptions that might apply to
an attestations include (this may not be a comprehensive list):
- Assumptions regarding the security measures a manufacturer takes
when provisioning keys into devices/TEEs;
- Assumptions regarding what hardware and software components have
access to the Attestation keys of the TEE;
- Assumptions related to the source or local verification of claims
within an attestation prior to a TEE signing a set of claims;
- Assumptions regarding the level of protection afforded to
attestation keys against exfiltration, modification, and side
channel attacks;
- Assumptions regarding the limitations of use applied to TEE
Attestation keys;
- Assumptions regarding the processes in place to discover or detect
TEE breeches; and
- Assumptions regarding the revocation and recovery process of TEE
attestation keys.
TAMs and SPs must be comfortable with the assumptions that are
inherently part of any attestation they accept. Alternatively, any
TAM or SP may choose not to accept an attestation generated from a
particular manufacturer or device's TEE based on the inherent
assumptions. The choice and policy decisions are left up to the
particular TAM/SP.
Some TAMs or SPs may require additional claims in order to properly
authorize a device or TEE. These additional claims may help clear up
any assumptions for which the TAM/SP wants to alleviate. The
specific format for these additional claims are outside the scope of
this specification, but the OTrP protocol SHALL allow these
additional claims to be included in the attestation messages.
The following sub-sections define the cryptographic properties
conveyed by the TEEP attestation, the basic set of TEEP claims
required in a TEEP attestation, the TEEP attestation flow between the
TAM the device TEE, and some implementation examples of how an
attestation key may be realized in a real TEEP device.
7.1. Attestation Cryptographic Properties
The attestation constructed by TEEP must convey certain cryptographic
properties from the attestor to the verifier; in the case of TEEP,
the attestation must convey properties from the device to the TAM
and/or SP. The properties required by TEEP include:
- Non-repudiation, Unique Proof of Source - the cryptographic
digital signature across the attestation, and optionally along
with information in the attestion itself SHALL uniquely identify a
specific TEE in a specific device.
- Integrity of claims - the cryptographic digital signature across
the attestation SHALL cover the entire attesation including all
meta data and all the claims in the attestation, ensuring that the
attestation has not be modified since the TEE signed the
attestation.
Standard public key algorithms such as RSA and ECDSA digital
signatures convey these properties. Group public key algorithms such
as EPID can also convey these properties, if the attestation includes
a unique device identifier and an identifier for the TEE. Other
cryptographic operations used in other attestation schemes may also
convey these properties.
The TEEP standard attestation format SHALL use one of the following
digital signature formats:
- RSA-2048 with SHA-256 or SHA-384 in RSASSA-PKCS1-v1_5 or PSS
format
- RSA-3072 with SHA-256 or SHA-384 in RSASSA-PKCS1-v1_5 or PSS
format
- ECDSA-256 using NIST P256 curve using SHA-256
- ECDSA-384 using NIST P384 curve using SHA-384
- HashEdDSA using Ed25519 with SHA-512 (Ed25519ph in RFC8032) and
context="TEEP Attestation"
- EdDSA using Ed448 with SHAK256 (Ed448ph in RFC8032) and
context="TEEP Attestation"
All TAMs and SPs MUST be able to accept attestations using these
algorithms, contingent on their acceptance of the assumptions implied
by the attestations.
7.2. TEEP Attestation Structure
For a TEEP attestation to be useful, it must contain an information
set allowing the TAM and/or SP to assess the attestation and make a
related security policy decision. The structure of the TEEP
attestation is shown in the diagram below.
+------(Signed By)-----------+
| |
/--------------------------\ V
+---------------+-------------+--------------------------+
| Attestation | The | The |
| Header | Claims | Attestation Signature(s) |
+---------------+-------------+--------------------------+
|
|
+------------+--(Contains)------+-----------------+--------------+
| | | | |
V V V V V
+-------------+ +-------------+ +----------+ +-----------------+ +------------+
| Device | | TEE | | | | Action or | | Additional |
| Identifying | | Identifying | | Liveness | | Operation | | or optional|
| Info | | Info | | Proof | | Specific claims | | Claims |
+-------------+ +-------------+ +----------+ +-----------------+ +------------+
Figure 8: Structure of TEEP Attestation
The Attestation Header SHALL identify the "Attestation Type" and the
"Attestation Signature Type" along with an "Attestation Format
Version Number." The "Attestation Type" identifies the minimal set
of claims that MUST be included in the attestation; this is an
identifier for a profile that defines the claims that should be
included in the attestation as part of the "Action or Operation
Specific Claims." The "Attestation Signature Type" identifies the
type of attestation signature that is attached. The type of
attestation signature SHALL be one of the standard signatures types
identified by an IANA number, a proprietary signature type identified
by an IANA number, or the generic "Proprietary Signature" with an
accompanying proprietary identifier. Not all TAMs may be able to
process proprietary signatures.
The claims in the attestation are set of mandatory and optional
claims. The claims themselves SHALL be defined in an attestation
claims dictionary. See the next section on TEEP Attestation Claims.
Claims are grouped in profiles under an identifier (Attestation
Type), however all attestations require a minimal set of claims which
includes:
- Device Identifying Info: TEEP attestations must uniquely identify
a device to the TAM and SP. This identifier allows the TAM/SP to
provide services unique to the device, such as managing installed
TAs, and providing subscriptions to services, and locating device-
specific keying material to communicate wiht or authenticate the
device. Additionally, device manufacturer information must be
provided to provide better universal uniqueness qualities without
requiring globally unique identifiers for all devices.
- TEE Identifying info: The type of TEE that generated this
attestation must be identified. Standard TEE types are identified
by an IANA number, but also must include version identification
information such as the hardware, firmware, and software version
of the TEE, as applicable by the TEE type. Structure to the
version number is required.TEE manufacturer information for the
TEE is required in order to disambiguate the same TEE type created
by different manufacturers and resolve potential assumptions
around manufacturer provisioning, keying and support for the TEE.
- Liveness Proof: a claim that includes liveness information SHALL
be included which may be a large nonce or may be a timestamp and
short nonce.
- Action Specific Claims: Certain attestation types shall include
specific claims. For example an attestation from a specific TA
shall include a measurement, version and signing public key for
the TA.
- Additional Claims: (Optional - May be empty set) A TAM or SP may
require specific additional claims in order to address potential
assumptions, such as the requirement that a device's REE performed
a secure boot, or that the device is not currenlty in a debug or
non-productions state. A TAM may require a device to provide a
device health attestation that may include some claims or
measurements about the REE. These claims are TAM specific.
7.3. TEEP Attestation Claims
TEEP requires a set of attestation claims that provide sufficient
evidence to the TAM and/or SP that the device and its TEE meet
certain minimal requirements. Because attestation formats are not
yet broadly standardized across the industry, standardization work is
currently ongoing, and it is expected that extensions to the
attestation claims will be required as new TEEs and devices are
created, the set of attestation claims required by TEEP SHALL be
defined in an IANA registry. That registry SHALL be defined in the
OTrP protocol with sufficient elements to address basic TEEP claims,
expected new standard claims (for example from
https://www.ietf.org/id/draft-mandyam-eat-01.txt), and proprietary
claim sets.
7.4. TEEP Attestation Flow
Attesations are required in TEEP under the following flows:
- When a TEE responds with device state information (dsi) to the TAM
or SP, including a "GetDeviceState" response, "InstallTA"
response, etc.
- When a new key pair is generated for a TA-to-TAM or TA-to-SP
communication, the keypair must be covered by an attestation,
including "CreateSecurityDomain" response, "UpdateSecurityDomain"
response, etc.
7.5. Attestation Key Example
The attestation hierarchy and seed required for TAM protocol The attestation hierarchy and seed required for TAM protocol
operation must be built into the device at manufacture. Additional operation must be built into the device at manufacture. Additional
TEEs can be added post-manufacture using the scheme proposed, but it TEEs can be added post-manufacture using the scheme proposed, but it
is outside of the current scope of this document to detail that. is outside of the current scope of this document to detail that.
It should be noted that the attestation scheme described is based on It should be noted that the attestation scheme described is based on
signatures. The only decryption that may take place is through the signatures. The only decryption that may take place is through the
use of a bootloader key. use of a bootloader key.
A boot module generated attestation can be optional where the A boot module generated attestation can be optional where the
starting point of device attestation can be at TEE certificates. A starting point of device attestation can be at TEE certificates. A
TAM can define its policies on what kinds of TEE it trusts if TFW TAM can define its policies on what kinds of TEE it trusts if TFW
attestation is not included during the TEE attestation. attestation is not included during the TEE attestation.
7.1.1. Attestation Hierarchy Establishment: Manufacture 7.5.1. Attestation Hierarchy Establishment: Manufacture
During manufacture the following steps are required: During manufacture the following steps are required:
1. A device-specific TFW key pair and certificate are burnt into the 1. A device-specific TFW key pair and certificate are burnt into the
device. This key pair will be used for signing operations device. This key pair will be used for signing operations
performed by the boot module. performed by the boot module.
2. TEE images are loaded and include a TEE instance-specific key 2. TEE images are loaded and include a TEE instance-specific key
pair and certificate. The key pair and certificate are included pair and certificate. The key pair and certificate are included
in the image and covered by the code signing hash. in the image and covered by the code signing hash.
3. The process for TEE images is repeated for any subordinate TEEs, 3. The process for TEE images is repeated for any subordinate TEEs,
which are additional TEEs after the root TEE that some devices which are additional TEEs after the root TEE that some devices
have. have.
7.1.2. Attestation Hierarchy Establishment: Device Boot 7.5.2. Attestation Hierarchy Establishment: Device Boot
During device boot the following steps are required: During device boot the following steps are required:
1. The boot module releases the TFW private key by decrypting it 1. The boot module releases the TFW private key by decrypting it
with the bootloader key. with the bootloader key.
2. The boot module verifies the code-signing signature of the active 2. The boot module verifies the code-signing signature of the active
TEE and places its TEE public key into a signing buffer, along TEE and places its TEE public key into a signing buffer, along
with its identifier for later access. For a TEE non-compliant to with its identifier for later access. For a TEE non-compliant to
this architecture, the boot module leaves the TEE public key this architecture, the boot module leaves the TEE public key
field blank. field blank.
3. The boot module signs the signing buffer with the TFW private 3. The boot module signs the signing buffer with the TFW private
key. key.
4. Each active TEE performs the same operation as the boot module, 4. Each active TEE performs the same operation as the boot module,
building up their own signed buffer containing subordinate TEE building up their own signed buffer containing subordinate TEE
information. information.
7.1.3. Attestation Hierarchy Establishment: TAM 7.5.3. Attestation Hierarchy Establishment: TAM
Before a TAM can begin operation in the marketplace, it must obtain a Before a TAM can begin operation in the marketplace, it must obtain a
TAM certificate from a CA that is registered in the trust store of TAM certificate from a CA that is registered in the trust store of
devices. In this way, the TEE can check the intermediate and root CA devices. In this way, the TEE can check the intermediate and root CA
and verify that it trusts this TAM to perform operations on the TEE. and verify that it trusts this TAM to perform operations on the TEE.
8. Algorithm and Attestation Agility 8. Algorithm and Attestation Agility
RFC 7696 [RFC7696] outlines the requirements to migrate from one RFC 7696 [RFC7696] outlines the requirements to migrate from one
mandatory-to-implement algorithm suite to another over time. This mandatory-to-implement algorithm suite to another over time. This
feature is also known as crypto agility. Protocol evolution is feature is also known as crypto agility. Protocol evolution is
greatly simplified when crypto agility is already considered during greatly simplified when crypto agility is already considered during
the design of the protocol. In the case of Open Trust Protocol the design of the protocol. In the case of the Open Trust Protocol
(OTrP) the diverse range of use cases, from trusted app updates for (OTrP) the diverse range of use cases, from trusted app updates for
smart phones and tablets to updates of code on higher-end IoT smart phones and tablets to updates of code on higher-end IoT
devices, creates the need for different mandatory-to-implement devices, creates the need for different mandatory-to-implement
algorithms already from the start. algorithms already from the start.
Crypto agility in the OTrP concerns the use of symmetric as well as Crypto agility in the OTrP concerns the use of symmetric as well as
asymmetric algorithms. Symmetric algorithms are used for encryption asymmetric algorithms. Symmetric algorithms are used for encryption
of content whereas the asymmetric algorithms are mostly used for of content whereas the asymmetric algorithms are mostly used for
signing messages. signing messages.
skipping to change at page 26, line 41 skipping to change at page 36, line 41
certificate, or revoked TAM certificate. Since OCSP stapling certificate, or revoked TAM certificate. Since OCSP stapling
includes signature generation time, certificate validity dates are includes signature generation time, certificate validity dates are
compared to the current time. compared to the current time.
9.7. Certificate Renewal 9.7. Certificate Renewal
TFW and TEE device certificates are expected to be long lived, longer TFW and TEE device certificates are expected to be long lived, longer
than the lifetime of a device. A TAM certificate usually has a than the lifetime of a device. A TAM certificate usually has a
moderate lifetime of 2 to 5 years. A TAM should get renewed or moderate lifetime of 2 to 5 years. A TAM should get renewed or
rekeyed certificates. The root CA certificates for a TAM, which are rekeyed certificates. The root CA certificates for a TAM, which are
embedded into the trust anchor store in a device, should have long embedded into the Trust Anchor store in a device, should have long
lifetimes that don't require device trust anchor update. On the lifetimes that don't require device Trust Anchor update. On the
other hand, it is imperative that OEMs or device providers plan for other hand, it is imperative that OEMs or device providers plan for
support of trust anchor update in their shipped devices. support of Trust Anchor update in their shipped devices.
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. Acknowledgements
The authors thank Dave Thaler for his very thorough review and many The authors thank Dave Thaler for his very thorough review and many
important suggestions. Most content of this document is split from a important suggestions. Most content of this document is split from a
previously combined OTrP protocol document previously combined OTrP protocol document
skipping to change at page 27, line 37 skipping to change at page 37, line 37
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-01 (work in progress), July 2018. opentrustprotocol-02 (work in progress), October 2018.
[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management
Requirements", RFC 6024, DOI 10.17487/RFC6024, October
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 Appendix A. History
RFC EDITOR: PLEASE REMOVE THIS SECTION RFC EDITOR: PLEASE REMOVE THIS SECTION
 End of changes. 67 change blocks. 
183 lines changed or deleted 669 lines changed or added

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