Merge pull request #2296 from madeline-underwood/CCA_Trustee

pareenaverma · web-flow · commit 8dd646cbaa38 · 2025-09-09T09:01:05.000-04:00
Cca trustee_PV to sign off
diff --git a/content/learning-paths/servers-and-cloud-computing/cca-trustee/_index.md b/content/learning-paths/servers-and-cloud-computing/cca-trustee/_index.md
@@ -1,62 +1,57 @@
 ---
-title: Run an end-to-end Attestation Flow with Arm CCA and Trustee
-
-draft: true
-cascade:
-    draft: true
-    
+title: Run an end-to-end attestation flow with Arm CCA and Trustee
+   
 minutes_to_complete: 60
 
-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).
+who_is_this_for: This Learning Path is for software developers who want to run an end-to-end attestation flow using Arm Confidential Compute Architecture (CCA) and Trustee services.
 
 learning_objectives:
-     - Describe how you can use attestation with Arm's Confidential Computing Architecture (CCA) and Trustee services.
-     - Deploy a simple workload in a CCA realm on an Armv9-A AEM Base Fixed Virtual Platform (FVP) that has support for RME extensions.
-     - Connect the workload with Trustee services to create an end-to-end example that uses attestation to unlock the confidential processing of data.
+  - Describe how you can use attestation with Arm's Confidential Computing Architecture (CCA) and Trustee services
+  - Deploy a simple workload in a CCA realm on an Armv9-A AEM Base Fixed Virtual Platform (FVP) that has support for RME extensions
+  - Connect the workload with Trustee services to create an end-to-end example that uses attestation to unlock the confidential processing of data
 
 prerequisites:
-    - 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/).
-    - Completion of the [Get Started with CCA Attestation and Veraison](/learning-paths/servers-and-cloud-computing/cca-veraison) Learning Path.
-    - Completion of the [Run an end-to-end Attestation Flow with Arm CCA](/learning-paths/servers-and-cloud-computing/cca-essentials/) Learning Path.
+  - An AArch64 or x86_64 computer running Linux or macOS; you can use cloud instances - see the [Arm cloud service providers](/learning-paths/servers-and-cloud-computing/csp/)
+  - Completion of the [Get started with CCA attestation and Veraison](/learning-paths/servers-and-cloud-computing/cca-veraison) Learning Path
+  - Completion of the [Run an end-to-end attestation flow with Arm CCA](/learning-paths/servers-and-cloud-computing/cca-essentials/) Learning Path
 
 author:
-    - Anton Antonov
+  - Anton Antonov
 
 ### Tags
 skilllevels: Advanced
 subjects: Performance and Architecture
 armips:
-    - Neoverse
-    - Cortex-A
+  - Neoverse
+  - Cortex-A
 operatingsystems:
-    - Linux
-    - MacOS
+  - Linux
+  - macOS
 tools_software_languages:
-    - FVP
-    - RME
-    - CCA
-    - Docker
-    - Veraison
-    - Trustee
+  - FVP
+  - RME
+  - CCA
+  - Docker
+  - Veraison
+  - Trustee
 
 further_reading:
-    - resource:
-        title: Arm Confidential Compute Architecture
-        link: https://www.arm.com/architecture/security-features/arm-confidential-compute-architecture
-        type: website
-    - resource:
-        title: Arm Confidential Compute Architecture open source enablement
-        link: https://www.youtube.com/watch?v=JXrNkYysuXw
-        type: video
-    - resource:
-        title: Learn the architecture - Realm Management Extension
-        link: https://developer.arm.com/documentation/den0126
-        type: documentation
-    - resource:
-        title: Realm Management Monitor specification
-        link: https://developer.arm.com/documentation/den0137/latest/
-        type: documentation
-
+  - resource:
+      title: Arm Confidential Compute Architecture
+      link: https://www.arm.com/architecture/security-features/arm-confidential-compute-architecture
+      type: website
+  - resource:
+      title: Arm Confidential Compute Architecture open-source enablement
+      link: https://www.youtube.com/watch?v=JXrNkYysuXw
+      type: video
+  - resource:
+      title: Learn the architecture - Realm Management Extension
+      link: https://developer.arm.com/documentation/den0126
+      type: documentation
+  - resource:
+      title: Realm Management Monitor specification
+      link: https://developer.arm.com/documentation/den0137/latest/
+      type: documentation
 
 ### FIXED, DO NOT MODIFY
 # ================================================================================
