TEEP Usecase for Confidential Computing in Network
Penglin Yang
Dawning Information Industry Co., Ltd.
No. 36, Zhongguancun Software Park, No.8, West Dongbeiwang Road, Haidian District
Beijing
100193
China
ypl_ietf@163.com
Meiling Chen
China Mobile
32 Xuanwumen West Street, Xicheng District
Beijing
100053
China
chenmeiling@chinamobile.com
Li Su
China Mobile
32 Xuanwumen West Street, Xicheng District
Beijing
100053
China
suli@chinamobile.com
Ting Pang
Huawei Technology Co.,Ltd.
127 Jinye Road, Yanta District
Xi'an
710077
China
pangting@huawei.com
21 June 2024
General
TEEP Working Group
Internet Draft
Confidential computing is the protection of data in use by performing computation in a hardware-based Trusted Execution Environment. Confidential computing could provide integrity and confidentiality for users who want to run applications and process data in that environment. When confidential computing is used in scenarios which need network to provision user data and applications, TEEP architecture and protocol could be used. This usecase illustrates the steps of how to deploy applications, containers, VMs and data in different confidential computing hardware in network. This document is a use case and extension of TEEP architecture and could provide guidance for cloud computing, MEC and other scenarios to use confidential computing in network.

Introduction
The Confidential Computing Consortium defined the concept of confidential computing as the protection of data in use by performing computation in a hardware-based Trusted Execution Environment [CCC-White-Paper]. In detail, computing unit with confidential computing feature could generate an isolated hardware-protected area, in which data and applications could be protected from illegal access or tampering. When using network to provision confidential computing, users need to choose appropriate steps to deploy their data and applications. This network could be in a cloud, MEC [MEC] or other network that provide confidential computing resource to users. For example in MEC, the autonomous vehicles could deploy private applications and data in confidential computing device to calculate on-vehicle and destination road information without knowing by MEC platform.
The TEEP WG defined the standardization of an architecture and protocol for managing the lifecycle of trusted applications running inside a TEE. In confidential computing, the TEE can also be provisioned and managed by TEEP architecture [I-D.ietf-teep-architecture] and protocol [I-D.ietf-teep-protocol]. By referring TEEP architecture and protocol, applications and data could be provisioned in confidential process, confidential container and confidential VM in different hardware architecture. The intended audiences for this use case are network users and operators who are interested in using confidential computing in network.

Terminology

Terms
The following terms are used in this document.
- Network Management/Orchestration Center(Network M/OC): M/OC exists in the management and orchestration layer of network. Network User uses the M/OC to request for computing resource. The TAM is inside the M/OC to provide management function to TEEP Agent via TEEP broker.
- Network User: Network User possesses personalization data and/or applications that need to be deployed on confidential computing device.
- Confidential Computing Device: Confidential Computing Device is connected by the network and can provide confidential computing service to Network User.
- Package: Package is a unit that is owned by Network User or TAM, and could be deployed on TEE/REE or treated as application data. If the TAM owns the Package, there must have no Personalization Data inside this Package. TA (Trusted Application) in confidential computing could be an application, or packaged with other components like library, TEE shim or even Guest OS. The specific package of confidential computing could refers to the white paper of [CCC_Common_Terminology] by CCC.
- Personalization Data(PD): Data that holds by Network User and needs to be protected by TEE during processing. Other terms like TAM, TEE, REE, TA will reuse the term definition defined in [I-D.ietf-teep-architecture].

Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Notional Architecture of using confidential computing in network
Figure 1 is the architecture of confidential computing in network. Two new components Network User and Network M/OC are introduced in this document. The connection between Network User and Network M/OC depends on the implementation of specific network. The connection between Network User and UA (Untrusted Application) or TA depends on the implementation of application. The connection between TAM, TEEP Broker and TEEP Agent refers to the TEEP protocol. Interactions of all components in this scenario are described in the Usecase section.

notional architecture of confidential computing in network

+--------------------------------------+
| Confidential Computing Device        |
|                       +--------+     |   +------------+
|  +-------------+      |        |     |   |Network M/OC|
|  | TEE         |      | TEEP   |     |   | +-------+  |
|  | +--------+  |  +---> Broker <----------->       |  |
|  | | TEEP   |  |  |   |        |     |   | |  TAM  |  |
|  | | Agent  |<----+   |        |     |   | |       |  |
|  | +--------+  |      |        <--+  |   | +---^---+  |
|  |             |      +--------+  |  |   +-----|------+
|  | +--------+  |                  |  |         |
|  | |   TA   |  |      +-------+   |  |         |
|  | |        |<-------->       |<--+  |         |
|  | +--------+  |      |  UA   |      |   +-----V------+
|  +-------------+      |       |<--------->Network User|
|                       +-------+      |   | (Package)  |
+--------------------------------------+   +------------+

