Skip to content

Commit fc5dc5f

Browse files
anta5010anta5010
committed
Add CCA Trustee Learning Path
Signed-off-by: Anton Antonov <[email protected]>
1 parent a866b5e commit fc5dc5f

File tree

6 files changed

+540
-0
lines changed

6 files changed

+540
-0
lines changed

‎content/learning-paths/servers-and-cloud-computing/cca-trustee/_index.md

Lines changed: 62 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,62 @@
1+
---
2+
title: Run an end-to-end Attestation Flow with Arm CCA and Trustee
3+
4+
minutes_to_complete: 60
5+
6+
who_is_this_for: This Learning Path is for software developers who want to learn how Trustee services can be used to run an end-to-end attestation flow with Arm's Confidential Computing Architecture (CCA).
7+
8+
learning_objectives:
9+
- Describe how you can use attestation with Arm's Confidential Computing Architecture (CCA) and Trustee services.
10+
- Deploy a simple workload in a CCA realm on an Armv9-A AEM Base Fixed Virtual Platform (FVP) that has support for RME extensions.
11+
- Connect the workload with Trustee services to create an end-to-end example that uses attestation to unlock the confidential processing of data.
12+
13+
prerequisites:
14+
- An AArch64 or x86_64 computer running Linux or MacOS. You can use cloud instances, see this list of [Arm cloud service providers](/learning-paths/servers-and-cloud-computing/csp/).
15+
- Completion of the [Get Started with CCA Attestation and Veraison](/learning-paths/servers-and-cloud-computing/cca-veraison) Learning Path.
16+
- Completion of the [Run an end-to-end Attestation Flow with Arm CCA](/learning-paths/servers-and-cloud-computing/cca-essentials/) Learning Path.
17+
18+
author:
19+
- Anton Antonov
20+
21+
### Tags
22+
skilllevels: Advanced
23+
subjects: Performance and Architecture
24+
armips:
25+
- Neoverse
26+
- Cortex-A
27+
operatingsystems:
28+
- Linux
29+
- MacOS
30+
tools_software_languages:
31+
- FVP
32+
- RME
33+
- CCA
34+
- Docker
35+
- Veraison
36+
- Trustee
37+
38+
further_reading:
39+
- resource:
40+
title: Arm Confidential Compute Architecture
41+
link: https://www.arm.com/architecture/security-features/arm-confidential-compute-architecture
42+
type: website
43+
- resource:
44+
title: Arm Confidential Compute Architecture open source enablement
45+
link: https://www.youtube.com/watch?v=JXrNkYysuXw
46+
type: video
47+
- resource:
48+
title: Learn the architecture - Realm Management Extension
49+
link: https://developer.arm.com/documentation/den0126
50+
type: documentation
51+
- resource:
52+
title: Realm Management Monitor specification
53+
link: https://developer.arm.com/documentation/den0137/latest/
54+
type: documentation
55+
56+
57+
### FIXED, DO NOT MODIFY
58+
# ================================================================================
59+
weight: 1 # _index.md always has weight of 1 to order correctly
60+
layout: "learningpathall" # All files under learning paths have this same wrapper
61+
learning_path_main_page: "yes" # This should be surfaced when looking for related content. Only set for _index.md of learning path content.
62+
---

‎content/learning-paths/servers-and-cloud-computing/cca-trustee/_next-steps.md

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
---
2+
# ================================================================================
3+
# FIXED, DO NOT MODIFY THIS FILE
4+
# ================================================================================
5+
weight: 21 # Set to always be larger than the content in this path to be at the end of the navigation.
6+
title: "Next Steps" # Always the same, html page title.
7+
layout: "learningpathall" # All files under learning paths have this same wrapper for Hugo processing.
8+
---

‎content/learning-paths/servers-and-cloud-computing/cca-trustee/attestation-services.png

19.9 KB
Loading

‎content/learning-paths/servers-and-cloud-computing/cca-trustee/cca-trustee.md