diff --git a/content/learning-paths/servers-and-cloud-computing/cca-trustee/cca-trustee.md b/content/learning-paths/servers-and-cloud-computing/cca-trustee/cca-trustee.md
@@ -1,152 +1,104 @@
 ---
 # User change
-title: "Overview of the Software Architecture"
+title: "Architecture overview for Arm CCA Attestation with Trustee"
 
 weight: 2 # 1 is first, 2 is second, etc.
 
 # Do not modify these elements
 layout: "learningpathall"
 ---
 
-## The role of Attestation
-In this Learning Path, you will learn how attestation can control the release
-of confidential data into a confidential Linux realm for processing.
+## The role of attestation
 
-The role of attestation is to assess whether the target compute environment
-offers a provable level of confidential isolation. In this Learning Path,
-the target compute environment is a Linux realm. The assessment of a provable
-level of confidential isolation needs to occur before the realm can be trusted
-to receive confidential data or algorithms. This use of attestation to judge
-the trustworthiness of a compute environment, before allowing it to do any
-processing, is a common practice in confidential computing.
+In this Learning Path, you will learn how attestation controls the release of confidential data into a confidential Linux realm for processing. The role of attestation is to assess whether the target compute environment offers a provable level of confidential isolation. In this Learning Path,
+the target compute environment is a Linux realm. The assessment of a provable level of confidential isolation must occur before the realm can be trusted to receive confidential data or algorithms. This use of attestation to judge the trustworthiness of a compute environment, before allowing it to do any processing, is a common practice in confidential computing.
 
-## Understanding the key software components
+## Key software components
 
 This Learning Path is similar to