Use Cases
The basic process of how a Network User utilizes confidential computing is shown below. At present, the main confidential instances types exist in industry are confidential process, confidential container and confidential VM. The definition of these instances could be found at [CCC-White-Paper]. Since confidential computing is a hardware-based technology, different hardware could support different confidential instances. This document gathers the main hardware architectures that support confidential computing, which include [TrustZone], [SGX], [SEV-SNP], [CCA], [TDX] and [CSV]. The following use cases are possible packaging models and how to deploy them in different hardware architecture. In the following tables, the brace means the operation steps to deploy packages. The arrow means deploy package to a destination. The "att" means attestation challenge for the target. All these actions in the following use cases could be expressed by TEEP protocol.
Case 1: UA, TA and PD are bundled as a package
In this case, UA, TA and PD are bundled as a package. This package is bundled by Network User and sends to TAM by specific netwwork. When TAM tries to deploy this package in confidential computing device, the process of TEEP is as follow.
1. Network User requests for confidential computing resource to Network M/OC.
2. M/OC orchestrates confidential computing device to undertake the request.
3. TAM requests remote attestation to TEEP Agent, TEEP Agent then sends the evidence to TAM. TAM works as Verifier in [RFC9334].
4. After verification, Network User works as Relying Party to receive the attestation result. If positive, Network User establishes secure channel [NIST-Special-Publication-800-133-V2] with TEEP Agent, and transfers this package to TEEP Agent.
5. TEEP Agent deploys TA and personalization data in TEE, then deploy UA in REE.
As for informing Network Users to develop their applications and data, the mapping of UA, TA and implementations are shown in figure 2.
TEEP Implementation of Case 1

+-------------+--------------------------------------------------+
|Package Model|                Case 1 (UA, TA, PD)               |
+-------------+----------------+----------------+----------------+
|             |  Confidential  |  Confidential  |                |
|  Instance   |   Process in   |  Container in  |  Confidential  |
|    Type     |   Physical or  |  Physical or   |       VM       |
|             | Virtual Machine| Virtual Machine|                |
+-------------+----------------+----------------+----------------+
|  Hardware   |    TrustZone,  | TrustZone, SGX,|    SEV, CCA    |
| Architecture|      SGX       |  SEV-SNP, CCA, |    TDX, CSV    |
|             |                |    TDX, CSV    |                |
+-------------+----------------+----------------+----------------+
|             |{att TEEP Agent,|{att TEEP Agent,|{att TEEP Agent,|
|    Load     |  (UA,TA,PD)->  |  (UA,TA,PD)->  |  (UA,TA,PD)->  |
|  Sequence   |  Confidential  |  Confidential  |  Confidential  |
|             |    Process,    |   Container,   |       VM,      |
|             |    UA->REE}    |    UA->REE}    |    UA->REE}    |
+-------------+----------------+----------------+----------------+

Case 2: PD is a separate package, TA and UA are integrated
In this use case, PD is a separate package, the UA and TA are integrated as a package. If Network User provides packages like this, the process of TEEP is as follow.
1. Network User requests for confidential computing resource to Network M/OC.
2. M/OC orchestrates confidential computing device to undertake the request.
3. Network User transfers UA and TA to confidential computing device via TAM. TAM then deploys these two applications in REE and TEE respectively. (In SGX, UA must be deployed first, then let UA to load TA in SGX.)
4. TAM requests remote attestation to TEEP Agent, TEEP Agent then sends the evidence to TAM. TAM works as Verifier in RATs architecture.
5. After verification, Network User works as Relying Party to receive the attestation result. If positive, Network User establishes secure channel with TA, and deploys personalization data to TA.
The mapping of UA, TA and implementations are shown in figure 3.
TEEP Implementation of Case 2

+-------------+--------------------------------------------------+
|Package Mode |               Case 2 (UA, TA) (PD)               |
+-------------+----------------+----------------+----------------+
|             |  Confidential  |  Confidential  |                |
|  Instance   |   Process in   |  Container in  |  Confidential  |
|    Type     |   Physical or  |  Physical or   |       VM       |
|             | Virtual Machine| Virtual Machine|                |
+-------------+----------------+----------------+----------------+
|  Hardware   |    TrustZone,  | TrustZone, SGX,|    SEV, CCA    |
| Architecture|      SGX       |  SEV-SNP, CCA, |    TDX, CSV    |
|             |                |    TDX, CSV    |                |
+-------------+----------------+----------------+----------------+
|             |   {UA->REE,    |    {UA->REE,   |   {UA->REE,    |
|             |TA->Confidential|TA->Confidential|TA->Confidential|
|    Load     |    Process,    |   Container,   |       VM,      |
|  Sequence   | att TEEP Agent,| att TEEP Agent,| att TEEP Agent,|
|             |    PD->TA}     |    PD->TA}     |     PD->TA}    |
+-------------+----------------+----------------+----------------+

Case 3: TA and PD are separate packages, with or without UA
In this case, Network User provides TA and PD as separate packages with or without UA. The process of TEEP in this case is as follow.
1. Network User requests for confidential computing resource to Network M/OC.
2. TAM in M/OC orchestrates confidential computing device to undertake the request.
3. Network User transfers UA to TAM, then TAM deploys UA in REE.
4. Network User transfers TA to TAM, then TAM transfers TA to TEEP Agent.
5. TAM requests remote attestation to TEEP Agent, TEEP Agent then sends the evidence to TAM. TAM works as Verifier in RATs architecture.
6. After verification, Network User works as Relying Party to receive the attestation result. If positive, Network User establishes secure channel with TA and transfers PD to it.
TEEP Implementation of Case 3

+-------------+--------------------------------------------------+
|Package Mode |        Case 3 (TA),(PD) or (TA),(PD),(UA)        |
+-------------+----------------+----------------+----------------+
|             |  Confidential  |  Confidential  |                |
|  Instance   |   Process in   |  Container in  |  Confidential  |
|    Type     |   Physical or  |  Physical or   |       VM       |
|             | Virtual Machine| Virtual Machine|                |
+-------------+----------------+----------------+----------------+
|  Hardware   |    TrustZone,  | TrustZone, SGX,|    SEV, CCA    |
| Architecture|      SGX       |  SEV-SNP, CCA, |    TDX, CSV    |
|             |                |    TDX, CSV    |                |
+-------------+----------------+----------------+----------------+
|    Load     |    {UA->REE,   |    {UA->REE,   |   {UA->REE,    |
|  Sequence   |TA->Confidential|TA->Confidential|TA->Confidential|
|             |    Process,    |    Container   |       VM,      |
|             | att TEEP Agent,| att TEEP Agent,| att TEEP Agent,|
|             |    PD->TA}     |    PD->TA}     |    PD->TA}     |
+-------------+----------------+----------------+----------------+

Case 4: TA and PD are bundled as a package, with or without UA
In this case, the process of TEEP is as follow.
1. Network User requests for confidential computing resource to Network M/OC.
2. TAM in M/OC orchestrates confidential computing device to undertake the request.
3. If there has UA, Network User deploys UA in REE.
4. TAM requests remote attestation to TEEP Agent, TEEP Agent then sends the evidence to TAM. The TAM works as Verifier in RATs architecture.
5. After verification, Network User works as Relying Party to receive the attestation result. If positive, Network User establishes secure channel with TEEP Agent and transfers TA and PD package to TEEP Agent.
TEEP Implementation of Case 4

+-------------+--------------------------------------------------+
|Package Mode |      Case 4 (TA, PD) (UA) or (TA, PD)            |
+-------------+----------------+----------------+----------------+
|             |  Confidential  |  Confidential  |                |
|  Instance   |   Process in   |  Container in  |  Confidential  |
|    Type     |   Physical or  |  Physical or   |       VM       |
|             | Virtual Machine| Virtual Machine|                |
+-------------+----------------+----------------+----------------+
|  Hardware   |    TrustZone,  | TrustZone, SGX,|    SEV, CCA    |
| Architecture|      SGX       |  SEV-SNP, CCA, |    TDX, CSV    |
|             |                |    TDX, CSV    |                |
+-------------+----------------+----------------+----------------+
|             |   {UA->REE,    |    {UA->REE,   |    {UA->REE,   |
|    Load     | att TEEP Agent,| att TEEP Agent,| att TEEP Agent,|
|  Sequence   |   (TA,PD)->    |   (TA,PD)->    |    (TA,PD)->   |
|             |  Confidential  |  Confidential  |  Confidential  |
|             |   Process}     |   Container}   |       VM}      |
+-------------+----------------+----------------+----------------+

