draft-ietf-teep-architecture-08.txt   draft-ietf-teep-architecture-09.txt 
TEEP M. Pei TEEP M. Pei
Internet-Draft Symantec Internet-Draft Symantec
Intended status: Informational H. Tschofenig Intended status: Informational H. Tschofenig
Expires: October 6, 2020 Arm Limited Expires: December 14, 2020 Arm Limited
D. Thaler D. Thaler
Microsoft Microsoft
D. Wheeler D. Wheeler
Intel Intel
April 04, 2020 June 12, 2020
Trusted Execution Environment Provisioning (TEEP) Architecture Trusted Execution Environment Provisioning (TEEP) Architecture
draft-ietf-teep-architecture-08 draft-ietf-teep-architecture-09
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 October 6, 2020. This Internet-Draft will expire on December 14, 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 29 skipping to change at page 2, line 29
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. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 7 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 8
3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . 10 4.2. Multiple TEEs in a Device . . . . . . . . . . . . . . . . 11
4.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 12 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. Examples of Application Delivery Mechanisms in 4.4.1. Example: Application Delivery Mechanisms in Intel SGX 16
Existing TEEs . . . . . . . . . . . . . . . . . . . . 15 4.4.2. Example: Application Delivery Mechanisms in Arm
4.5. Entity Relations . . . . . . . . . . . . . . . . . . . . 16 TrustZone . . . . . . . . . . . . . . . . . . . . . . 16
5. Keys and Certificate Types . . . . . . . . . . . . . . . . . 17 4.5. Entity Relations . . . . . . . . . . . . . . . . . . . . 17
5.1. Trust Anchors in a TEEP Agent . . . . . . . . . . . . . . 19 5. Keys and Certificate Types . . . . . . . . . . . . . . . . . 18
5.2. Trust Anchors in a TEE . . . . . . . . . . . . . . . . . 19 5.1. Trust Anchors in a TEEP Agent . . . . . . . . . . . . . . 20
5.3. Trust Anchors in a TAM . . . . . . . . . . . . . . . . . 19 5.2. Trust Anchors in a TEE . . . . . . . . . . . . . . . . . 20
5.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 19 5.3. Trust Anchors in a TAM . . . . . . . . . . . . . . . . . 20
5.5. Message Security . . . . . . . . . . . . . . . . . . . . 20 5.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 20
6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.5. Message Security . . . . . . . . . . . . . . . . . . . . 21
6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 20 6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2. TEEP Broker Implementation Consideration . . . . . . . . 21 6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 21
6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 21 6.2. TEEP Broker Implementation Consideration . . . . . . . . 22
6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 22 6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 22
7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 24 8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 25 9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 26
9.2. Data Protection at TAM and TEE . . . . . . . . . . . . . 25 9.2. Data Protection at TAM and TEE . . . . . . . . . . . . . 26
9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 25 9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 26
9.4. Compromised CA . . . . . . . . . . . . . . . . . . . . . 26 9.4. Compromised CA . . . . . . . . . . . . . . . . . . . . . 27
9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 26 9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 27
9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 26 9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 27
9.7. Certificate Renewal . . . . . . . . . . . . . . . . . . . 27 9.7. Certificate Expiry and Renewal . . . . . . . . . . . . . 28
9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 27 9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 28
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
13. Informative References . . . . . . . . . . . . . . . . . . . 28 13. Informative References . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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 increases with the sources. The potential for attacks further increases 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 3, line 51 skipping to change at page 4, line 4
code outside that environment, including by a commodity operating code outside that environment, including by a commodity operating
system (if present). system (if present).
This separation reduces the possibility of a successful attack on This separation reduces the possibility of a successful attack on
application components and the data contained inside the TEE. application components and the data contained inside the TEE.
Typically, application components are chosen to execute inside a TEE Typically, application components are chosen to execute inside a TEE
because those application components perform security sensitive because those application components perform security sensitive
operations or operate on sensitive data. An application component operations or operate on sensitive data. An application component
running inside a TEE is referred to as a Trusted Application (TA), running inside a TEE is referred to as a Trusted Application (TA),
while an application running outside any TEE is referred to as an while an application running outside any TEE is referred to as an
Untrusted Application. Untrusted Application. In the example of a banking application, code
that relates to the authentication protocol could reside in a TA
while the application logic including HTTP protocol parsing could be
contained in the Untrusted Application. In addition, processing of
credit card numbers or account balances could be done in a TA as it
is sensitive data. The precise code split is ultimately a decision
of the 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
may integrate one or more TEEs into their devices depending on market may integrate one or more TEEs into their devices depending on market
needs. needs.
To simplify the life of TA developers interacting with TAs in a TEE, To simplify the life of TA developers interacting with TAs in a TEE,
an interoperable protocol for managing TAs running in different TEEs an interoperable protocol for managing TAs running in different TEEs
of various devices is needed. In this TEE ecosystem, there often of various devices is needed. This software update protocol needs to
arises a need for an external trusted party to verify the identity, make sure that compatible trusted and untrusted components (if any)
claims, and rights of TA developers, devices, and their TEEs. This of an application are installed on the correct device. In this TEE
trusted third party is the Trusted Application Manager (TAM). ecosystem, there often arises a need for an external trusted party to
verify the identity, claims, and rights of TA developers, devices,
and their TEEs. This trusted third party is the Trusted Application
Manager (TAM).
The Trusted Execution Environment Provisioning (TEEP) protocol The Trusted Execution Environment Provisioning (TEEP) protocol
addresses the following problems: addresses the following problems:
- An installer of an Untrusted Application that depends on a given - An installer of an Untrusted Application that depends on a given
TA wants to request installation of that TA in the device's TEE so TA wants to request installation of that TA in the device's TEE so
that the Untrusted Application can complete, but the TEE needs to that the Untrusted Application can complete, but the TEE needs to
verify whether such a TA is actually authorized to run in the TEE verify whether such a TA is actually authorized to run in the TEE
and consume potentially scarce TEE resources. and consume potentially scarce TEE resources.
skipping to change at page 4, line 51 skipping to change at page 5, line 16
to manage a TA in the device is authorized to manage TAs in the to manage a TA in the device is authorized to manage TAs in the
TEE, and what TAs the entity is permitted to manage. TEE, and what TAs the entity is permitted to manage.
- A TAM (e.g., operated by a device administrator) wants to - A TAM (e.g., operated by a device administrator) wants to
determine if a TA exists (is installed) on a device (in the TEE), determine if a TA exists (is installed) on a device (in the TEE),
and if not, install the TA in the TEE. and if not, install the TA in the TEE.
- A TAM wants to check whether a TA in a device's TEE is the most - A TAM wants to check whether a TA in a device's TEE is the most
up-to-date version, and if not, update the TA in the TEE. up-to-date version, and if not, update the TA in the TEE.
- A TA developer wants to remove a confidential TA from a device's - A Device Administrator wants to remove a TA from a device's TEE if
TEE if the TA developer is no longer offering such TAs or the TAs the TA developer is no longer maintaining that TA, when the TA has
are being revoked from a particular user (or device). For been revoked or is not used for other reasons anymore (e.g., due
example, if a subscription or contract for a particular service to an expired subscription).
has expired, or a payment by the user has not been completed or
has been rescinded.
- 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 to provision the Note: The TA developer requires the help of a TAM and most likely the
Trusted Applications to remote devices and the TEEP protocol Device Administrator to provision the Trusted Applications to remote
exchanges messages between a TAM and a TEEP Agent via a TEEP Broker. 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 Rich Execution Environment. A device contains
a default list of Trust Anchors that identify entities (e.g., a default list of Trust Anchors that identify entities (e.g.,
TAMs) that are trusted by the device. This list is normally set TAMs) that are trusted by the device. This list is normally set
by the device manufacturer, and may be governed by the device's by the device manufacturer, and may be governed by the device's
skipping to change at page 6, line 43 skipping to change at page 7, line 7
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 component that runs in a
TEE. TEE.
- Trusted Application (TA) Developer: An entity that wishes to - Trusted Application (TA) Developer: An entity that wishes to
provide functionality on devices that requires the use of one or provide functionality on devices that requires the use of one or
more Trusted Applications. more Trusted Applications. The TA developer signs the TA binary
(or more precisely the manifest associated with the TA binary) or
uses another entity on his or her behalf to get the TA binary
signed. (A TA binary may also be encrypted by the developer or by
some third party service.) For editorial reasons, we assume that
the TA developer signs the TA binary ignoring the distinction
between the binary and the manifest and by simplifying the case
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
skipping to change at page 10, line 26 skipping to change at page 11, line 7
protocol transport would be implemented inside the TEE itself. protocol transport would be implemented inside the TEE itself.
- TEEP Agent: The TEEP Agent is a processing module running inside a - TEEP Agent: The TEEP Agent is a processing module running inside a
TEE that receives TAM requests (typically relayed via a TEEP TEE that receives TAM requests (typically relayed via a TEEP
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): Certificate-based credentials used - Certification Authority (CA): A CA is an entity that issues
for authenticating a device, a TAM and a TA developer. A device digital certificates (especially X.509 certificates) and vouches
embeds a list of root certificates (Trust Anchors), from trusted for the binding between the data items in a certificate [RFC4949].
CAs that a TAM will be validated against. A TAM will remotely Certificates are then used for authenticating a device, a TAM and
attest a device by checking whether a device comes with a a TA developer. A device embeds a list of root certificates
certificate from a CA that the TAM trusts. The CAs do not need to (Trust Anchors), from trusted CAs that a TAM will be validated
be the same; different CAs can be chosen by each TAM, and against. A TAM will remotely attest a device by checking whether
different device CAs can be used by different device a device comes with a certificate from 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 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) present themselves the device. However, some TEEs (for example, SGX [SGX]) present
as separate containers within memory without a controlling manager themselves as separate containers within memory without a controlling
within the TEE. As such, there might be multiple TEEP Brokers in the manager within the TEE. As such, there might be multiple TEEP
Rich Execution Environment, where each TEEP Broker communicates with Brokers in the Rich Execution Environment, where each TEEP Broker
one or more TEEs associated with it. communicates with one or more TEEs associated with it.
It is up to the Rich Execution Environment and the Untrusted It is up to the Rich Execution Environment and the Untrusted
Applications how they select the correct TEEP Broker. Verification Applications how they select the correct TEEP Broker. Verification
that the correct TA has been reached then becomes a matter of that the correct TA has been reached then becomes a matter of
properly verifying TA attestations, which are unforgeable. properly verifying TA attestations, 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.
skipping to change at page 12, line 22 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 software the TA back to the signer. The signer is usually the TA developer,
author, but in some cases might be another party that the TA software but in some cases might be another party that the TA developer
author trusts, or a party to whom the code has been licensed (in trusts, or a party to whom the code has been licensed (in which case
which case the same code might be signed by multiple licensees and the same code might be signed by multiple licensees and distributed
distributed as if it were different TAs). as if it were different TAs).
A TA author or signer selects one or more TAMs through which to offer 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 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 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 selects a TAM and publishes a signed TA to it, independent of whether
the publishing entity is the TA software author or the signer or the publishing entity is the TA developer or the signer or both.
both.
The TA developer chooses TAMs based upon the markets into which the The TA developer chooses TAMs based upon the markets into which the
TAM can provide access. There may be TAMs that provide services to TAM can provide access. There may be TAMs that provide services to
specific types of devices, or device operating systems, or specific specific types of devices, or device operating systems, or specific
geographical regions or network carriers. A TA developer may be geographical regions or network carriers. A TA developer may be
motivated to utilize multiple TAMs for its service in order to motivated to utilize multiple TAMs for its service in order to
maximize market penetration and availability on multiple types of maximize market penetration and availability on multiple types of
devices. This likely means that the same TA will be available devices. This likely means that the same TA will be available
through multiple TAMs. through multiple TAMs.
skipping to change at page 14, line 19 skipping to change at page 15, line 12
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 TA developer or the device or a user. This personalization data
is dependent on the TEE, the TA, and the TA developer; an example of may dependent on the type of TEE, a particular TEE instance, the TA,
the TA developer and even the user of the device; an example of
personalization data might be a secret symmetric key used by the TA personalization data might be a secret symmetric key used by the TA
to communicate with the TA developer. Implementations must support to communicate with some service. Implementations must support
encryption of personalization data to preserve the confidentiality of encryption of personalization data to preserve the confidentiality of
potentially sensitive data contained within it. Other than this potentially sensitive data contained within it and support integrity
requirement to support confidentiality, the TEEP architecture places protection of the personalization data. Other than the requirement
no limitations or requirements on the personalization data. to support confidentiality and integrity protection, the TEEP
architecture places no limitations or requirements on the
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 developer 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
skipping to change at page 15, line 5 skipping to change at page 16, line 5
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.
4.4.1. Examples of Application Delivery Mechanisms in Existing TEEs
In order to better understand these cases, it is helpful to review In order to better understand these cases, it is helpful to review
actual implementations of TEEs and their application delivery actual implementations of TEEs and their application delivery
mechanisms. mechanisms.
4.4.1. Example: Application Delivery Mechanisms in Intel SGX
In Intel Software Guard Extensions (SGX), the Untrusted Application In Intel Software Guard Extensions (SGX), the Untrusted Application
and TA are typically bundled into the same package (Case 2). The TA and TA are typically bundled into the same package (Case 2). The TA
exists in the package as a shared library (.so or .dll). The exists in the package as a shared library (.so or .dll). The
Untrusted Application loads the TA into an SGX enclave when the Untrusted Application loads the TA into an SGX enclave when the
Untrusted Application needs the TA. This organization makes it easy Untrusted Application needs the TA. This organization makes it easy
to maintain compatibility between the Untrusted Application and the to maintain compatibility between the Untrusted Application and the
TA, since they are updated together. It is entirely possible to TA, since they are updated together. It is entirely possible to
create an Untrusted Application that loads an external TA into an SGX create an Untrusted Application that loads an external TA into an SGX
enclave, and use that TA (Case 3). In this case, the Untrusted enclave, and use that TA (Case 3). In this case, the Untrusted
Application would require a reference to an external file or download Application would require a reference to an external file or download
skipping to change at page 15, line 45 skipping to change at page 16, line 45
otherwise there is a significant problem in getting the SGX enclave otherwise there is a significant problem in getting the SGX enclave
code (the TA) from the TEE, through the installer, and into the code (the TA) from the TEE, through the installer, and into the
Untrusted Application in a trusted fashion. Finally, the Untrusted Application in a trusted fashion. Finally, the
personalization data would need to be sent out of the TEE (encrypted personalization data would need to be sent out of the TEE (encrypted
in an SGX enclave-to-enclave manner) to the REE's installation app, in an SGX enclave-to-enclave manner) to the REE's installation app,
which would pass this data to the installed Untrusted Application, which would pass this data to the installed Untrusted Application,
which would in turn send this data to the SGX enclave (TA). This which would in turn send this data to the SGX enclave (TA). This
complexity is due to the fact that each SGX enclave is separate and complexity is due to the fact that each SGX enclave is separate and
does not have direct communication to other SGX enclaves. does not have direct communication to other SGX enclaves.
In Arm TrustZone for A- and R-class devices, the Untrusted 4.4.2. Example: Application Delivery Mechanisms in Arm TrustZone
In Arm TrustZone [TrustZone] for A-class devices, the Untrusted
Application and TA may or may not be bundled together. This differs Application and TA may or may not be bundled together. This differs
from SGX since in TrustZone the TA lifetime is not inherently tied to from SGX since in TrustZone the TA lifetime is not inherently tied to
a specific Untrused Application process lifetime as occurs in SGX. A a specific Untrused Application process lifetime as occurs in SGX. A
TA is loaded by a trusted OS running in the TEE, where the trusted OS TA is loaded by a trusted OS running in the TEE, where the trusted OS
is separate from the OS in the REE. Thus Cases 2 and 3 are equally is separate from the OS in the REE. Thus Cases 2 and 3 are equally
applicable. In addition, it is possible for TAs to communicate with applicable. In addition, it is possible for TAs to communicate with
each other without involving any Untrusted Application, and so the each other without involving any Untrusted Application, and so the
complexity of Case 1 is lower than in the SGX example. Thus, Case 1 complexity of Case 1 is lower than in the SGX example. Thus, Case 1
is possible as well, though still more complex than Cases 2 and 3. is possible as well, though still more complex than Cases 2 and 3.
4.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 of the TAM allowed. A device manufacturer enables verification by one or more
providers and TA binary signers; it may embed a list of default Trust TAMs and by TA developers; it may embed a list of default Trust
Anchors into the TEEP Agent and TEE for TAM trust verification and TA Anchors into the TEEP Agent and TEE for TAM and TA trust
signer verification. 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: Developer Experience
Note that Figure 3 shows the TA developer as a TA signer. The TA Note that Figure 3 shows the view from a TA developer point of view.
signer is either the same as the TA developer, or is a related entity The TA developer signs the TA or is a related entity trusted to sign
trusted to sign the developer's TAs. the developer-created TAs.
Figure 3 shows an example where the same developer builds two Figure 3 shows an example where the same developer builds two
applications: 1) an Untrusted Application; 2) a TA that provides some applications: 1) an Untrusted Application; 2) a TA that provides some
security functions to be run inside a TEE. At step 2, the TA security functions to be run inside a TEE. At step 2, the TA
developer uploads the Untrusted Application (2a) to an Application developer uploads the Untrusted Application (2a) to an Application
Store. The Untrusted Application may optionally bundle the TA Store. The Untrusted Application may optionally bundle the TA
binary. Meanwhile, the TA developer may provide its TA to a TAM that binary. Meanwhile, the TA developer may provide its TA to a TAM that
will be managing the TA in various devices. At step 3, a user will will be managing the TA in various devices. At step 3, a user will
go to an Application Store to download the Untrusted Application. go to an Application Store to download the Untrusted Application.
Since the Untrusted Application depends on the TA, installing the Since the Untrusted Application depends on the TA, installing the
skipping to change at page 19, line 48 skipping to change at page 20, line 48
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 that the TAM
trusts. trusts.
5.4. Scalability 5.4. Scalability
This architecture uses a PKI, although self-signed certificates are This architecture uses a PKI, although self-signed certificates are
also permitted. Trust Anchors exist on the devices to enable the TEE also permitted. Trust Anchors exist on the devices to enable the TEE
to authenticate TAMs and TA signers, and TAMs use Trust Anchors to to authenticate TAMs and TA developer, and TAMs use Trust Anchors to
authenticate TEEs. When a PKI is used, many intermediate CA authenticate TEEs. When 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
skipping to change at page 22, line 51 skipping to change at page 23, line 51
| +------------+ | Evidence | TAM | Evidence +----------+ | +------------+ | Evidence | TAM | Evidence +----------+
| | TEE |------------->| (Relying |-------------->| Verifier | | | TEE |------------->| (Relying |-------------->| Verifier |
| | (Attester) | | | Party) |<--------------| | | | (Attester) | | | Party) |<--------------| |
| +------------+ | +----------+ Attestation +----------+ | +------------+ | +----------+ Attestation +----------+
+----------------+ 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 algorithms and manufacturers, and TEEs support different attestation protocols. In
mechanisms. In order for TEEP to be inclusive, it is agnostic to the order for TEEP to be inclusive, it is agnostic to the format of
format of evidence, allowing proprietary or standardized formats to evidence, allowing proprietary or standardized formats to be used
be used between a TEE and a verifier (which may or may not be between a TEE and a verifier (which may or may not be colocated in
colocated in the TAM). However, it should be recognized that not all the TAM). However, it should be recognized that not all Verifiers
Verifiers may be able to process all proprietary forms of attestation may be able to process all proprietary forms of attestation evidence.
evidence. Similarly, the TEEP protocol is agnostic as to the format Similarly, the TEEP protocol is agnostic as to the format of
of attestation results, and the protocol (if any) used between the attestation results, and the protocol (if any) used between the TAM
TAM and a verifier, as long as they convey at least the required set and a verifier, as long as they convey at least the required set of
of claims in some format. claims in some format. Note that the respective attestation
algorithms are not defined in the TEEP protocol itself; see
The assumptions that may apply to an attestation have to do with the [I-D.ietf-rats-architecture] and [I-D.ietf-teep-protocol] for more
quality of the attestation and the quality and security provided by discussion.
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 There are a number of considerations that need to be considered when
when provisioning keys into devices/TEEs; appraising evidence provided by a TEE, including:
- Assumptions regarding what hardware and software components have - What security measures a manufacturer takes when provisioning keys
access to the attestation keys of the TEE; into devices/TEEs;
- Assumptions related to the source or local verification of claims - What hardware and software components have access to the
within an attestation prior to a TEE signing a set of claims; attestation keys of the TEE;
- Assumptions regarding the level of protection afforded to - The source or local verification of claims within an attestation
attestation keys against exfiltration, modification, and side prior to a TEE signing a set of claims;
channel attacks;
- Assumptions regarding the limitations of use applied to TEE - The level of protection afforded to attestation keys against
attestation keys; exfiltration, modification, and side channel attacks;
- Assumptions regarding the processes in place to discover or detect - The limitations of use applied to TEE attestation keys;
TEE breeches; and
- Assumptions regarding the revocation and recovery process of TEE - The processes in place to discover or detect TEE breeches; and
attestation keys.
TAMs must be comfortable with the assumptions that are inherently - The revocation and recovery process of TEE attestation keys.
part of any attestation result they accept. Alternatively, any TAM
may choose not to accept an attestation result generated using
evidence 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.
Some TAMs may require additional claims in order to properly Some TAMs may require additional claims in order to properly
authorize a device or TEE. These additional claims may help clear up authorize a device or TEE. The specific format for these additional
any assumptions for which the TAM wants to alleviate. The specific claims are outside the scope of this specification, but the TEEP
format for these additional claims are outside the scope of this protocol allows these additional claims to be included in the
specification, but the TEEP protocol allows these additional claims attestation messages.
to be included in the attestation messages.
For more discussion of the attestation and appraisal process, see the
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 and TA developer. Unique device
identification allows the TAM to provide services to the device, identification allows the TAM to provide services to the device,
such as managing installed TAs, and providing subscriptions to such as managing installed TAs, and providing subscriptions to
services, and locating device-specific keying material to services, and locating device-specific keying material to
communicate with or authenticate the device. In some use cases it communicate with or authenticate the device. In some use cases it
may be sufficient to identify only the class of the device. The may be sufficient to identify only the class of the device. The
security and privacy requirements regarding device identification security and privacy requirements regarding device identification
will vary with the type of TA provisioned to the TEE. will vary with the type of TA provisioned to the TEE.
- TEE Identifying info: The type of TEE that generated this - TEE Identifying info: The type of TEE that generated this
attestation must be identified, 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 resolve same TEE type created by different manufacturers and address
potential assumptions 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
skipping to change at page 24, line 48 skipping to change at page 25, line 39
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 considered during the greatly simplified when crypto agility is considered during the
design of the protocol. In the case of the TEEP protocol the diverse design of the protocol. In the case of the TEEP protocol the diverse
range of use cases, from trusted app updates for smart phones and range of use cases, from trusted app updates for smart phones and
tablets to updates of code on higher-end IoT devices, creates the tablets to updates of code on higher-end IoT devices, creates the
need for different mandatory-to-implement algorithms already from the need for different mandatory-to-implement algorithms already from the
start. 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. Symmetric algorithms are used for encryption asymmetric algorithms. In the context of TEEP symmetric algorithms
of content whereas the asymmetric algorithms are mostly used for are used for encryption of TA binaries and personalization data
signing messages. whereas the asymmetric algorithms are mostly used for signing
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
technology it supports. For many deployment cases it is more likely technology it supports. For many deployment cases it is more likely
for the TAM to support one or more attestation techniques whereas the for the TAM to support one or more attestation techniques whereas the
device may only support one. device may only support one.
9. Security Considerations 9. Security Considerations
skipping to change at page 26, line 23 skipping to change at page 27, line 16
A compromised REE might also request initiating the full flow of A compromised REE might also request initiating the full flow of
installation of TAs that are not necessary. It may also repeat a installation of TAs that are not necessary. It may also repeat a
prior legitimate TA installation request. A TEEP Agent prior legitimate TA installation request. A TEEP Agent
implementation is responsible for ensuring that it can recognize and implementation is responsible for ensuring that it can recognize and
decline such repeated requests. It is also responsible for decline such repeated requests. It is also responsible for
protecting the resource usage allocated for TA management. protecting the resource usage allocated for TA management.
9.4. Compromised CA 9.4. Compromised CA
A root CA for TAM certificates might get compromised. Some TEE Trust A root CA for TAM certificates might get compromised. A Trust Anchor
Anchor update mechanism is expected from device OEMs. TEEs are other than a root CA certificate may also be compromised. Some TEE
responsible for validating certificate revocation about a TAM Trust Anchor update mechanism is expected from device OEMs.
certificate chain.
TEEs are responsible for validating certificate revocation about a
TAM certificate chain, including the TAM certificate and the
intermediate CA certificates up to the root certificate. This will
detect a compromised TAM certificate and also any compromised
intermediate CA certificate.
If the root CA of some TEE device certificates is compromised, these If the root CA of some TEE device certificates is compromised, these
devices might be rejected by a TAM, which is a decision of the TAM devices might be rejected by a TAM, which is a decision of the TAM
implementation and policy choice. TAMs are responsible for implementation and policy choice. TAMs are responsible for
validating any intermediate CA for TEE device certificates. validating any intermediate CA for TEE device certificates.
9.5. Compromised TAM 9.5. Compromised TAM
Device TEEs are responsible for validating the supplied TAM Device TEEs are responsible for validating the supplied TAM
certificates to determine that the TAM is trustworthy. certificates to determine that the TAM is trustworthy.
skipping to change at page 27, line 23 skipping to change at page 28, line 21
during which a malicious TA might be able to operate successfully, during which a malicious TA might be able to operate successfully,
which is the validity time of the previous attestation result. For which is the validity time of the previous attestation result. For
example, if the Verifier in Figure 5 is updated to treat a previously example, if the Verifier in Figure 5 is updated to treat a previously
valid TA as no longer trustworthy, any attestation result it valid TA as no longer trustworthy, any attestation result it
previously generated saying that the TA is valid will continue to be previously generated saying that the TA is valid will continue to be
used until the attestation result expires. As such, the TAM's used until the attestation result expires. As such, the TAM's
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 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 update. On the other hand, it
is imperative that OEMs or device providers plan for support of Trust is imperative that OEMs or device providers plan for support of Trust
Anchor update in their shipped devices. Anchor update in their shipped devices.
For those cases where TEE devices are given certificates for which no
good expiration date can be assigned the recommendations in
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 developer 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 developer securely learning a public key of the TEE that it can
use to encrypt. One way to do this is for the TA developer to run use to encrypt. One way to do this is for the TA developer to run
its own TAM so that it can distribute the decryption key via the TEEP its own TAM so that it can distribute the decryption key via the TEEP
skipping to change at page 28, line 32 skipping to change at page 29, line 32
13. Informative References 13. Informative References
[GPTEE] GlobalPlatform, "GlobalPlatform Device Technology: TEE [GPTEE] GlobalPlatform, "GlobalPlatform Device Technology: TEE
System Architecture, v1.1", GlobalPlatform GPD_SPE_009, System Architecture, v1.1", GlobalPlatform 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-rats-architecture] [I-D.ietf-rats-architecture]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote Attestation Procedures Architecture", W. Pan, "Remote Attestation Procedures Architecture",
draft-ietf-rats-architecture-02 (work in progress), March draft-ietf-rats-architecture-04 (work in progress), May
2020. 2020.
[I-D.ietf-suit-manifest] [I-D.ietf-suit-manifest]
Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg,
"A Concise Binary Object Representation (CBOR)-based "A Concise Binary Object Representation (CBOR)-based
Serialization Format for the Software Updates for Internet Serialization Format for the Software Updates for Internet
of Things (SUIT) Manifest", draft-ietf-suit-manifest-04 of Things (SUIT) Manifest", draft-ietf-suit-manifest-07
(work in progress), March 2020. (work in progress), June 2020.
[I-D.ietf-teep-otrp-over-http] [I-D.ietf-teep-otrp-over-http]
Thaler, D., "HTTP Transport for Trusted Execution Thaler, D., "HTTP Transport for Trusted Execution
Environment Provisioning: Agent-to- TAM Communication", Environment Provisioning: Agent-to- TAM Communication",
draft-ietf-teep-otrp-over-http-05 (work in progress), draft-ietf-teep-otrp-over-http-06 (work in progress),
March 2020. April 2020.
[I-D.ietf-teep-protocol]
Tschofenig, H., Pei, M., Wheeler, D., Thaler, D., and A.
Tsukamoto, "Trusted Execution Environment Provisioning
(TEEP) Protocol", draft-ietf-teep-protocol-02 (work in
progress), April 2020.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management
Requirements", RFC 6024, DOI 10.17487/RFC6024, October Requirements", RFC 6024, DOI 10.17487/RFC6024, October
2010, <https://www.rfc-editor.org/info/rfc6024>. 2010, <https://www.rfc-editor.org/info/rfc6024>.
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting Mandatory-to-Implement Algorithms", Agility and Selecting Mandatory-to-Implement Algorithms",
BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
<https://www.rfc-editor.org/info/rfc7696>. <https://www.rfc-editor.org/info/rfc7696>.
[SGX] Intel, "Intel(R) Software Guard Extensions (Intel (R)
SGX)", n.d., <https://www.intel.com/content/www/us/en/
architecture-and-technology/software-guard-
extensions.html>.
[TrustZone]
Arm, "Arm TrustZone Technology", n.d.,
<https://developer.arm.com/ip-products/security-ip/
trustzone>.
Authors' Addresses Authors' Addresses
Mingliang Pei Mingliang Pei
Symantec Symantec
EMail: mingliang_pei@symantec.com EMail: mingliang_pei@symantec.com
Hannes Tschofenig Hannes Tschofenig
Arm Limited Arm Limited
 End of changes. 45 change blocks. 
146 lines changed or deleted 198 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/