-[Run an end-to-end Attestation Flow with Arm CCA](/learning-paths/servers-and-cloud-computing/cca-essentials/).
-
-The main difference is that instead of KBS from the [Veraison](https://github.com/veraison) project you will use
-the components implemented in the [confidential containers (CoCo)](https://github.com/confidential-containers)
-to support the [IETF RATS model](https://datatracker.ietf.org/doc/rfc9334/)
-(Remote ATtestation procedureS Architecture). The components include the Attestation Service (AS),
-Key Broker Service (KBS), Reference Value Provider Service (RVPS), Attestation Agent (AA), and Confidential Data Hub (CDH).
+[Run an end-to-end Attestation Flow with Arm CCA](/learning-paths/servers-and-cloud-computing/cca-essentials/). The main difference is that, instead of the KBS from the [Veraison](https://github.com/veraison) project, you will use components implemented in the [Confidential Containers (CoCo) Project](https://github.com/confidential-containers) to support the [IETF RATS model](https://datatracker.ietf.org/doc/rfc9334/) (Remote ATtestation procedureS). These components include the Attestation Service (AS), Key Broker Service (KBS), Reference Value Provider Service (RVPS), Attestation Agent (AA), and Confidential Data Hub (CDH).
 The AS, KBS, and RVPS components are part of the [Trustee project](https://github.com/confidential-containers/trustee),
 whereas the AA and CDH are part of the [Guest Components](https://github.com/confidential-containers/guest-components) project in CoCo.
 
-### RATS key components
+## RATS roles
 
-This is a list of components used in this Learning Path:
+This Learning Path focuses on the following key concepts:
 
-- `Attester` - provides Evidence, which is evaluated and appraised to decide its
-   trustworthiness (for instance, a test to see whether it’s authorized to perform some action).
-   Evidence may include configuration data, measurements, telemetry, or inferences.
-- `Verifier` - evaluates the validity of the evidence received from the attester
-   and produces attestation results, which are sent to the Relying party.
-   Attestation results typically include information regarding the Attester,
-   while the Verifier vouches for the validity of the results.
-- `Relying party` - depends on the validity of information originating from
-   the attester for reliably applying an action. This information can come
-   from the verifier or directly through the attester.
+- **Attester** – provides evidence that is evaluated to decide **Trustworthiness** (for example, whether it is authorized to perform an action). 
+- **Evidence** can include configuration data, measurements, telemetry, or inferences.
+- **Verifier** – evaluates the evidence from the Attester and produces attestation results that are sent to the Relying party. The Verifier vouches for the validity of those results.
+- **Relying party** – depends on the validity of information from the Attester (either directly or through the Verifier) to make an access or policy decision.
 
-### Trustee components
+## Trustee components
 
-The Trustee project includes components deployed on a trusted side and used to verify
-whether the remote workload is running in a trusted execution environment (TEE).
-It also verifies that the remote environment uses the expected software and hardware versions.
+Trustee components run on the trusted side and verify whether a remote workload is executing in a trusted execution environment (TEE) and using the expected software and hardware versions.
 
-#### Key Broker Service (KBS)
+## Key Broker Service (KBS)
 
-The Key Broker Service (KBS) facilitates remote attestation and managing
-and delivering secrets. Equating this to the RATS model, the KBS is the
-`relying party` entity. The KBS, however, doesn’t validate the attestation evidence.
-Instead, it uses the attestation service (AS) to verify the TEE evidence.
+The KBS facilitates remote attestation and manages and delivers secrets. In RATS terms, the KBS is the **Relying party**. The KBS does not validate attestation evidence itself; it relies on the Attestation Service (AS) to verify the TEE evidence.
 
-#### Attestation Service (AS)
+## Attestation Service (AS)
 
-The Attestation Service (AS) is responsible for validating the TEE evidence.
-When mapped to the RATS model, the AS is the equivalent of the `verifier`.
-The AS receives attestation evidence and returns an attestation token
-containing the results of a two-step verification process.
+The Attestation Service (AS) validates TEE evidence. In RATS terms, the AS is the **Verifier**. The AS receives attestation evidence and returns an attestation token containing the results of a two-step verification process.
 
 The following diagram shows the AS components:
 
-![attestation-services](attestation-services.png "Attestation Service components")
-
-The AS runs the following verification process:
+![Attestation Service components alt-text#center](attestation-services.png "Attestation Service components")
 
-1. Verify the formatting and the origin of the evidence - for example, checking the signature of the evidence.
-   This is accomplished by one of the platform-specific Verifier Drivers.
-2. Evaluate the claims provided in the evidence - for example, validating that the measurements are what the
-   client expects. This is done by a Policy Engine with help from the RVPS.
+The AS performs this verification flow:
 
-##### Verifier driver
+- **Verify format and origin of evidence** – for example, verify the evidence signature. This is handled by a platform-specific Verifier driver.
+- **Evaluate claims** – for example, validate that measurements match expected values. This is handled by the Policy engine, with RVPS support.
 
-A verifier driver parses the attestation evidence provided by the hardware TEE. It performs the following tasks:
+## Verifier driver
 
-1. Verifies the hardware TEE signature of the TEE quote and report provided in the evidence
-2. Receives the evidence and organizes the status into a JSON format to be returned
+A Verifier driver parses the attestation evidence provided by the hardware TEE and:
 
-In this Learning Path, the AS is configured to use an external CCA verifier.
+- Verifies the hardware TEE signature of the quote and report included in the evidence.
+- Normalizes the verified evidence into a JSON structure to be returned.
 
-[Linaro](https://www.linaro.org) provides such an attestation verifier for use with pre-silicon Arm CCA platforms.
-This verifier is built from the Open-Source [Veraison project](https://github.com/veraison).
-You can learn more about Veraison and Linaro attestation verifier service in
-[Get Started with CCA Attestation and Veraison](https://learn.arm.com/learning-paths/servers-and-cloud-computing/cca-veraison/)
+In this Learning Path, the AS is configured to use an external CCA Verifier.
 
-##### Policy Engine
+[Linaro](https://www.linaro.org) provides an attestation Verifier for pre-silicon Arm CCA platforms. It is built from the open-source [Veraison](https://github.com/veraison) project. Learn more in
+[Get Started with CCA Attestation and Veraison](https://learn.arm.com/learning-paths/servers-and-cloud-computing/cca-veraison/).
 
-The AS allows users to upload their own policies when performing evidence verification.
-When an attestation request is received by the AS, it uses a policy ID in the request
-to decide which policies should be evaluated.
-The results of all policies evaluated are included in the attestation response.
+## Policy engine
 
-In this Learning Path the AS attestation policy includes specific Arm CCA rules.
+The AS lets you upload custom policies used during evidence verification. When the AS receives an attestation request, it uses the policy ID in the request to decide which policies to evaluate. The attestation response includes the results of all evaluated policies.
 
-#### Reference Value Provider Service (RVPS)
+In this Learning Path, the AS policy includes Arm CCA–specific rules.
 
-The reference value provider service (RVPS) is a component in the AS responsible for verifying,
-storing, and providing reference values. RVPS receives and verifies inputs from the software
-supply chain, stores the measurement values, and generates reference value claims for the AS.
-This operation is performed based on the evidence verified by the AS.
+## Reference Value Provider Service (RVPS)
 
+RVPS verifies, stores, and provides reference values. It receives inputs from the software supply chain, stores measurement values, and generates reference value claims for the AS, based on evidence verified by the AS.
 
-### Guest components
+## Guest components
 
-The guest components are the services/tools that run inside the realm (TEE).
-When mapped to the RATS model, these components are the equivalent of the `Attester`.
+Guest components run inside the realm (TEE). In RATS terms, these components act as the **Attester**.
 
-For simplicity instead of Attestation Agent (AA) and Confidential Data Hub (CDH)
-you will use [KBS Client Tool](https://github.com/confidential-containers/trustee/tree/main/tools/kbs-client)
+For simplicity, instead of Attestation Agent (AA) and Confidential Data Hub (CDH), you will use the [KBS Client Tool](https://github.com/confidential-containers/trustee/tree/main/tools/kbs-client).
 
 This is a simple client for the KBS that facilitates basic attestation flows.
-You will run this tool inside of a realm to make requests for an attestation result token (EAR) and a secret.
+You will run this tool in a realm to make requests for an attestation result token (EAR) and a secret.
 
 The client tool can also be used to provision the KBS/AS with resources and policies.
 
-KBS Client connects to the KBS in order to perform attestation. To prove the trustworthiness of the environment
-KBS Client sends the evidence (claims) from the TEE in the form of a CCA attestation token.
-You can learn more about CCA attestation tokens in
-[Get Started with CCA Attestation and Veraison](https://learn.arm.com/learning-paths/servers-and-cloud-computing/cca-veraison/)
+To prove the environment’s trustworthiness, the KBS Client sends CCA attestation evidence (a CCA attestation token) to the KBS. Learn more about CCA attestation tokens in
+[Get Started with CCA Attestation and Veraison](https://learn.arm.com/learning-paths/servers-and-cloud-computing/cca-veraison/).
+
+For convenience, Trustee services and the client software are packaged in Docker containers, which you can run on any suitable AArch64 or x86_64 development host. Because the client runs in a realm, it uses the Fixed Virtual Platform (FVP) and the reference software stack for Arm CCA. If you are new to running applications in realms with FVP, see
+[Run an application in a Realm using the Arm Confidential Computing Architecture (CCA)](/learning-paths/servers-and-cloud-computing/cca-container).
 
-For convenience, Trustee services and the client software are packaged in
-docker containers, which you can execute on any suitable AArch64 or x86_64
-development machine. Since the client software runs in a realm, it makes use
-of the Fixed Virtual Platform (FVP) and the reference software stack for Arm CCA.
-If you have not yet familiarized yourself with running applications in realms using
-FVP and the reference software stack, see the
-[Run an application in a Realm using the Arm Confidential Computing Architecture (CCA)](/learning-paths/servers-and-cloud-computing/cca-container)
-Learning Path.
+When the AS receives an attestation token from the realm using the KBS, it:
 
-When the AS receives an attestation token from the realm via KBS:
-- it calls an external CCA verifier (the Linaro attestation verifier service) to obtain an attestation result.
-- the external CCA verifier checks the token's cryptographic signature,
-  verifies that it denotes a confidential computing platform and provides an attestation result.
-- it also checks the token evidences against its own attestation policies and updates attestation result status and trustworthiness vectors.
+- Calls an external CCA Verifier (the Linaro attestation Verifier service) to obtain an attestation result.
+- Checks the token’s cryptographic signature and confirms that it represents a confidential computing platform.
+- Evaluates evidence in the token against its policies and updates the attestation result and trustworthiness vectors.
 
-When asked for a resource the KBS uses the attestation result to decide whether to release the secrets into the realm for processing.
+When a resource is requested, the KBS uses the attestation result to decide whether to release secrets to the realm for processing.
 
-Figure 1 demonstrates the software architecture that you will construct to run the attestation example.
+This diagram shows the software architecture you will construct to run the attestation example:
 
-![cca-trustee](trustee.png "Figure 1: Software architecture for running attestation.")
+![Software architecture for running attestation alt-text#center](trustee.png "Software architecture for running attestation")
 
-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.
+Proceed to the next section to run the end-to-end attestation example using the components and architecture described here.
diff --git a/content/learning-paths/servers-and-cloud-computing/cca-trustee/flow.md b/content/learning-paths/servers-and-cloud-computing/cca-trustee/flow.md