Case 5: PD and UA are bundled as a package, TA is a separate package
In this case, the process of TEEP is as follow.
1. Network User requests for confidential computing resource to Network M/OC.
2. TAM in M/OC orchestrates confidential computing device to undertake the request.
3. TAM requests remote attestation to TEEP Agent, TEEP Agent then sends the evidence to TAM. The TAM works as Verifier in RATs architecture.
4. After verification, Network User works as Relying Party to receive the attestation result. If positive, TAM deploys TA in TEE.
5. TA decrypts the PD and UA package inside TEE.
TEEP Implementation of Case 5

+-------------+--------------------------------------------------+
|Package Mode |               Case 5 (UA, PD) (TA)               |
+-------------+----------------+----------------+----------------+
|             |  Confidential  |  Confidential  |                |
|  Instance   |   Process in   |  Container in  |  Confidential  |
|    Type     |   Physical or  |  Physical or   |       VM       |
|             | Virtual Machine| Virtual Machine|                |
+-------------+----------------+----------------+----------------+
|  Hardware   |    TrustZone,  | TrustZone, SGX,|    SEV, CCA    |
| Architecture|      SGX       |  SEV-SNP, CCA, |    TDX, CSV    |
|             |                |    TDX, CSV    |                |
+-------------+----------------+----------------+----------------+
|             |{att TEEP Agent,|{att TEEP Agent,|{att TEEP Agent,|
|    Load     |      TA->      |      TA->      |      TA->      |
|  Sequence   |  Confidential  |  Confidential  |  Confidential  |
|             |    Process,    |   Container,   |      VM,       |
|             |  (UA,PD)->TA}  |  (UA,PD)->TA}  |  (UA,PD)->TA}  |
+-------------+----------------+----------------+----------------+

IANA Considerations
This document does not require actions by IANA.

Security Considerations
Besides the security considerations in TEEP architecture, there is no more security and privacy issues in this document.

Acknowledgements
Many thanks to Dave Thaler, Eric Voit, Hannes Tschofenig, the CCC TAC meeting and other people who provide comments and suggestions.

Normative Reference

Informative Reference
[NIST-Special-Publication-800-133-V2]

Recommendation for Cryptographic Key Generation
NIST
June 2020
[MEC]

Multi-access Edge Computing (MEC);Framework and Reference Architecture
ETSI
March 2022
[CCC-White-Paper]

Confidential Computing: Hardware-Based Trusted Execution for Applications and Data
Confidential Computing Consortium
January 2021
[CCC Common Terminology]

Common Terminology for Confidential Computing
Confidential Computing Consortium
October 2022
[CSV]

HYGON China Secure Virtualization
HYGON
May 2023
[TrustZone]

Kunpeng BoostKit for Confidential Computing TrustZone Kit
HUAWEI Technologies
January 2022
[SGX]

Overview of Intel Software Guard Extension
Intel
June 2016
[SEV-SNP]

AMD SEV-SNP: Strengthening VM-isolation-with-integrity-protection-and-more
Advanced Micro Devices
January 2020
[CCA]

Arm Confidential Computing Architecture
ARM
March 2022
[TDX]

Intel Trust Domain Extensions
Intel
August 2021
[I-D.ietf-teep-architecture]
[I-D.ietf-teep-protocol]
[CCC_Common_Terminology]
[RFC9334]

Submodules in TEEP Agent
The original design of TEEP only includes TEEP Agent and TA inside TEE. While in confidential computing implementation, other submodules may also be involved in the TEE. In TEEP, these submodules could be covered by TEEP Agent.
In SGX based confidential computing, submodule could provide convenient environment or API in which TA does not have to modify its source code to fit into SGX instructions. Submodules like Gramine and Occlum .etc are examples that could be included in TEEP Agent. If there is no submodule in TEEP Agent, the TA and UA need to be customized applications which fit into the SGX architecture.
In SEV and other architectures that support whole guest VM as a TEE, TEEP Agent doesn't have to use extra submodule to work as a middleware or API. However with some submodules like Enarx which works as a runtime JIT compiler, TA could be deployed in a hardware independent way. In this scenario, TA could be deployed in different hardware architecture without re-compiling.