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.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |