Merge pull request #1462 from madeline-underwood/CCA

CCA Essentials_AP approved - if image redone.

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

@@ -1,21 +1,21 @@
 ---
-title: Run an Attestation with Arm Confidential Compute Architecture (CCA)
+title: Run an end-to-end Attestation Flow with Arm CCA
 
 minutes_to_complete: 120
 
-who_is_this_for: This is an advanced topic for software developers who want to see a practical example of how attestation is used with Arm's Confidential Computing Architecture (CCA).  
+who_is_this_for: This is an advanced topic for software developers who want to learn how to run an end-to-end attestation flow with Arm's Confidential Computing Architecture (CCA).  
 
 learning_objectives:
-     - Understand how attestation is used with Arm's Confidential Computing Architecture (CCA).
-     - Deploy a simple workload in a CCA realm on an Armv-A AEM Base FVP (Fixed Virtual Platform) with support for RME extensions. 
-     - Connect the workload with additional software services to create an end-to-end example for using attestation to unlock the confidential processing of data.
+     - Describe how you can use attestation with Arm's Confidential Computing Architecture (CCA).
+     - 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 additional software 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. You can use cloud instances, refer to the list of [Arm cloud service providers](/learning-paths/servers-and-cloud-computing/csp/).
-    - Completion of the [Introduction to CCA Attestation with Veraison](/learning-paths/servers-and-cloud-computing/cca-veraison) learning path.
-    - Completion of the [Run an application in a Realm using the Arm Confidential Computing Architecture (CCA)](learning-paths/servers-and-cloud-computing/cca-container/) learning path.
+    - An AArch64 or x86_64 computer running Linux. You can use cloud instances, see this list of [Arm cloud service providers](/learning-paths/servers-and-cloud-computing/csp/).
+    - Completion of the [Introduction to CCA Attestation with Veraison](/learning-paths/servers-and-cloud-computing/cca-veraison) Learning Path.
+    - Completion of the [Run an application in a Realm using the Arm Confidential Computing Architecture (CCA)](learning-paths/servers-and-cloud-computing/cca-container/) Learning Path.
 
-author_primary: Arnaud de Grandmaison, Paul Howard and Pareena Verma
+author_primary: Arnaud de Grandmaison, Paul Howard, and Pareena Verma
 
 ### Tags
 skilllevels: Advanced

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

@@ -4,7 +4,7 @@
 # ================================================================================
 
 next_step_guidance: >
-   You now have an understanding of how attestation is used with Arm's Confidential Computing Architecture (CCA). You can also build the complete Arm CCA software stack yourself and validate your applications on an Arm FVP ahead of silicon availability.
+   You now have an understanding of how you can use attestation with Arm's Confidential Computing Architecture (CCA). You can also build the complete Arm CCA software stack and validate your applications on an Arm FVP ahead of silicon availability.
 
 # 1-3 sentence recommendation outlining how the reader can generally keep learning about these topics, and a specific explanation of why the next step is being recommended.
 

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

@@ -8,28 +8,30 @@ weight: 2 # 1 is first, 2 is second, etc.
 layout: "learningpathall"
 ---
 
-## Overview 
-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 
+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 is to assess whether the target compute environment (the Linux realm, in this case) offers a provable level of confidential isolation. This assessment 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 pattern in confidential computing. Here, you will learn about this pattern using a minimal set of software components.
+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. Here, you will learn about this practice using a minimal set of software components.
 
 ## Understanding the key software components 
-In this learning path, you will make use of a key broker service, or KBS. The role of the KBS is to be a repository for encryption keys or other confidential data resources. A KBS will release such secrets for processing in a confidential computing environment, but only when that environment has proved itself trustworthy through attestation.
+In this Learning Path, you will make use of a Key Broker Service, or KBS. 
 
