Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add applicability text #218

Merged
merged 1 commit into from Feb 21, 2021
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
35 changes: 35 additions & 0 deletions draft-ietf-teep-architecture.md
Expand Up @@ -62,6 +62,20 @@ informative:
target: https://globalplatform.org/specs-library/tee-system-architecture-v1-1/
seriesinfo:
GlobalPlatform: GPD_SPE_009
GSMA:
author:
org: GSM Association
title: "GP.22 RSP Technical Specification, Version 2.2.2"
date: 2020-06
target: https://www.gsma.com/esim/wp-content/uploads/2020/06/SGP.22-v2.2.2.pdf
OTRP:
author:
org: GlobalPlatform
title: "Open Trust Protocol (OTrP) Profile v1.1"
date: 2020-07
target: https://globalplatform.org/specs-library/tee-management-framework-open-trust-protocol/
seriesinfo:
GlobalPlatform: GPD_SPE_123
SGX:
author:
org: Intel
Expand Down Expand Up @@ -177,6 +191,14 @@ the following problems:
been revoked or is not used for other reasons anymore (e.g., due to an
expired subscription).

For TEEs that simply verify and load signed TA's from an untrusted
filesystem, classic application distribution protocols can be used
without modification. The problems in the bullets above, on the other hand,
require a new protocol, i.e.,
the TEEP protocol, for TEEs that can install and enumerate TAs in a
TEE-secured location and where another domain-specific protocol standard
(e.g., {{GSMA}}, {{OTRP}}) that meets the needs is not already in use.

# Terminology {#terminology}

The following terms are used:
Expand Down Expand Up @@ -649,6 +671,13 @@ would pass this data to the installed Untrusted Application, which would in turn
to the SGX enclave (TA). This complexity is due to the fact that each SGX enclave is separate
and does not have direct communication to other SGX enclaves.

As long as signed files (TAs and/or Personalization Data) are installed into
an untrusted filesystem and trust is verified by the TEE at load time, classic
distribution mechanisms can be used. Some uses of SGX, however, allow a model
where a TA can be dynamically installed into an SGX enclave that
provides a runtime platform. The TEEP protocol can be used in
such cases, where the runtime platform could include a TEEP Agent.

### 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
Expand All @@ -661,6 +690,12 @@ with each other without involving any Untrusted Application, and so the complexi
is lower than in the SGX example. Thus, Case 1 is possible as well, though still more
complex than Cases 2 and 3.

TEE OS's (e.g., OP-TEE) that support loading and verifying signed TAs from
an untrusted filesystem can, like SGX, use classic file distribution
mechanisms. If secure TA storage is used (e.g., a Replay-Protected
Memory Block device) on the other hand, the TEEP protocol can be used
to manage such storage.

## Entity Relations

This architecture leverages asymmetric cryptography to
Expand Down