draft-ietf-teep-architecture-07.txt   draft-ietf-teep-architecture-08.txt 
TEEP M. Pei TEEP M. Pei
Internet-Draft Symantec Internet-Draft Symantec
Intended status: Informational H. Tschofenig Intended status: Informational H. Tschofenig
Expires: September 8, 2020 Arm Limited Expires: October 6, 2020 Arm Limited
D. Thaler D. Thaler
Microsoft Microsoft
D. Wheeler D. Wheeler
Intel Intel
March 07, 2020 April 04, 2020
Trusted Execution Environment Provisioning (TEEP) Architecture Trusted Execution Environment Provisioning (TEEP) Architecture
draft-ietf-teep-architecture-07 draft-ietf-teep-architecture-08
Abstract Abstract
A Trusted Execution Environment (TEE) is an environment that enforces A Trusted Execution Environment (TEE) is an environment that enforces
that only authorized code can execute within that environment, 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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 8, 2020. This Internet-Draft will expire on October 6, 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 3, line 39 skipping to change at page 3, line 39
complexity of features and applications on devices, and the complexity of features and applications on devices, and the
unintended interactions among those features and applications. The unintended interactions among those features and applications. The
danger of attacks on a system increases as the sensitivity of the danger of attacks on a system increases as the sensitivity of the
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
only authorized code can execute within that environment, 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).
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),
skipping to change at page 14, line 21 skipping to change at page 14, line 21
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 is dependent on the TEE, the TA, and the TA developer; 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. The personalization data must to communicate with the TA developer. Implementations must support
be encrypted to preserve the confidentiality of potentially sensitive encryption of personalization data to preserve the confidentiality of
data contained within it. Other than this requirement to support potentially sensitive data contained within it. Other than this
confidentiality, the TEEP architecture places no limitations or requirement to support confidentiality, the TEEP architecture places
requirements on the personalization data. 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 25, line 48 skipping to change at page 25, line 48
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 have such mitigate DoS attacks against it but most TEEs don't have such a
capability. capability.
In some other scenarios, the compromised REE may ask a TEEP Broker to In some other scenarios, the compromised REE may ask a TEEP Broker to
make repeated requests to a TEEP Agent in a TEE to install or make repeated requests to a TEEP Agent in a TEE to install or
uninstall a TA. A TA installation or uninstallation request uninstall a TA. A TA installation or uninstallation request
constructed by the TEEP Broker or REE will be rejected by the TEEP constructed by the TEEP Broker or REE will be rejected by the TEEP
Agent because the request won't have the correct signature from a TAM Agent because the request won't have the correct signature from a TAM
to pass the request signature validation. to pass the request signature validation.
This can become a DoS attack by exhausting resources in a TEE with This can become a DoS attack by exhausting resources in a TEE with
skipping to change at page 27, line 5 skipping to change at page 27, line 5
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. 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
example whenever the RequestPolicyCheck API (Section 6.2.1) is
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
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
skipping to change at page 28, line 30 skipping to change at page 28, line 30
feedback. feedback.
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., and N. Smith, Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
"Remote Attestation Procedures Architecture", draft-ietf- W. Pan, "Remote Attestation Procedures Architecture",
rats-architecture-01 (work in progress), February 2020. draft-ietf-rats-architecture-02 (work in progress), March
2020.
[I-D.ietf-suit-manifest] [I-D.ietf-suit-manifest]
Moran, B., Tschofenig, H., and H. Birkholz, "A Concise Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg,
Binary Object Representation (CBOR)-based Serialization "A Concise Binary Object Representation (CBOR)-based
Format for the Software Updates for Internet of Things Serialization Format for the Software Updates for Internet
(SUIT) Manifest", draft-ietf-suit-manifest-03 (work in of Things (SUIT) Manifest", draft-ietf-suit-manifest-04
progress), February 2020. (work in progress), March 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-04 (work in progress), draft-ietf-teep-otrp-over-http-05 (work in progress),
February 2020. March 2020.
[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management
Requirements", RFC 6024, DOI 10.17487/RFC6024, October Requirements", RFC 6024, DOI 10.17487/RFC6024, October
2010, <https://www.rfc-editor.org/info/rfc6024>. 2010, <https://www.rfc-editor.org/info/rfc6024>.
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting Mandatory-to-Implement Algorithms", Agility and Selecting Mandatory-to-Implement Algorithms",
BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
<https://www.rfc-editor.org/info/rfc7696>. <https://www.rfc-editor.org/info/rfc7696>.
 End of changes. 12 change blocks. 
23 lines changed or deleted 27 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/