-The workload that runs inside the realm is a client of the KBS. It calls the KBS to request a secret. The KBS will not return the secret immediately. Instead, it will issue an attestation challenge back to the client. The client must respond with evidence in the form of a [CCA attestation token](/learning-paths/servers-and-cloud-computing/cca-container/cca-container/#obtain-a-cca-attestation-token-from-the-virtual-guest-in-a-realm).
+The role of the KBS is to be a repository for encryption keys or other confidential data resources. A KBS releases secrets for processing in a confidential computing environment, but only when that environment has proved itself trustworthy through attestation.
 
-When the KBS receives an attestation token from the realm, it needs to call a verification service that will check the token's cryptographic signature and verify that it denotes a confidential computing platform. As you saw in the [Introduction to CCA Attestation with Veraison learning path](/learning-paths/servers-and-cloud-computing/cca-veraison), Linaro provides such an attestation verifier for use with pre-silicon CCA platforms. This verifier is built from the open-source [Veraison project](https://github.com/veraison). The KBS calls this verifier to obtain an attestation result. The KBS can then use this result to decide whether to release the secrets into the realm for processing.
+The workload that runs inside the realm is a client of the KBS. It calls the KBS to request a secret, but the KBS does not return the secret immediately. Instead, it issues an attestation challenge back to the client. The client must respond with evidence in the form of a [CCA attestation token](/learning-paths/servers-and-cloud-computing/cca-container/cca-container/#obtain-a-cca-attestation-token-from-the-virtual-guest-in-a-realm).
 
-For additional security, the KBS does not release any secrets in clear text, even after a successful verification of the attestation token. Instead, the realm provides an additional public encryption key to the KBS. This is known as a wrapping key. The KBS will use this public key to encrypt(wrap) the secrets. The client workload inside the realm is then able to use its own private key to unwrap the secrets and use them.
+When the KBS receives an attestation token from the realm, it needs to call a verification service that checks the token's cryptographic signature and verifies that it denotes a confidential computing platform. As you saw in the prerequisite reading [Introduction to CCA Attestation with Veraison Learning Path](/learning-paths/servers-and-cloud-computing/cca-veraison), Linaro provides such an attestation verifier for use with pre-silicon CCA platforms. This verifier is built from the open-source [Veraison project](https://github.com/veraison). The KBS calls this verifier to obtain an attestation result. The KBS then uses this result to decide whether to release the secrets into the realm for processing.
 
-In this learning path example, you will see the secret that is exchanged between the KBS and the realm is a small string value, which the realm will decrypt and echo to its console window once all the attestation steps have succeeded.
+For additional security, the KBS does not release any secrets in clear text, even after a successful verification of the attestation token. Instead, the realm provides an additional public encryption key to the KBS. This is known as a wrapping key. The KBS uses this public key to wrap, which here means encrypt, the secrets. The client workload inside the realm is then able to use its own private key to unwrap the secrets and use them.
 
-For convenience, both the KBS and the client software are packaged in docker containers, which you can execute on any suitable development machine (aarch64 or x86_64). 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 familiarised yourself with running applications in realms using FVP and the reference software stack, please refer to the [Run an application in a Realm using the Arm Confidential Computing Architecture (CCA)](/learning-paths/servers-and-cloud-computing/cca-container) learning path.
+In the example in this Learning Path, you will see that the secret that is exchanged between the KBS and the realm is a small string value, which the realm decrypts and echoes to its console window once all the attestation steps have succeeded.
 
-The attestation verification service is hosted by Linaro, so it will not be necessary for you to build or deploy this service yourself.
+For convenience, both the KBS 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 familiarised 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.
 
-Shown in this figure below is the software architecture you will construct to run the attestation example in this learning path.
+The attestation verification service is hosted by Linaro, so it is not necessary for you to build or deploy this service yourself.
 
-![cca-essentials](cca-essentials.png)
+Figure 1 demonstrates the software architecture that you will construct to run the attestation example.
 
-You can now proceed to the next section to run the end-to-end attestation example with the software components and architecture as described.
+![cca-essentials](cca-essentials.png "Figure 1: 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.