< draft-ietf-teep-architecture-09.txt   draft-ietf-teep-architecture-10.txt >
TEEP M. Pei TEEP M. Pei
Internet-Draft Symantec Internet-Draft Broadcom
Intended status: Informational H. Tschofenig Intended status: Informational H. Tschofenig
Expires: December 14, 2020 Arm Limited Expires: December 21, 2020 Arm Limited
D. Thaler D. Thaler
Microsoft Microsoft
D. Wheeler D. Wheeler
Intel Intel
June 12, 2020 June 19, 2020
Trusted Execution Environment Provisioning (TEEP) Architecture Trusted Execution Environment Provisioning (TEEP) Architecture
draft-ietf-teep-architecture-09 draft-ietf-teep-architecture-10
Abstract Abstract
A Trusted Execution Environment (TEE) is an environment that enforces A Trusted Execution Environment (TEE) is an environment that enforces
that any code within that environment cannot be tampered with, and that any code within that environment cannot be tampered with, and
that any data used by such code cannot be read or tampered with by that any data used by such code cannot be read or tampered with by
any code outside that environment. This architecture document any code outside that environment. This architecture document
motivates the design and standardization of a protocol for managing motivates the design and standardization of a protocol for managing
the lifecycle of trusted applications running inside such a TEE. the lifecycle of trusted applications running inside such a TEE.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 14, 2020. This Internet-Draft will expire on December 21, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 37 skipping to change at page 2, line 37
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 8 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 8
3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 8 3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 8
3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 8 3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 8
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. System Components . . . . . . . . . . . . . . . . . . . . 8 4.1. System Components . . . . . . . . . . . . . . . . . . . . 8
4.2. Multiple TEEs in a Device . . . . . . . . . . . . . . . . 11 4.2. Multiple TEEs in a Device . . . . . . . . . . . . . . . . 11
4.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 13 4.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 13
4.4. Untrusted Apps, Trusted Apps, and Personalization Data . 14 4.4. Untrusted Apps, Trusted Apps, and Personalization Data . 14
4.4.1. Example: Application Delivery Mechanisms in Intel SGX 16 4.4.1. Example: Application Delivery Mechanisms in Intel SGX 15
4.4.2. Example: Application Delivery Mechanisms in Arm 4.4.2. Example: Application Delivery Mechanisms in Arm
TrustZone . . . . . . . . . . . . . . . . . . . . . . 16 TrustZone . . . . . . . . . . . . . . . . . . . . . . 16
4.5. Entity Relations . . . . . . . . . . . . . . . . . . . . 17 4.5. Entity Relations . . . . . . . . . . . . . . . . . . . . 16
5. Keys and Certificate Types . . . . . . . . . . . . . . . . . 18 5. Keys and Certificate Types . . . . . . . . . . . . . . . . . 18
5.1. Trust Anchors in a TEEP Agent . . . . . . . . . . . . . . 20 5.1. Trust Anchors in a TEEP Agent . . . . . . . . . . . . . . 19
5.2. Trust Anchors in a TEE . . . . . . . . . . . . . . . . . 20 5.2. Trust Anchors in a TEE . . . . . . . . . . . . . . . . . 20
5.3. Trust Anchors in a TAM . . . . . . . . . . . . . . . . . 20 5.3. Trust Anchors in a TAM . . . . . . . . . . . . . . . . . 20
5.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 20 5.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 20
5.5. Message Security . . . . . . . . . . . . . . . . . . . . 21 5.5. Message Security . . . . . . . . . . . . . . . . . . . . 20
6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 21 6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 21 6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 21
6.2. TEEP Broker Implementation Consideration . . . . . . . . 22 6.2. TEEP Broker Implementation Consideration . . . . . . . . 22
6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 22 6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 22
6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 23 6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 22
7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Information Required in TEEP Claims . . . . . . . . . . . 24 7.1. Information Required in TEEP Claims . . . . . . . . . . . 24
8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 25 8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 26 9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 25
9.2. Data Protection at TAM and TEE . . . . . . . . . . . . . 26 9.2. Data Protection . . . . . . . . . . . . . . . . . . . . . 26
9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 26 9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 26
9.4. Compromised CA . . . . . . . . . . . . . . . . . . . . . 27 9.4. Compromised CA . . . . . . . . . . . . . . . . . . . . . 27
9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 27 9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 27
9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 27 9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 27
9.7. Certificate Expiry and Renewal . . . . . . . . . . . . . 28 9.7. Certificate Expiry and Renewal . . . . . . . . . . . . . 28
9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 28 9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 28
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
13. Informative References . . . . . . . . . . . . . . . . . . . 29 13. Informative References . . . . . . . . . . . . . . . . . . . 29
skipping to change at page 3, line 44 skipping to change at page 3, line 44
applications or data on the device increases. As an example, applications or data on the device increases. As an example,
exposure of emails from a mail client is likely to be of concern to exposure of emails from a mail client is likely to be of concern to
its owner, but a compromise of a banking application raises even its owner, but a compromise of a banking application raises even
greater concerns. greater concerns.
The Trusted Execution Environment (TEE) concept is designed to The Trusted Execution Environment (TEE) concept is designed to
execute applications in a protected environment that enforces that execute applications in a protected environment that enforces that
any code within that environment cannot be tampered with, and that any code within that environment cannot be tampered with, and that
any data used by such code cannot be read or tampered with by any any data used by such code cannot be read or tampered with by any
code outside that environment, including by a commodity operating code outside that environment, including by a commodity operating
system (if present). system (if present). In a system with multiple TEEs, this also means
that code in one TEE cannot be read or tampered with by code in the
other TEE.
This separation reduces the possibility of a successful attack on This separation reduces the possibility of a successful attack on
application components and the data contained inside the TEE. application components and the data contained inside the TEE.
Typically, application components are chosen to execute inside a TEE Typically, application components are chosen to execute inside a TEE
because those application components perform security sensitive because those application components perform security sensitive
operations or operate on sensitive data. An application component operations or operate on sensitive data. An application component
running inside a TEE is referred to as a Trusted Application (TA), running inside a TEE is referred to as a Trusted Application (TA),
while an application running outside any TEE is referred to as an while an application running outside any TEE, i.e., in the Rich
Untrusted Application. In the example of a banking application, code Execution Environment (REE), is referred to as an Untrusted
that relates to the authentication protocol could reside in a TA Application. In the example of a banking application, code that
while the application logic including HTTP protocol parsing could be relates to the authentication protocol could reside in a TA while the
contained in the Untrusted Application. In addition, processing of application logic including HTTP protocol parsing could be contained
credit card numbers or account balances could be done in a TA as it in the Untrusted Application. In addition, processing of credit card
is sensitive data. The precise code split is ultimately a decision numbers or account balances could be done in a TA as it is sensitive
of the developer based on the assets he or she wants to protect data. The precise code split is ultimately a decision of the
according to the threat model. developer based on the assets he or she wants to protect according to
the threat model.
TEEs use hardware enforcement combined with software protection to TEEs use hardware enforcement combined with software protection to
secure TAs and its data. TEEs typically offer a more limited set of secure TAs and its data. TEEs typically offer a more limited set of
services to TAs than is normally available to Untrusted Applications. services to TAs than is normally available to Untrusted Applications.
Not all TEEs are the same, however, and different vendors may have Not all TEEs are the same, however, and different vendors may have
different implementations of TEEs with different security properties, different implementations of TEEs with different security properties,
different features, and different control mechanisms to operate on different features, and different control mechanisms to operate on
TAs. Some vendors may themselves market multiple different TEEs with TAs. Some vendors may themselves market multiple different TEEs with
different properties attuned to different markets. A device vendor different properties attuned to different markets. A device vendor
skipping to change at page 5, line 26 skipping to change at page 5, line 28
- A Device Administrator wants to remove a TA from a device's TEE if - A Device Administrator wants to remove a TA from a device's TEE if
the TA developer is no longer maintaining that TA, when the TA has the TA developer is no longer maintaining that TA, when the TA has
been revoked or is not used for other reasons anymore (e.g., due been revoked or is not used for other reasons anymore (e.g., due
to an expired subscription). to an expired subscription).
- A TA developer wants to define the relationship between - A TA developer wants to define the relationship between
cooperating TAs under the TA developer's control, and specify cooperating TAs under the TA developer's control, and specify
whether the TAs can communicate, share data, and/or share key whether the TAs can communicate, share data, and/or share key
material. material.
Note: The TA developer requires the help of a TAM and most likely the
Device Administrator to provision the Trusted Applications to remote
devices and the TEEP protocol exchanges messages between a TAM and a
TEEP Agent via a TEEP Broker.
2. Terminology 2. Terminology
The following terms are used: The following terms are used:
- Device: A physical piece of hardware that hosts one or more TEEs, - Device: A physical piece of hardware that hosts one or more TEEs,
often along with a Rich Execution Environment. A device contains often along with a REE. A device contains a default list of Trust
a default list of Trust Anchors that identify entities (e.g., Anchors that identify entities (e.g., TAMs) that are trusted by
TAMs) that are trusted by the device. This list is normally set the device. This list is normally set by the device manufacturer,
by the device manufacturer, and may be governed by the device's and may be governed by the device's network carrier when it is a
network carrier when it is a mobile device. The list of Trust mobile device. The list of Trust Anchors is normally modifiable
Anchors is normally modifiable by the device's owner or Device by the device's owner or Device Administrator. However the device
Administrator. However the device manufacturer or network carrier manufacturer or network carrier (in the mobile device case) may
(in the mobile device case) may restrict some modifications, for restrict some modifications, for example, by not allowing the
example, by not allowing the manufacturer or carrier's Trust manufacturer or carrier's Trust Anchor to be removed or disabled.
Anchor to be removed or disabled.
- Device Administrator: An entity that is responsible for - Device Administrator: An entity that is responsible for
administration of a device, which could be the device owner. A administration of a device, which could be the Device Owner. A
Device Administrator has privileges on the device to install and Device Administrator has privileges on the device to install and
remove Untrusted Applications and TAs, approve or reject Trust remove Untrusted Applications and TAs, approve or reject Trust
Anchors, and approve or reject TA developers, among possibly other Anchors, and approve or reject TA developers, among possibly other
privileges on the device. A Device Administrator can manage the privileges on the device. A Device Administrator can manage the
list of allowed TAMs by modifying the list of Trust Anchors on the list of allowed TAMs by modifying the list of Trust Anchors on the
device. Although a Device Administrator may have privileges and device. Although a Device Administrator may have privileges and
device-specific controls to locally administer a device, the device-specific controls to locally administer a device, the
Device Administrator may choose to remotely administer a device Device Administrator may choose to remotely administer a device
through a TAM. through a TAM.
skipping to change at page 6, line 25 skipping to change at page 6, line 22
administration rights. In this case, the enterprise appoints a administration rights. In this case, the enterprise appoints a
Device Administrator that is not the device owner. Device Administrator that is not the device owner.
- Device User: A human being that uses a device. Many devices have - Device User: A human being that uses a device. Many devices have
a single device user. Some devices have a primary device user a single device user. Some devices have a primary device user
with other human beings as secondary device users (e.g., parent with other human beings as secondary device users (e.g., parent
allowing children to use their tablet or laptop). Other devices allowing children to use their tablet or laptop). Other devices
are not used by a human being and hence have no device user. are not used by a human being and hence have no device user.
Relates to Device Owner and Device Administrator. Relates to Device Owner and Device Administrator.
- Raw Public Key (RPK): The RPK only consists of the
SubjectPublicKeyInfo structure of a PKIX certificate that carries
the parameters necessary to describe the public key. Other
serialization formats that do not rely on ASN.1 may also be used.
- Rich Execution Environment (REE): An environment that is provided - Rich Execution Environment (REE): An environment that is provided
and governed by a typical OS (e.g., Linux, Windows, Android, iOS), and governed by a typical OS (e.g., Linux, Windows, Android, iOS),
potentially in conjunction with other supporting operating systems potentially in conjunction with other supporting operating systems
and hypervisors; it is outside of any TEE. This environment and and hypervisors; it is outside of any TEE. This environment and
applications running on it are considered untrusted (or more applications running on it are considered untrusted (or more
precisely, less trusted than a TEE). precisely, less trusted than a TEE).
- Trust Anchor: As defined in [RFC6024] and - Trust Anchor: As defined in [RFC6024] and
[I-D.ietf-suit-manifest], "A trust anchor represents an [I-D.ietf-suit-manifest], "A trust anchor represents an
authoritative entity via a public key and associated data. The authoritative entity via a public key and associated data. The
public key is used to verify digital signatures, and the public key is used to verify digital signatures, and the
associated data is used to constrain the types of information for associated data is used to constrain the types of information for
which the trust anchor is authoritative." The Trust Anchor may be which the trust anchor is authoritative." The Trust Anchor may be
a certificate or it may be a raw public key along with additional a certificate or it may be a raw public key along with additional
data if necessary such as its public key algorithm and parameters. data if necessary such as its public key algorithm and parameters.
- Trust Anchor Store: As defined in [RFC6024], "A trust anchor store - Trust Anchor Store: As defined in [RFC6024], "A trust anchor store
is a set of one or more trust anchors stored in a device. A is a set of one or more trust anchors stored in a device. A
device may have more than one trust anchor store, each of which device may have more than one trust anchor store, each of which
may be used by one or more applications." As noted in may be used by one or more applications." As noted in
[I-D.ietf-suit-manifest], a trust anchor store must resist [I-D.ietf-suit-manifest], a Trust Anchor Store must resist
modification against unauthorized insertion, deletion, and modification against unauthorized insertion, deletion, and
modification. modification.
- Trusted Application (TA): An application component that runs in a - Trusted Application (TA): An application (or, in some
TEE. implementations, an application component) that runs in a TEE.
- Trusted Application (TA) Developer: An entity that wishes to - Trusted Application (TA) Developer: An entity that develops one or
provide functionality on devices that requires the use of one or more TAs.
more Trusted Applications. The TA developer signs the TA binary
(or more precisely the manifest associated with the TA binary) or - Trusted Application (TA) Signer: An entity that signs a TA with a
uses another entity on his or her behalf to get the TA binary key that a TEE will trust. The signer might or might not be the
signed. (A TA binary may also be encrypted by the developer or by same entity as the TA Developer. For example, a TA might be
some third party service.) For editorial reasons, we assume that signed (or re-signed) by a Device Administrator if the TEE will
the TA developer signs the TA binary ignoring the distinction only trust the Device Administrator. A TA might also be
between the binary and the manifest and by simplifying the case encrypted, if the code is considered confidential.
where the TA developer outsources signing and encryption to a
third party entity or service.
- Trusted Application Manager (TAM): An entity that manages Trusted - Trusted Application Manager (TAM): An entity that manages Trusted
Applications (TAs) running in TEEs of various devices. Applications (TAs) running in TEEs of various devices.
- Trusted Execution Environment (TEE): An execution environment that - Trusted Execution Environment (TEE): An execution environment that
enforces that only authorized code can execute within the TEE, and enforces that only authorized code can execute within the TEE, and
data used by that code cannot be read or tampered with by code data used by that code cannot be read or tampered with by code
outside the TEE. A TEE also generally has a device unique outside the TEE. A TEE also generally has a device unique
credential that cannot be cloned. There are multiple technologies credential that cannot be cloned. There are multiple technologies
that can be used to implement a TEE, and the level of security that can be used to implement a TEE, and the level of security
achieved varies accordingly. In addition, TEEs typically use an achieved varies accordingly. In addition, TEEs typically use an
isolation mechanism between Trusted Applications to ensure that isolation mechanism between Trusted Applications to ensure that
one TA cannot read, modify or delete the data and code of another one TA cannot read, modify or delete the data and code of another
TA. TA.
- Untrusted Application: An application running in a Rich Execution - Untrusted Application: An application running in an REE. An
Environment. Untrusted Application might depend on one or more TAs.
3. Use Cases 3. Use Cases
3.1. Payment 3.1. Payment
A payment application in a mobile device requires high security and A payment application in a mobile device requires high security and
trust about the hosting device. Payments initiated from a mobile trust in the hosting device. Payments initiated from a mobile device
device can use a Trusted Application to provide strong identification can use a Trusted Application to provide strong identification and
and proof of transaction. proof of transaction.
For a mobile payment application, some biometric identification For a mobile payment application, some biometric identification
information could also be stored in a TEE. The mobile payment information could also be stored in a TEE. The mobile payment
application can use such information for unlocking the phone and for application can use such information for unlocking the device and for
local identification of the user. local identification of the user.
A trusted user interface (UI) may be used in a mobile device to A trusted user interface (UI) may be used in a mobile device to
prevent malicious software from stealing sensitive user input data. prevent malicious software from stealing sensitive user input data.
Such an implementation often relies on a TEE for providing access to Such an implementation often relies on a TEE for providing access to
peripherals, such as PIN input. peripherals, such as PIN input.
3.2. Authentication 3.2. Authentication
For better security of authentication, a device may store its keys For better security of authentication, a device may store its keys
skipping to change at page 9, line 28 skipping to change at page 9, line 28
| | | +---+ +---+ | +-------+ | | | Device Administrator | | | +---+ +---+ | +-------+ | | | Device Administrator
| | +-------------+ | App-1 | | | | | | +-------------+ | App-1 | | | |
| | | | | | | | | | | | | |
| +--------------------| |---+ | | | +--------------------| |---+ | |
| | |--------+ | | | |--------+ |
| +-------+ | | +-------+ |
+-------------------------------------------+ +-------------------------------------------+
Figure 1: Notional Architecture of TEEP Figure 1: Notional Architecture of TEEP
- TA developers and Device Administrators utilize the services of a - TA Signers and Device Administrators utilize the services of a TAM
TAM to manage TAs on devices. TA developers do not directly to manage TAs on devices. TA Signers do not directly interact
interact with devices. Device Administators may elect to use a with devices. Device Administators may elect to use a TAM for
TAM for remote administration of TAs instead of managing each remote administration of TAs instead of managing each device
device directly. directly.
- Trusted Application Manager (TAM): A TAM is responsible for - Trusted Application Manager (TAM): A TAM is responsible for
performing lifecycle management activity on TAs on behalf of TA performing lifecycle management activity on TAs on behalf of TA
developers and Device Administrators. This includes creation and Signers and Device Administrators. This includes creation and
deletion of TAs, and may include, for example, over-the-air deletion of TAs, and may include, for example, over-the-air
updates to keep TAs up-to-date and clean up when a version should updates to keep TAs up-to-date and clean up when a version should
be removed. TAMs may provide services that make it easier for TA be removed. TAMs may provide services that make it easier for TA
developers or Device Administators to use the TAM's service to Signers or Device Administators to use the TAM's service to manage
manage multiple devices, although that is not required of a TAM. multiple devices, although that is not required of a TAM.
The TAM performs its management of TAs on the device through The TAM performs its management of TAs on the device through
interactions with a device's TEEP Broker, which relays messages interactions with a device's TEEP Broker, which relays messages
between a TAM and a TEEP Agent running inside the TEE. As shown between a TAM and a TEEP Agent running inside the TEE. As shown
in Figure 1, the TAM cannot directly contact a TEEP Agent, but in Figure 1, the TAM cannot directly contact a TEEP Agent, but
must wait for the TEEP Broker to contact the TAM requesting a must wait for the TEEP Broker to contact the TAM requesting a
particular service. This architecture is intentional in order to particular service. This architecture is intentional in order to
accommodate network and application firewalls that normally accommodate network and application firewalls that normally
protect user and enterprise devices from arbitrary connections protect user and enterprise devices from arbitrary connections
from external network entities. from external network entities.
A TAM may be publicly available for use by many TA developers, or A TAM may be publicly available for use by many TA Signers, or a
a TAM may be private, and accessible by only one or a limited TAM may be private, and accessible by only one or a limited number
number of TA developers. It is expected that many manufacturers of TA Signers. It is expected that many manufacturers and network
and network carriers will run their own private TAM. carriers will run their own private TAM.
A TA developer or Device Administrator chooses a particular TAM A TA Signer or Device Administrator chooses a particular TAM based
based on whether the TAM is trusted by a device or set of devices. on whether the TAM is trusted by a device or set of devices. The
The TAM is trusted by a device if the TAM's public key is, or TAM is trusted by a device if the TAM's public key is, or chains
chains up to, an authorized Trust Anchor in the device. A TA up to, an authorized Trust Anchor in the device. A TA Signer or
developer or Device Administrator may run their own TAM, but the Device Administrator may run their own TAM, but the devices they
devices they wish to manage must include this TAM's public key/ wish to manage must include this TAM's public key/certificate
certificate, or a certificate it chains up to, in the Trust Anchor [RFC5280], or a certificate it chains up to, in the Trust Anchor
list. Store.
A TA developer or Device Administrator is free to utilize multiple A TA Signer or Device Administrator is free to utilize multiple
TAMs. This may be required for a TA developer to manage multiple TAMs. This may be required for managing TAs on multiple different
different types of devices from different manufacturers, or to types of devices from different manufacturers, or mobile devices
manage mobile devices on different network carriers, since the on different network carriers, since the Trust Anchor Store on
Trust Anchor list on these different devices may contain different these different devices may contain different TAMs. A Device
TAMs. A Device Administrator may be able to add their own TAM's Administrator may be able to add their own TAM's public key or
public key or certificate to the Trust Anchor list on all their certificate to the Trust Anchor Store on all their devices,
devices, overcoming this limitation. overcoming this limitation.
Any entity is free to operate a TAM. For a TAM to be successful, Any entity is free to operate a TAM. For a TAM to be successful,
it must have its public key or certificate installed in a device's it must have its public key or certificate installed in a device's
Trust Anchor list. A TAM may set up a relationship with device Trust Anchor Store. A TAM may set up a relationship with device
manufacturers or network carriers to have them install the TAM's manufacturers or network carriers to have them install the TAM's
keys in their device's Trust Anchor list. Alternatively, a TAM keys in their device's Trust Anchor Store. Alternatively, a TAM
may publish its certificate and allow Device Administrators to may publish its certificate and allow Device Administrators to
install the TAM's certificate in their devices as an after-market- install the TAM's certificate in their devices as an after-market-
action. action.
- TEEP Broker: A TEEP Broker is an application component running in - TEEP Broker: A TEEP Broker is an application component running in
a Rich Execution Environment (REE) that enables the message a Rich Execution Environment (REE) that enables the message
protocol exchange between a TAM and a TEE in a device. A TEEP protocol exchange between a TAM and a TEE in a device. A TEEP
Broker does not process messages on behalf of a TEE, but merely is Broker does not process messages on behalf of a TEE, but merely is
responsible for relaying messages from the TAM to the TEE, and for responsible for relaying messages from the TAM to the TEE, and for
returning the TEE's responses to the TAM. In devices with no REE returning the TEE's responses to the TAM. In devices with no REE
skipping to change at page 11, line 11 skipping to change at page 11, line 11
Broker that runs in an REE). A TEEP Agent in the TEE may parse Broker that runs in an REE). A TEEP Agent in the TEE may parse
requests or forward requests to other processing modules in a TEE, requests or forward requests to other processing modules in a TEE,
which is up to a TEE provider's implementation. A response which is up to a TEE provider's implementation. A response
message corresponding to a TAM request is sent back to the TAM, message corresponding to a TAM request is sent back to the TAM,
again typically relayed via a TEEP Broker. again typically relayed via a TEEP Broker.
- Certification Authority (CA): A CA is an entity that issues - Certification Authority (CA): A CA is an entity that issues
digital certificates (especially X.509 certificates) and vouches digital certificates (especially X.509 certificates) and vouches
for the binding between the data items in a certificate [RFC4949]. for the binding between the data items in a certificate [RFC4949].
Certificates are then used for authenticating a device, a TAM and Certificates are then used for authenticating a device, a TAM and
a TA developer. A device embeds a list of root certificates a TA Signer. A device embeds a list of root certificates (Trust
(Trust Anchors), from trusted CAs that a TAM will be validated Anchors), from trusted CAs that a TAM will be validated against.
against. A TAM will remotely attest a device by checking whether A TAM will remotely attest a device by checking whether a device
a device comes with a certificate from a CA that the TAM trusts. comes with a certificate from a CA that the TAM trusts. The CAs
The CAs do not need to be the same; different CAs can be chosen by do not need to be the same; different CAs can be chosen by each
each TAM, and different device CAs can be used by different device TAM, and different device CAs can be used by different device
manufacturers. manufacturers.
4.2. Multiple TEEs in a Device 4.2. Multiple TEEs in a Device
Some devices might implement multiple TEEs. In these cases, there Some devices might implement multiple TEEs. In these cases, there
might be one shared TEEP Broker that interacts with all the TEEs in might be one shared TEEP Broker that interacts with all the TEEs in
the device. However, some TEEs (for example, SGX [SGX]) present the device. However, some TEEs (for example, SGX [SGX]) present
themselves as separate containers within memory without a controlling themselves as separate containers within memory without a controlling
manager within the TEE. As such, there might be multiple TEEP manager within the TEE. As such, there might be multiple TEEP
Brokers in the Rich Execution Environment, where each TEEP Broker Brokers in the REE, where each TEEP Broker communicates with one or
communicates with one or more TEEs associated with it. more TEEs associated with it.
It is up to the Rich Execution Environment and the Untrusted It is up to the REE and the Untrusted Applications how they select
Applications how they select the correct TEEP Broker. Verification the correct TEEP Broker. Verification that the correct TA has been
that the correct TA has been reached then becomes a matter of reached then becomes a matter of properly verifying TA attestations,
properly verifying TA attestations, which are unforgeable. which are unforgeable.
The multiple TEEP Broker approach is shown in the diagram below. For The multiple TEEP Broker approach is shown in the diagram below. For
brevity, TEEP Broker 2 is shown interacting with only one TAM and brevity, TEEP Broker 2 is shown interacting with only one TAM and
Untrusted Application and only one TEE, but no such limitations are Untrusted Application and only one TEE, but no such limitations are
intended to be implied in the architecture. intended to be implied in the architecture.
+-------------------------------------------+ +-------------------------------------------+
| Device | | Device |
| | TA Developer | | TA Signer
| +-------------+ | | | +-------------+ | |
| | TEE-1 | | | | | TEE-1 | | |
| | +-------+ | +--------+ | +--------+ | | | +-------+ | +--------+ | +--------+ |
| | | TEEP | | | TEEP |------------->| |<-+ | | | TEEP | | | TEEP |------------->| |<-+
| | | Agent |<----------| Broker | | | | | | | Agent |<----------| Broker | | | | TA
| | | 1 | | | 1 |---------+ | | | | | 1 | | | 1 |---------+ | |
| | +-------+ | | | | | | | | | +-------+ | | | | | | |
| | | | |<---+ | | | | | | | | |<---+ | | | |
| | +---+ +---+ | | | | | | +-| TAM-1 | | | +---+ +---+ | | | | | | +-| TAM-1 |Policy
| | |TA1| |TA2| | | |<-+ | | +->| | |<-+ | | |TA1| |TA2| | | |<-+ | | +->| | |<-+
| +-->| | | |<---+ +--------+ | | | | +--------+ | | +-->| | | |<---+ +--------+ | | | | +--------+ |
| | | +---+ +---+ | | | | | | TAM-2 | | | | | +---+ +---+ | | | | | | TAM-2 | |
| | | | | +-------+ | | | +--------+ | | | | | | +-------+ | | | +--------+ |
| | +-------------+ +-----| App-2 |--+ | | ^ | | | +-------------+ +-----| App-2 |--+ | | ^ |
| | +-------+ | | | | Device | | +-------+ | | | | Device
| +--------------------| App-1 | | | | | Administrator | +--------------------| App-1 | | | | | Administrator
| +------| | | | | | | +------| | | | | |
| +-----------|-+ | |---+ | | | | +-----------|-+ | |---+ | | |
| | TEE-2 | | | |--------+ | | | | TEE-2 | | | |--------+ | |
skipping to change at page 13, line 18 skipping to change at page 13, line 18
one or more TEEP Agents and one or more TAMs. The selection of which one or more TEEP Agents and one or more TAMs. The selection of which
TAM to communicate with might be made with or without input from an TAM to communicate with might be made with or without input from an
Untrusted Application, but is ultimately the decision of a TEEP Untrusted Application, but is ultimately the decision of a TEEP
Agent. Agent.
A TEEP Agent is assumed to be able to determine, for any given TA, A TEEP Agent is assumed to be able to determine, for any given TA,
whether that TA is installed (or minimally, is running) in a TEE with whether that TA is installed (or minimally, is running) in a TEE with
which the TEEP Agent is associated. which the TEEP Agent is associated.
Each TA is digitally signed, protecting its integrity, and linking Each TA is digitally signed, protecting its integrity, and linking
the TA back to the signer. The signer is usually the TA developer, the TA back to the TA Signer. The TA Signer is often the TA
but in some cases might be another party that the TA developer Developer, but in some cases might be another party such as a Device
trusts, or a party to whom the code has been licensed (in which case Administrator or other party to whom the code has been licensed (in
the same code might be signed by multiple licensees and distributed which case the same code might be signed by multiple licensees and
as if it were different TAs). distributed as if it were different TAs).
A TA author or signer selects one or more TAMs through which to offer
their TA(s), and communicates the TA(s) to the TAM. In this
document, we use the term "TA developer" to refer to the entity that
selects a TAM and publishes a signed TA to it, independent of whether
the publishing entity is the TA developer or the signer or both.
The TA developer chooses TAMs based upon the markets into which the A TA Signer selects one or more TAMs and communicates the TA(s) to
TAM can provide access. There may be TAMs that provide services to the TAM. For example, the TA Signer might choose TAMs based upon the
specific types of devices, or device operating systems, or specific markets into which the TAM can provide access. There may be TAMs
geographical regions or network carriers. A TA developer may be that provide services to specific types of devices, or device
motivated to utilize multiple TAMs for its service in order to operating systems, or specific geographical regions or network
maximize market penetration and availability on multiple types of carriers. A TA Signer may be motivated to utilize multiple TAMs in
devices. This likely means that the same TA will be available order to maximize market penetration and availability on multiple
through multiple TAMs. types of devices. This means that the same TA will often be
available through multiple TAMs.
When the developer of an Untrusted Application that depends on a TA When the developer of an Untrusted Application that depends on a TA
publishes the Untrusted Application to an app store or other app publishes the Untrusted Application to an app store or other app
repository, the developer optionally binds the Untrusted Application repository, the developer optionally binds the Untrusted Application
with a manifest that identifies what TAMs can be contacted for the with a manifest that identifies what TAMs can be contacted for the
TA. In some situations, a TA may only be available via a single TAM TA. In some situations, a TA may only be available via a single TAM
- this is likely the case for enterprise applications or TA - this is likely the case for enterprise applications or TA Signers
developers serving a closed community. For broad public apps, there serving a closed community. For broad public apps, there will likely
will likely be multiple TAMs in the manifest - one servicing one be multiple TAMs in the manifest - one servicing one brand of mobile
brand of mobile device and another servicing a different device and another servicing a different manufacturer, etc. Because
manufacturer, etc. Because different devices and different different devices and different manufacturers trust different TAMs,
manufacturers trust different TAMs, the manifest can include multiple the manifest can include multiple TAMs that support the required TA.
TAMs that support the required TA.
When a TEEP Broker receives a request from an Untrusted Application When a TEEP Broker receives a request from an Untrusted Application
to install a TA, a list of TAM URIs may be provided for that TA, and to install a TA, a list of TAM URIs may be provided for that TA, and
the request is passed to the TEEP Agent. If the TEEP Agent decides the request is passed to the TEEP Agent. If the TEEP Agent decides
that the TA needs to be installed, the TEEP Agent selects a single that the TA needs to be installed, the TEEP Agent selects a single
TAM URI that is consistent with the list of trusted TAMs provisioned TAM URI that is consistent with the list of trusted TAMs provisioned
on the device, invokes the HTTP transport for TEEP to connect to the on the device, invokes the HTTP transport for TEEP to connect to the
TAM URI, and begins a TEEP protocol exchange. When the TEEP Agent TAM URI, and begins a TEEP protocol exchange. When the TEEP Agent
subsequently receives the TA to install and the TA's manifest subsequently receives the TA to install and the TA's manifest
indicates dependencies on any other trusted components, each indicates dependencies on any other trusted components, each
skipping to change at page 15, line 11 skipping to change at page 15, line 4
Untrusted Application in a REE and one or more TAs in a TEE, as shown Untrusted Application in a REE and one or more TAs in a TEE, as shown
in Figure 2. For most purposes, an Untrusted Application that uses in Figure 2. For most purposes, an Untrusted Application that uses
one or more TAs in a TEE appears no different from any other one or more TAs in a TEE appears no different from any other
Untrusted Application in the REE. However, the way the Untrusted Untrusted Application in the REE. However, the way the Untrusted
Application and its corresponding TAs are packaged, delivered, and Application and its corresponding TAs are packaged, delivered, and
installed on the device can vary. The variations depend on whether installed on the device can vary. The variations depend on whether
the Untrusted Application and TA are bundled together or are provided the Untrusted Application and TA are bundled together or are provided
separately, and this has implications to the management of the TAs in separately, and this has implications to the management of the TAs in
a TEE. In addition to the Untrusted Application and TA(s), the TA(s) a TEE. In addition to the Untrusted Application and TA(s), the TA(s)
and/or TEE may require some additional data to personalize the TA to and/or TEE may require some additional data to personalize the TA to
the TA developer or the device or a user. This personalization data the device or a user. This personalization data may depend on the
may dependent on the type of TEE, a particular TEE instance, the TA, type of TEE, a particular TEE instance, the TA, and even the user of
the TA developer and even the user of the device; an example of the device; an example of personalization data might be a secret
personalization data might be a secret symmetric key used by the TA symmetric key used by the TA to communicate with some service.
to communicate with some service. Implementations must support Implementations must support encryption of personalization data to
encryption of personalization data to preserve the confidentiality of preserve the confidentiality of potentially sensitive data contained
potentially sensitive data contained within it and support integrity within it and support integrity protection of the personalization
protection of the personalization data. Other than the requirement data. Other than the requirement to support confidentiality and
to support confidentiality and integrity protection, the TEEP integrity protection, the TEEP architecture places no limitations or
architecture places no limitations or requirements on the requirements on the personalization data.
personalization data.
There are three possible cases for bundling of an Untrusted There are three possible cases for bundling of an Untrusted
Application, TA(s), and personalization data: Application, TA(s), and personalization data:
1. The Untrusted Application, TA(s), and personalization data are 1. The Untrusted Application, TA(s), and personalization data are
all bundled together in a single package by a TA developer and all bundled together in a single package by a TA Signer and
provided to the TEEP Broker through the TAM. provided to the TEEP Broker through the TAM.
2. The Untrusted Application and the TA(s) are bundled together in a 2. The Untrusted Application and the TA(s) are bundled together in a
single package, which a TAM or a publicly accessible app store single package, which a TAM or a publicly accessible app store
maintains, and the personalization data is separately provided by maintains, and the personalization data is separately provided by
the TA developer's TAM. the TA Signer's TAM.
3. All components are independent. The Untrusted Application is 3. All components are independent. The Untrusted Application is
installed through some independent or device-specific mechanism, installed through some independent or device-specific mechanism,
and the TAM provides the TA and personalization data from the TA and the TAM provides the TA and personalization data from the TA
developer. Delivery of the TA and personalization data may be Signer. Delivery of the TA and personalization data may be
combined or separate. combined or separate.
The TEEP protocol treats each TA, any dependencies the TA has, and The TEEP protocol treats each TA, any dependencies the TA has, and
personalization data as separate components with separate personalization data as separate components with separate
installation steps that are expressed in SUIT manifests, and a SUIT installation steps that are expressed in SUIT manifests, and a SUIT
manifest might contain or reference multiple binaries (see manifest might contain or reference multiple binaries (see
[I-D.ietf-suit-manifest] for more details). The TEEP Agent is [I-D.ietf-suit-manifest] for more details). The TEEP Agent is
responsible for handling any installation steps that need to be responsible for handling any installation steps that need to be
performed inside the TEE, such as decryption of private TA binaries performed inside the TEE, such as decryption of private TA binaries
or personalization data. or personalization data.
skipping to change at page 17, line 17 skipping to change at page 17, line 7
is possible as well, though still more complex than Cases 2 and 3. is possible as well, though still more complex than Cases 2 and 3.
4.5. Entity Relations 4.5. Entity Relations
This architecture leverages asymmetric cryptography to authenticate a This architecture leverages asymmetric cryptography to authenticate a
device to a TAM. Additionally, a TEEP Agent in a device device to a TAM. Additionally, a TEEP Agent in a device
authenticates a TAM. The provisioning of Trust Anchors to a device authenticates a TAM. The provisioning of Trust Anchors to a device
may be different from one use case to the other. A Device may be different from one use case to the other. A Device
Administrator may want to have the capability to control what TAs are Administrator may want to have the capability to control what TAs are
allowed. A device manufacturer enables verification by one or more allowed. A device manufacturer enables verification by one or more
TAMs and by TA developers; it may embed a list of default Trust TAMs and by TA Signers; it may embed a list of default Trust Anchors
Anchors into the TEEP Agent and TEE for TAM and TA trust into the TEEP Agent and TEE for TAM trust verification and TA
verification. signature verification.
(App Developers) (App Store) (TAM) (Device with TEE) (CAs) (App Developers) (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: | | | |
| | | | | | | |
(a) Untrusted | | | | (a) Untrusted | | | |
App - 2a. Supply --> | --- 3. Install ------> | | App - 2a. Supply --> | --- 3. Install ------> | |
| | | | | | | |
(b) TA -- 2b. Supply ----------> | 4. Messaging-->| | (b) TA -- 2b. Supply ----------> | 4. Messaging-->| |
| | | | | | | |
Figure 3: Developer Experience Figure 3: Example Developer Experience
Note that Figure 3 shows the view from a TA developer point of view. Figure 3 shows an example where the same developer builds and signs
The TA developer signs the TA or is a related entity trusted to sign two applications: 1) an Untrusted Application; 2) a TA that provides
the developer-created TAs. some security functions to be run inside a TEE.
Figure 3 shows an example where the same developer builds two At step 2, the developer uploads the Untrusted Application (2a) to an
applications: 1) an Untrusted Application; 2) a TA that provides some Application Store. In this example, the developer is also the TA
security functions to be run inside a TEE. At step 2, the TA Signer, and so generates a signed TA. The developer can then either
developer uploads the Untrusted Application (2a) to an Application bundle the signed TA with the Untrusted Application, or the developer
Store. The Untrusted Application may optionally bundle the TA can provide the signed TA to a TAM that will be managing the TA in
binary. Meanwhile, the TA developer may provide its TA to a TAM that various devices.
will be managing the TA in various devices. At step 3, a user will
go to an Application Store to download the Untrusted Application. At step 3, a user will go to an Application Store to download the
Since the Untrusted Application depends on the TA, installing the Untrusted Application. Since the Untrusted Application depends on
Untrusted Application will trigger TA installation by initiating the TA, installing the Untrusted Application will trigger TA
communication with a TAM. This is step 4. The TEEP Agent will installation by initiating communication with a TAM. This is step 4.
interact with TAM via a TEEP Broker that faciliates communications The TEEP Agent will interact with TAM via a TEEP Broker that
between a TAM and the TEEP Agent in TEE. faciliates communications between a TAM and the TEEP Agent in TEE.
Some TA installation implementations might ask for a user's consent. Some TA installation implementations might ask for a user's consent.
In other implementations, a Device Administrator might choose what In other implementations, a Device Administrator might choose what
Untrusted Applications and related TAs to be installed. A user Untrusted Applications and related TAs to be installed. A user
consent flow is out of scope of the TEEP architecture. consent flow is out of scope of the TEEP architecture.
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 TA management commands to a device, and device a TAM to deliver TA management commands to a device, and device
attestation and response messages created by a TEE that responds to a attestation and response messages created by a TEE that responds to a
TAM's message. TAM's message.
It should be noted that network communication capability is generally It should be noted that network communication capability is generally
not available in TAs in today's TEE-powered devices. Consequently, not available in TAs in today's TEE-powered devices. Consequently,
Trusted Applications generally rely on broker in the REE to provide Trusted Applications generally rely on broker in the REE to provide
access to nnetwork functionality in the REE. A broker does not need access to network functionality in the REE. A broker does not need
to know the actual content of messages to facilitate such access. to know the actual content of messages to facilitate such access.
Similarly, since the TEEP Agent runs inside a TEE, the TEEP Agent Similarly, since the TEEP Agent runs inside a TEE, the TEEP Agent
generally relies on a TEEP Broker in the REE to provide network generally relies on a TEEP Broker in the REE to provide network
access, and relay TAM requests to the TEEP Agent and relay the access, and relay TAM requests to the TEEP Agent and relay the
responses back to the TAM. responses back to the TAM.
5. Keys and Certificate Types 5. Keys and Certificate Types
This architecture leverages the following credentials, which allow This architecture leverages the following credentials, which allow
delivering end-to-end security between a TAM and a TEEP Agent. delivering end-to-end security between a TAM and a TEEP Agent.
Figure 4 summarizes the relationships between various keys and where Figure 4 summarizes the relationships between various keys and where
they are stored. Each public/private key identifies a TA developer, they are stored. Each public/private key identifies a TA Signer,
TAM, or TEE, and gets a certificate that chains up to some CA. A TAM, or TEE, and gets a certificate that chains up to some trust
list of trusted certificates is then used to check a presented anchor. A list of trusted certificates is then used to check a
certificate against. presented certificate against.
Different CAs can be used for different types of certificates. TEEP Different CAs can be used for different types of certificates. TEEP
messages are always signed, where the signer key is the message messages are always signed, where the signer key is the message
originator's private key, such as that of a TAM or a TEE. In originator's private key, such as that of a TAM or a TEE. In
addition to the keys shown in Figure 4, there may be additional keys addition to the keys shown in Figure 4, there may be additional keys
used for attestation. Refer to the RATS Architecture used for attestation. Refer to the RATS Architecture
[I-D.ietf-rats-architecture] for more discussion. [I-D.ietf-rats-architecture] for more discussion.
Cardinality & Location of Cardinality & Location of
Location of Private Key Trust Anchor Location of Private Key Trust Anchor
Purpose Private Key Signs Store Purpose Private Key Signs Store
------------------ ----------- ------------- ------------- ------------------ ----------- ------------- -------------
Authenticating TEE 1 per TEE TEEP responses TAM Authenticating TEE 1 per TEE TEEP responses TAM
Authenticating TAM 1 per TAM TEEP requests TEEP Agent Authenticating TAM 1 per TAM TEEP requests TEEP Agent
Code Signing 1 per TA TA binary TEE Code Signing 1 per TA TA binary TEE
developer Signer
Figure 4: Keys Figure 4: Signature Keys
Note that personalization data is not included in the table above. Note that personalization data is not included in the table above.
The use of personalization data is dependent on how TAs are used and The use of personalization data is dependent on how TAs are used and
what their security requirements are. what their security requirements are.
TEEP requests from a TAM to a TEEP Agent can be encrypted with the TEEP requests from a TAM to a TEEP Agent are signed with the TAM
TEE public key (to provide confidentiality), and are then signed with private key (for authentication and integrity protection).
the TAM private key (for authentication and integrity protection). Personalization data and TA binaries can be encrypted with a key that
Conversely, TEEP responses from a TEEP Agent to a TAM can be is established with a content encryption key established with the TEE
encrypted with the TAM public key, and are then signed with the TEE public key (to provide confidentiality). Conversely, TEEP responses
private key. from a TEEP Agent to a TAM can be signed with the TEE private key.
The TEE key pair and certificate are thus used for authenticating the The TEE key pair and certificate are thus used for authenticating the
TEE to a remote TAM, and for sending private data to the TEE. Often, TEE to a remote TAM, and for sending private data to the TEE. Often,
the key pair is burned into the TEE by the TEE manufacturer and the the key pair is burned into the TEE by the TEE manufacturer and the
key pair and its certificate are valid for the expected lifetime of key pair and its certificate are valid for the expected lifetime of
the TEE. A TAM provider is responsible for configuring the TAM's the TEE. A TAM provider is responsible for configuring the TAM's
Trust Anchor Store with the manufacturer certificates or CAs that are Trust Anchor Store with the manufacturer certificates or CAs that are
used to sign TEE keys. This is discussed further in Section 5.3 used to sign TEE keys. This is discussed further in Section 5.3
below. below.
The TAM key pair and certificate are used for authenticating a TAM to The TAM key pair and certificate are used for authenticating a TAM to
a remote TEE, and for sending private data to the TAM. A TAM a remote TEE, and for sending private data to the TAM. A TAM
provider is responsible for acquiring a certificate from a CA that is provider is responsible for acquiring a certificate from a CA that is
trusted by the TEEs it manages. This is discussed further in trusted by the TEEs it manages. This is discussed further in
Section 5.1 below. Section 5.1 below.
The TA developer key pair and certificate are used to sign TAs that The TA Signer key pair and certificate are used to sign TAs that the
the TEE will consider authorized to execute. TEEs must be configured TEE will consider authorized to execute. TEEs must be configured
with the certificates or keys that it considers authorized to sign with the certificates or keys that it considers authorized to sign
TAs that it will execute. This is discussed further in Section 5.2 TAs that it will execute. This is discussed further in Section 5.2
below. below.
5.1. Trust Anchors in a TEEP Agent 5.1. Trust Anchors in a TEEP Agent
A TEEP Agent's Trust Anchor Store contains a list of Trust Anchors, A TEEP Agent's Trust Anchor Store contains a list of Trust Anchors,
which are CA certificates that sign various TAM certificates. The which are CA certificates that sign various TAM certificates. The
list is typically preloaded at manufacturing time, and can be updated list is typically preloaded at manufacturing time, and can be updated
using the TEEP protocol if the TEE has some form of "Trust Anchor using the TEEP protocol if the TEE has some form of "Trust Anchor
skipping to change at page 20, line 23 skipping to change at page 20, line 7
data for any other TA. data for any other TA.
When Trust Anchor update is carried out, it is imperative that any When Trust Anchor update is carried out, it is imperative that any
update must maintain integrity where only an authentic Trust Anchor update must maintain integrity where only an authentic Trust Anchor
list from a device manufacturer or a Device Administrator is list from a device manufacturer or a Device Administrator is
accepted. Details are out of scope of the architecture and can be accepted. Details are out of scope of the architecture and can be
addressed in a protocol document. addressed in a protocol 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 Anchor Store of the TEEP Agent. CA or the raw public key of a TAM that is listed in the Trust Anchor
Store of the TEEP Agent.
5.2. Trust Anchors in a TEE 5.2. Trust Anchors in a TEE
A TEE determines whether TA binaries are allowed to execute by A TEE determines whether TA binaries are allowed to execute by
verifying whether the TA's signer chains up to a certificate in the verifying whether their signature can be verified using
TEE's Trust Anchor Store. The list is typically preloaded at certificate(s) or raw public key(s) in the TEE's Trust Anchor Store.
manufacturing time, and can be updated using the TEEP protocol if the The list is typically preloaded at manufacturing time, and can be
TEE has some form of "Trust Anchor Manager TA" that has Trust Anchors updated using the TEEP protocol if the TEE has some form of "Trust
in its configuration data. Thus, Trust Anchors can be updated Anchor Manager TA" that has Trust Anchors in its configuration data.
similar to updating the configuration data for any other TA, as Thus, Trust Anchors can be updated similar to updating the
discussed in Section 5.1. configuration data for any other TA, as discussed in Section 5.1.
5.3. Trust Anchors in a TAM 5.3. Trust Anchors in a TAM
The Trust Anchor Store in a TAM consists of a list of Trust Anchors, The Trust Anchor Store in a TAM consists of a list of Trust Anchors,
which are certificates that sign various device TEE certificates. A which are certificates that sign various device TEE certificates. A
TAM will accept a device for TA management if the TEE in the device TAM will accept a device for TA management if the TEE in the device
uses a TEE certificate that is chained to a certificate that the TAM uses a TEE certificate that is chained to a certificate or raw public
trusts. key that the TAM trusts, is contained in an allow list, is not found
on a block list, and/or fulfills any other policy criteria.
5.4. Scalability 5.4. Scalability
This architecture uses a PKI, although self-signed certificates are This architecture uses a PKI (including self-signed certificates).
also permitted. Trust Anchors exist on the devices to enable the TEE Trust Anchors exist on the devices to enable the TEE to authenticate
to authenticate TAMs and TA developer, and TAMs use Trust Anchors to TAMs and TA Signers, and TAMs use Trust Anchors to authenticate TEEs.
authenticate TEEs. When a PKI is used, many intermediate CA When a PKI is used, many intermediate CA certificates can chain to a
certificates can chain to a root certificate, each of which can issue root certificate, each of which can issue many certificates. This
many certificates. This makes the protocol highly scalable. New makes the protocol highly scalable. New factories that produce TEEs
factories that produce TEEs can join the ecosystem. In this case, can join the ecosystem. In this case, such a factory can get an
such a factory can get an intermediate CA certificate from one of the intermediate CA certificate from one of the existing roots without
existing roots without requiring that TAMs are updated with requiring that TAMs are updated with information about the new device
information about the new device factory. Likewise, new TAMs can factory. Likewise, new TAMs can join the ecosystem, providing they
join the ecosystem, providing they are issued a TAM certificate that are issued a TAM certificate that chains to an existing root whereby
chains to an existing root whereby existing TEEs will be allowed to existing TEEs will be allowed to be personalized by the TAM without
be personalized by the TAM without requiring changes to the TEE requiring changes to the TEE itself. This enables the ecosystem to
itself. This enables the ecosystem to scale, and avoids the need for scale, and avoids the need for centralized databases of all TEEs
centralized databases of all TEEs produced or all TAMs that exist or produced or all TAMs that exist or all TA Signers that exist.
all TA developers that exist.
5.5. Message Security 5.5. Message Security
Messages created by a TAM are used to deliver TA management commands Messages created by a TAM are used to deliver TA management commands
to a device, and device attestation and messages created by the to a device, and device attestation and messages created by the
device TEE to respond to TAM messages. device TEE to respond to TAM messages.
These messages are signed end-to-end between a TEEP Agent and a TAM, These messages are signed end-to-end between a TEEP Agent and a TAM.
and are typically encrypted such that only the targeted device TEE or Confidentiality is provided by encrypting sensitive payloads (such as
TAM is able to decrypt and view the actual content. personalization data and attestation evidence), rather than
encrypting the messages themselves. Using encrypted payloads is
important to ensure that only the targeted device TEE or TAM is able
to decrypt and view the actual content.
6. TEEP Broker 6. TEEP Broker
A TEE and TAs often do not have the capability to directly A TEE and TAs often do not have the capability to directly
communicate outside of the hosting device. For example, communicate outside of the hosting device. For example,
GlobalPlatform [GPTEE] specifies one such architecture. This calls GlobalPlatform [GPTEE] specifies one such architecture. This calls
for a software module in the REE world to handle network for a software module in the REE world to handle network
communication with a TAM. communication with a TAM.
A TEEP Broker is an application component running in the REE of the A TEEP Broker is an application component running in the REE of the
skipping to change at page 23, line 21 skipping to change at page 23, line 10
6.2.2. TEEP Broker Distribution 6.2.2. TEEP Broker Distribution
The Broker installation is commonly carried out at OEM time. A user The Broker installation is commonly carried out at OEM time. A user
can dynamically download and install a Broker on-demand. can dynamically download and install a Broker on-demand.
7. Attestation 7. Attestation
Attestation is the process through which one entity (an Attester) Attestation is the process through which one entity (an Attester)
presents "evidence", in the form of a series of claims, to another presents "evidence", in the form of a series of claims, to another
entity (a Verifier), and provides sufficient proof that the claims entity (a Verifier), and provides sufficient proof that the claims
are true. Different Verifiers may have different standards for are true. Different Verifiers may require different degrees of
attestation proofs and not all attestations are acceptable to every confidence in attestation proofs and not all attestations are
verifier. A third entity (a Relying Party) can then use "attestation acceptable to every verifier. A third entity (a Relying Party) can
results", in the form of another series of claims, from a Verifier to then use "attestation results", in the form of another series of
make authorization decisions. (See [I-D.ietf-rats-architecture] for claims, from a Verifier to make authorization decisions. (See
more discussion.) [I-D.ietf-rats-architecture] for more discussion.)
In TEEP, as depicted in Figure 5, the primary purpose of an In TEEP, as depicted in Figure 5, the primary purpose of an
attestation is to allow a device (the Attester) to prove to a TAM attestation is to allow a device (the Attester) to prove to a TAM
(the Relying Party) that a TEE in the device has particular (the Relying Party) that a TEE in the device has particular
properties, was built by a particular manufacturer, and/or is properties, was built by a particular manufacturer, and/or is
executing a particular TA. Other claims are possible; TEEP does not executing a particular TA. Other claims are possible; TEEP does not
limit the claims that may appear in evidence or attestation results, limit the claims that may appear in evidence or attestation results,
but defines a minimal set of attestation result claims required for but defines a minimal set of attestation result claims required for
TEEP to operate properly. Extensions to these claims are possible. TEEP to operate properly. Extensions to these claims are possible.
Other standards or groups may define the format and semantics of Other standards or groups may define the format and semantics of
skipping to change at page 24, line 6 skipping to change at page 23, line 44
+----------------+ Result +----------------+ Result
Figure 5: TEEP Attestation Roles Figure 5: TEEP Attestation Roles
As of the writing of this specification, device and TEE attestations As of the writing of this specification, device and TEE attestations
have not been standardized across the market. Different devices, have not been standardized across the market. Different devices,
manufacturers, and TEEs support different attestation protocols. In manufacturers, and TEEs support different attestation protocols. In
order for TEEP to be inclusive, it is agnostic to the format of order for TEEP to be inclusive, it is agnostic to the format of
evidence, allowing proprietary or standardized formats to be used evidence, allowing proprietary or standardized formats to be used
between a TEE and a verifier (which may or may not be colocated in between a TEE and a verifier (which may or may not be colocated in
the TAM). However, it should be recognized that not all Verifiers the TAM), as long as the format supports encryption of any
may be able to process all proprietary forms of attestation evidence. information that is considered sensitive.
Similarly, the TEEP protocol is agnostic as to the format of
attestation results, and the protocol (if any) used between the TAM However, it should be recognized that not all Verifiers may be able
and a verifier, as long as they convey at least the required set of to process all proprietary forms of attestation evidence. Similarly,
claims in some format. Note that the respective attestation the TEEP protocol is agnostic as to the format of attestation
algorithms are not defined in the TEEP protocol itself; see results, and the protocol (if any) used between the TAM and a
verifier, as long as they convey at least the required set of claims
in some format. Note that the respective attestation algorithms are
not defined in the TEEP protocol itself; see
[I-D.ietf-rats-architecture] and [I-D.ietf-teep-protocol] for more [I-D.ietf-rats-architecture] and [I-D.ietf-teep-protocol] for more
discussion. discussion.
There are a number of considerations that need to be considered when There are a number of considerations that need to be considered when
appraising evidence provided by a TEE, including: appraising evidence provided by a TEE, including:
- What security measures a manufacturer takes when provisioning keys - What security measures a manufacturer takes when provisioning keys
into devices/TEEs; into devices/TEEs;
- What hardware and software components have access to the - What hardware and software components have access to the
skipping to change at page 24, line 49 skipping to change at page 24, line 41
claims are outside the scope of this specification, but the TEEP claims are outside the scope of this specification, but the TEEP
protocol allows these additional claims to be included in the protocol allows these additional claims to be included in the
attestation messages. attestation messages.
For more discussion of the attestation and appraisal process, see the For more discussion of the attestation and appraisal process, see the
RATS Architecture [I-D.ietf-rats-architecture]. RATS Architecture [I-D.ietf-rats-architecture].
7.1. Information Required in TEEP Claims 7.1. Information Required in TEEP Claims
- Device Identifying Info: TEEP attestations may need to uniquely - Device Identifying Info: TEEP attestations may need to uniquely
identify a device to the TAM and TA developer. Unique device identify a device to the TAM. Unique device identification allows
identification allows the TAM to provide services to the device, the TAM to provide services to the device, such as managing
such as managing installed TAs, and providing subscriptions to installed TAs, and providing subscriptions to services, and
services, and locating device-specific keying material to locating device-specific keying material to communicate with or
communicate with or authenticate the device. In some use cases it authenticate the device. In some use cases it may be sufficient
may be sufficient to identify only the class of the device. The to identify only the class of the device. The security and
security and privacy requirements regarding device identification privacy requirements regarding device identification will vary
will vary with the type of TA provisioned to the TEE. with the type of TA provisioned to the TEE.
- TEE Identifying info: The type of TEE that generated this - TEE Identifying info: The type of TEE that generated this
attestation must be identified, including version identification attestation must be identified, including version identification
information such as the hardware, firmware, and software version information such as the hardware, firmware, and software version
of the TEE, as applicable by the TEE type. TEE manufacturer of the TEE, as applicable by the TEE type. TEE manufacturer
information for the TEE is required in order to disambiguate the information for the TEE is required in order to disambiguate the
same TEE type created by different manufacturers and address same TEE type created by different manufacturers and address
considerations around manufacturer provisioning, keying and considerations around manufacturer provisioning, keying and
support for the TEE. support for the TEE.
- Freshness Proof: A claim that includes freshness information must - Freshness Proof: A claim that includes freshness information must
be included, such as a nonce or timestamp. be included, such as a nonce or timestamp.
- Requested Components: A list of zero or more components (TAs or - Requested Components: A list of zero or more components (TAs or
other dependencies needed by a TEE) that are requested by some other dependencies needed by a TEE) that are requested by some
depending app, but which are not currently installed in the TEE. depending app, but which are not currently installed in 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 cryptographic algorithm suite to another over
feature is also known as crypto agility. Protocol evolution is time. This feature is also known as crypto agility. Protocol
greatly simplified when crypto agility is considered during the evolution is greatly simplified when crypto agility is considered
design of the protocol. In the case of the TEEP protocol the diverse during the design of the protocol. In the case of the TEEP protocol
range of use cases, from trusted app updates for smart phones and the diverse range of use cases, from trusted app updates for smart
tablets to updates of code on higher-end IoT devices, creates the phones and tablets to updates of code on higher-end IoT devices,
need for different mandatory-to-implement algorithms already from the creates the need for different mandatory-to-implement algorithms
start. already from the start.
Crypto agility in TEEP concerns the use of symmetric as well as Crypto agility in TEEP concerns the use of symmetric as well as
asymmetric algorithms. In the context of TEEP symmetric algorithms asymmetric algorithms. In the context of TEEP symmetric algorithms
are used for encryption of TA binaries and personalization data are used for encryption of TA binaries and personalization data
whereas the asymmetric algorithms are mostly used for signing whereas the asymmetric algorithms are mostly used for signing
messages. messages.
In addition to the use of cryptographic algorithms in TEEP, there is In addition to the use of cryptographic algorithms in TEEP, there is
also the need to make use of different attestation technologies. A also the need to make use of different attestation technologies. A
device must provide techniques to inform a TAM about the attestation device must provide techniques to inform a TAM about the attestation
skipping to change at page 26, line 27 skipping to change at page 26, line 17
A TEEP Agent in a TEE is responsible for protecting against potential A TEEP Agent in a TEE is responsible for protecting against potential
attacks from a compromised TEEP Broker or rogue malware in the REE. attacks from a compromised TEEP Broker or rogue malware in the REE.
A rogue TEEP Broker might send corrupted data to the TEEP Agent, or A rogue TEEP Broker might send corrupted data to the TEEP Agent, or
launch a DoS attack by sending a flood of TEEP protocol requests. launch a DoS attack by sending a flood of TEEP protocol requests.
The TEEP Agent validates the signature of each TEEP protocol request The TEEP Agent validates the signature of each TEEP protocol request
and checks the signing certificate against its Trust Anchors. To and checks the signing certificate against its Trust Anchors. To
mitigate DoS attacks, it might also add some protection scheme such mitigate DoS attacks, it might also add some protection scheme such
as a threshold on repeated requests or number of TAs that can be as a threshold on repeated requests or number of TAs that can be
installed. installed.
9.2. Data Protection at TAM and TEE 9.2. Data Protection
The TEE implementation provides protection of data on the device. It The TEE implementation provides protection of data on the device. It
is the responsibility of the TAM to protect data on its servers. is the responsibility of the TAM to protect data on its servers.
The protocol between TEEP Agents and TAMs similarly is responsible
for securely providing integrity and confidentiality protection
against adversaries between them. Since the transport protocol under
the TEEP protocol might be implemented outside a TEE, as discussed in
Section 6, it cannot be relied upon for sufficient protection. The
TEEP protocol provides integrity protection, but confidentiality must
be provided by payload security, i.e., using encrypted TA binaries
and encrypted attestation information. See [I-D.ietf-teep-protocol]
for more discussion.
9.3. Compromised REE 9.3. Compromised REE
It is possible that the REE of a device is compromised. If the REE It is possible that the REE of a device is compromised. If the REE
is compromised, several DoS attacks may be launched. The compromised is compromised, several DoS attacks may be launched. The compromised
REE may terminate the TEEP Broker such that TEEP transactions cannot REE may terminate the TEEP Broker such that TEEP transactions cannot
reach the TEE, or might drop or delay messages between a TAM and a reach the TEE, or might drop or delay messages between a TAM and a
TEEP Agent. However, while a DoS attack cannot be prevented, the REE TEEP Agent. However, while a DoS attack cannot be prevented, the REE
cannot access anything in the TEE if it is implemented correctly. cannot access anything in the TEE if it is implemented correctly.
Some TEEs may have some watchdog scheme to observe REE state and Some TEEs may have some watchdog scheme to observe REE state and
mitigate DoS attacks against it but most TEEs don't have such a mitigate DoS attacks against it but most TEEs don't have such a
skipping to change at page 27, line 48 skipping to change at page 27, line 51
It is possible that a rogue developer distributes a malicious It is possible that a rogue developer distributes a malicious
Untrusted Application and intends to get a malicious TA installed. Untrusted Application and intends to get a malicious TA installed.
It's the responsibility of the TAM to not install malicious trusted It's the responsibility of the TAM to not install malicious trusted
apps in the first place. The TEEP architecture allows a TEEP Agent apps in the first place. The TEEP architecture allows a TEEP Agent
to decide which TAMs it trusts via Trust Anchors, and delegates the to decide which TAMs it trusts via Trust Anchors, and delegates the
TA authenticity check to the TAMs it trusts. TA authenticity check to the TAMs it trusts.
It may happen that a TA was previously considered trustworthy but is It may happen that a TA was previously considered trustworthy but is
later found to be buggy or compromised. In this case, the TAM can later found to be buggy or compromised. In this case, the TAM can
initiate the removal of the TA by notifying devices to remove the TA initiate the removal of the TA by notifying devices to remove the TA
(and potentially the REE or device owner to remove any Untrusted (and potentially the REE or Device Owner to remove any Untrusted
Application that depend on the TA). If the TAM does not currently Application that depend on the TA). If the TAM does not currently
have a connection to the TEEP Agent on a device, such a notification have a connection to the TEEP Agent on a device, such a notification
would occur the next time connectivity does exist. That is, to would occur the next time connectivity does exist. That is, to
recover, the TEEP Agent must be able to reach out to the TAM, for recover, the TEEP Agent must be able to reach out to the TAM, for
example whenever the RequestPolicyCheck API (Section 6.2.1) is example whenever the RequestPolicyCheck API (Section 6.2.1) is
invoked by a timer or other event. invoked by a timer or other event.
Furthermore the policy in the Verifier in an attestation process can Furthermore the policy in the Verifier in an attestation process can
be updated so that any evidence that includes the malicious TA would be updated so that any evidence that includes the malicious TA would
result in an attestation failure. There is, however, a time window result in an attestation failure. There is, however, a time window
skipping to change at page 28, line 27 skipping to change at page 28, line 29
Verifier should take into account the acceptable time window when Verifier should take into account the acceptable time window when
generating attestation results. See [I-D.ietf-rats-architecture] for generating attestation results. See [I-D.ietf-rats-architecture] for
further discussion. further discussion.
9.7. Certificate Expiry and Renewal 9.7. Certificate Expiry and Renewal
TEE device certificates are expected to be long lived, longer than TEE device certificates are expected to be long lived, longer than
the lifetime of a device. A TAM certificate usually has a moderate the lifetime of a device. A TAM certificate usually has a moderate
lifetime of 2 to 5 years. A TAM should get renewed or rekeyed lifetime of 2 to 5 years. A TAM should get renewed or rekeyed
certificates. The root CA certificates for a TAM, which are embedded certificates. The root CA certificates for a TAM, which are embedded
into the Trust Anchor store in a device, should have long lifetimes into the Trust Anchor Store in a device, should have long lifetimes
that don't require device Trust Anchor update. On the other hand, it that don't require device Trust Anchor updates. On the other hand,
is imperative that OEMs or device providers plan for support of Trust it is imperative that OEMs or device providers plan for support of
Anchor update in their shipped devices. Trust Anchor update in their shipped devices.
For those cases where TEE devices are given certificates for which no For those cases where TEE devices are given certificates for which no
good expiration date can be assigned the recommendations in good expiration date can be assigned the recommendations in
Section 4.1.2.5 of RFC 5280 [RFC5280] are applicable. Section 4.1.2.5 of RFC 5280 [RFC5280] are applicable.
9.8. Keeping Secrets from the TAM 9.8. Keeping Secrets from the TAM
In some scenarios, it is desirable to protect the TA binary or In some scenarios, it is desirable to protect the TA binary or
configuration from being disclosed to the TAM that distributes them. configuration from being disclosed to the TAM that distributes them.
In such a scenario, the files can be encrypted end-to-end between a In such a scenario, the files can be encrypted end-to-end between a
TA developer and a TEE. However, there must be some means of TA Signer and a TEE. However, there must be some means of
provisioning the decryption key into the TEE and/or some means of the provisioning the decryption key into the TEE and/or some means of the
TA developer securely learning a public key of the TEE that it can TA Signer securely learning a public key of the TEE that it can use
use to encrypt. One way to do this is for the TA developer to run to encrypt. One way to do this is for the TA Signer to run its own
its own TAM so that it can distribute the decryption key via the TEEP TAM so that it can distribute the decryption key via the TEEP
protocol, and the key file can be a dependency in the manifest of the protocol, and the key file can be a dependency in the manifest of the
encrypted TA. Thus, the TEEP Agent would look at the TA manifest, encrypted TA. Thus, the TEEP Agent would look at the TA manifest,
determine there is a dependency with a TAM URI of the TA developer's determine there is a dependency with a TAM URI of the TA Signer's
TAM. The Agent would then install the dependency, and then continue TAM. The Agent would then install the dependency, and then continue
with the TA installation steps, including decrypting the TA binary with the TA installation steps, including decrypting the TA binary
with the relevant key. with the relevant key.
10. IANA Considerations 10. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
11. Contributors 11. Contributors
skipping to change at page 30, line 37 skipping to change at page 30, line 43
extensions.html>. extensions.html>.
[TrustZone] [TrustZone]
Arm, "Arm TrustZone Technology", n.d., Arm, "Arm TrustZone Technology", n.d.,
<https://developer.arm.com/ip-products/security-ip/ <https://developer.arm.com/ip-products/security-ip/
trustzone>. trustzone>.
Authors' Addresses Authors' Addresses
Mingliang Pei Mingliang Pei
Symantec Broadcom
EMail: mingliang_pei@symantec.com EMail: mingliang.pei@broadcom.com
Hannes Tschofenig Hannes Tschofenig
Arm Limited Arm Limited
EMail: hannes.tschofenig@arm.com EMail: hannes.tschofenig@arm.com
Dave Thaler Dave Thaler
Microsoft Microsoft
EMail: dthaler@microsoft.com EMail: dthaler@microsoft.com
David Wheeler David Wheeler
Intel Intel
EMail: david.m.wheeler@intel.com EMail: david.m.wheeler@intel.com
 End of changes. 74 change blocks. 
251 lines changed or deleted 261 lines changed or added

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