Lines changed: 152 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,152 @@
1+
---
2+
# User change
3+
title: "Overview of the Software Architecture"
4+
5+
weight: 2 # 1 is first, 2 is second, etc.
6+
7+
# Do not modify these elements
8+
layout: "learningpathall"
9+
---
10+
11+
## The role of Attestation
12+
In this Learning Path, you will learn how attestation can control the release
13+
of confidential data into a confidential Linux realm for processing.
14+
15+
The role of attestation is to assess whether the target compute environment
16+
offers a provable level of confidential isolation. In this Learning Path,
17+
the target compute environment is a Linux realm. The assessment of a provable
18+
level of confidential isolation needs to occur before the realm can be trusted
19+
to receive confidential data or algorithms. This use of attestation to judge
20+
the trustworthiness of a compute environment, before allowing it to do any
21+
processing, is a common practice in confidential computing.
22+
23+
## Understanding the key software components
24+
25+
This Learning Path is similar to
26+
[Run an end-to-end Attestation Flow with Arm CCA](/learning-paths/servers-and-cloud-computing/cca-essentials/).
27+
28+
The main difference is that instead of KBS from the [Veraison](https://github.com/veraison) project you will use
29+
the components implemented in the [confidential containers (CoCo)](https://github.com/confidential-containers)
30+
to support the [IETF RATS model](https://datatracker.ietf.org/doc/rfc9334/)
31+
(Remote ATtestation procedureS Architecture). The components include the Attestation Service (AS),
32+
Key Broker Service (KBS), Reference Value Provider Service (RVPS), Attestation Agent (AA), and Confidential Data Hub (CDH).
33+
The AS, KBS, and RVPS components are part of the [Trustee project](https://github.com/confidential-containers/trustee),
34+
whereas the AA and CDH are part of the [Guest Components](https://github.com/confidential-containers/guest-components) project in CoCo.
35+
36+
### RATS key components
37+
38+
This is a list of components used in this Learning Path:
39+
40+
- `Attester` - provides Evidence, which is evaluated and appraised to decide its
41+
trustworthiness (for instance, a test to see whether it’s authorized to perform some action).
42+
Evidence may include configuration data, measurements, telemetry, or inferences.
43+
- `Verifier` - evaluates the validity of the evidence received from the attester
44+
and produces attestation results, which are sent to the Relying party.
45+
Attestation results typically include information regarding the Attester,
46+
while the Verifier vouches for the validity of the results.
47+
- `Relying party` - depends on the validity of information originating from
48+
the attester for reliably applying an action. This information can come
49+
from the verifier or directly through the attester.
50+
51+
### Trustee components
52+
53+
The Trustee project includes components deployed on a trusted side and used to verify
54+
whether the remote workload is running in a trusted execution environment (TEE).
55+
It also verifies that the remote environment uses the expected software and hardware versions.
56+
57+
#### Key Broker Service (KBS)
58+
59+
The Key Broker Service (KBS) facilitates remote attestation and managing
60+
and delivering secrets. Equating this to the RATS model, the KBS is the
61+
`relying party` entity. The KBS, however, doesn’t validate the attestation evidence.
62+
Instead, it uses the attestation service (AS) to verify the TEE evidence.
63+
64+
#### Attestation Service (AS)
65+
66+
The Attestation Service (AS) is responsible for validating the TEE evidence.
67+
When mapped to the RATS model, the AS is the equivalent of the `verifier`.
68+
The AS receives attestation evidence and returns an attestation token
69+
containing the results of a two-step verification process.
70+
71+
The following diagram shows the AS components:
72+
73+
![attestation-services](attestation-services.png "Attestation Service components")
74+
75+
The AS runs the following verification process:
76+
77+
1. Verify the formatting and the origin of the evidence - for example, checking the signature of the evidence.
78+
This is accomplished by one of the platform-specific Verifier Drivers.
79+
2. Evaluate the claims provided in the evidence - for example, validating that the measurements are what the
80+
client expects. This is done by a Policy Engine with help from the RVPS.
81+
82+
##### Verifier driver
83+
84+
A verifier driver parses the attestation evidence provided by the hardware TEE. It performs the following tasks:
85+
86+
1. Verifies the hardware TEE signature of the TEE quote and report provided in the evidence
87+
2. Receives the evidence and organizes the status into a JSON format to be returned
88+
89+
In this Learning Path AS is configured to use an external CCA verifer.
90+
91+
[Linaro](https://www.linaro.org) provides such an attestation verifier for use with pre-silicon CCA platforms.
92+
This verifier is built from the Open-Source [Veraison project](https://github.com/veraison).
93+
You can learn more about Veraison and Linaro attestation verifier service in
94+
[Get Started with CCA Attestation and Veraison](https://learn.arm.com/learning-paths/servers-and-cloud-computing/cca-veraison/)
95+
96+
##### Policy Engine
97+
98+
The AS allows users to upload their own policies when performing evidence verification.
99+
When an attestation request is received by the AS, it uses a policy ID in the request
100+
to decide which policies should be evaluated.
101+
The results of all policies evaluated are included in the attestation response.
102+
103+
In this Learning Path AS attestation policy includes specific Arm CCA rules.
104+
105+
#### Reference Value Provider Service (RVPS)
106+
107+
The reference value provider service (RVPS) is a component in the AS responsible for verifying,
108+
storing, and providing reference values. RVPS receives and verifies inputs from the software
109+
supply chain, stores the measurement values, and generates reference value claims for the AS.
110+
This operation is performed based on the evidence verified by the AS.
111+
112+
113+
### Guest components
114+
115+
The guest components are the services/tools that run inside the realm (TEE).
116+
When mapped to the RATS model, these components are the equivalent of the `Attester`.
117+
118+
For simplicity instead of Attestation Agent (AA) and Confidential Data Hub (CDH)
119+
you will use [KBS Client Tool](https://github.com/confidential-containers/trustee/tree/main/tools/kbs-client)
120+
121+
This is a simple client for the KBS that facilitates basic attestation flows.
122+
You will run this tool inside of a realm to make requests for an attestation result token (EAR) and a secret.
123+
124+
The client tool can also be used to provision the KBS/AS with resources and policies.
125+
126+
KBS Client connects to the KBS in order to perform attestation. To prove the trustworthiness of the environment
127+
KBS Client sends the evidence (claims) from the TEE in the form of a CCA attestaion token.
128+
You can learn more about CCA attestation tokens in
129+
[Get Started with CCA Attestation and Veraison](https://learn.arm.com/learning-paths/servers-and-cloud-computing/cca-veraison/)
130+
131+
For convenience, Trustee services and the client software are packaged in
132+
docker containers, which you can execute on any suitable AArch64 or x86_64
133+
development machine. Since the client software runs in a realm, it makes use
134+
of the Fixed Virtual Platform (FVP) and the reference software stack for Arm CCA.
135+
If you have not yet familiarized yourself with running applications in realms using
136+
FVP and the reference software stack, see the
137+
[Run an application in a Realm using the Arm Confidential Computing Architecture (CCA)](/learning-paths/servers-and-cloud-computing/cca-container)
138+
Learning Path.
139+
140+
When the AS receives an attestation token from the realm via KBS:
141+
- it calls an external CCA verifer (the Linaro attestation verifier service) to obtain an attestation result.
142+
- the external CCA verifer checks the token's cryptographic signature,
143+
verifies that it denotes a confidential computing platform and provides an attestation result.
144+
- AS also checks the token evidences against a its own attestation policies and updates attestation result status and trustworthiness vectors.
145+
146+
When asked for a resource the KBS uses the attestation result to decide whether to release the secrets into the realm for processing.
147+
148+
Figure 1 demonstrates the software architecture that you will construct to run the attestation example.
149+
150+
![cca-trustee](trustee.png "Figure 1: Software architecture for running attestation.")
151+
152+
You can now proceed to the next section to run the end-to-end attestation example with the software components and architecture as described here.

0 commit comments

Comments
 (0)