From c3e03260f0aeb868bfa52f1cd276d9479fae5c30 Mon Sep 17 00:00:00 2001 From: Maddy Underwood <167196745+madeline-underwood@users.noreply.github.com> Date: Wed, 18 Dec 2024 15:56:42 +0000 Subject: [PATCH 01/12] Editorial improvements. --- .../cca-essentials/_index.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md b/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md index 08affd0cb..522008607 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md @@ -3,19 +3,19 @@ title: Run an Attestation with Arm Confidential Compute Architecture (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 see how you can use attestation 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 Armv-A AEM Base Fixed Virtual Platform (FVP) with 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 From 9a987588d557303d1a5b5d4c89a60883e1a07294 Mon Sep 17 00:00:00 2001 From: Maddy Underwood <167196745+madeline-underwood@users.noreply.github.com> Date: Wed, 18 Dec 2024 16:12:16 +0000 Subject: [PATCH 02/12] Fixed typo. --- .../cca-essentials/cca-essentials.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/content/learning-paths/servers-and-cloud-computing/cca-essentials/cca-essentials.md b/content/learning-paths/servers-and-cloud-computing/cca-essentials/cca-essentials.md index 5674feed7..870d5e95d 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-essentials/cca-essentials.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-essentials/cca-essentials.md @@ -9,26 +9,26 @@ 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. +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 particular Learning Path, the target compute environment is the 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 pattern in confidential computing. Here, you will learn about this pattern 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 role of the KBS is to be a repository for encryption keys or other confidential data resources. A KBS releases such secrets for processing in a confidential computing environment, but only when that environment has proved itself trustworthy through attestation. 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). -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. +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 [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. -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. +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 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. -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. +In this Learning Path example, 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. -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. +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, for further information, 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. -The attestation verification service is hosted by Linaro, so it will not be necessary for you to build or deploy this service yourself. +The attestation verification service is hosted by Linaro, so it is not necessary for you to build or deploy this service yourself. -Shown in this figure below is the software architecture you will construct to run the attestation example in this learning path. +Shown in this figure below is the software architecture you will construct to run the attestation example. ![cca-essentials](cca-essentials.png) From 411bb5cce652785d45cfbef024522970310d0147 Mon Sep 17 00:00:00 2001 From: Maddy Underwood <167196745+madeline-underwood@users.noreply.github.com> Date: Wed, 18 Dec 2024 16:23:41 +0000 Subject: [PATCH 03/12] Tweak --- .../cca-essentials/cca-essentials.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/learning-paths/servers-and-cloud-computing/cca-essentials/cca-essentials.md b/content/learning-paths/servers-and-cloud-computing/cca-essentials/cca-essentials.md index 870d5e95d..498aa7f6f 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-essentials/cca-essentials.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-essentials/cca-essentials.md @@ -11,7 +11,7 @@ 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 is to assess whether the target compute environment offers a provable level of confidential isolation. In this particular Learning Path, the target compute environment is the 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 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 particular Learning Path, the target compute environment is the 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 releases such secrets for processing in a confidential computing environment, but only when that environment has proved itself trustworthy through attestation. From dd65828afa69b6f69e576bed0269efde5fd94a72 Mon Sep 17 00:00:00 2001 From: Maddy Underwood <167196745+madeline-underwood@users.noreply.github.com> Date: Wed, 18 Dec 2024 17:05:12 +0000 Subject: [PATCH 04/12] Corrected Arm Architecture reference. --- .../servers-and-cloud-computing/cca-essentials/_index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md b/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md index 522008607..e33c5c1a5 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md @@ -3,11 +3,11 @@ title: Run an Attestation with Arm Confidential Compute Architecture (CCA) minutes_to_complete: 120 -who_is_this_for: This is an advanced topic for software developers who want to see how you can use attestation 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 use attestation with Arm's Confidential Computing Architecture (CCA). learning_objectives: - Describe how you can use attestation with Arm's Confidential Computing Architecture (CCA). - - Deploy a simple workload in a CCA realm on an Armv-A AEM Base Fixed Virtual Platform (FVP) with support for RME extensions. + - Deploy a simple workload in a CCA realm on an Armv9-A AEM Base Fixed Virtual Platform (FVP) with 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: From f5b8c9f1e65ef30f4e3ebe744c1a54b57e87694f Mon Sep 17 00:00:00 2001 From: Maddy Underwood <167196745+madeline-underwood@users.noreply.github.com> Date: Wed, 18 Dec 2024 17:06:24 +0000 Subject: [PATCH 05/12] Update _index.md --- .../servers-and-cloud-computing/cca-essentials/_index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md b/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md index e33c5c1a5..0c61b2c34 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md @@ -12,8 +12,8 @@ learning_objectives: prerequisites: - 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. + - 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 From 6e7af2bacd664ae19196571817612cdd43e09045 Mon Sep 17 00:00:00 2001 From: Maddy Underwood <167196745+madeline-underwood@users.noreply.github.com> Date: Wed, 18 Dec 2024 17:08:05 +0000 Subject: [PATCH 06/12] Editorial tweaks. --- .../servers-and-cloud-computing/cca-essentials/_next-steps.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/learning-paths/servers-and-cloud-computing/cca-essentials/_next-steps.md b/content/learning-paths/servers-and-cloud-computing/cca-essentials/_next-steps.md index d45c26908..fbb658a21 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-essentials/_next-steps.md +++ b/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. From 2bae860349dfa607e2c926d73df2e2f4e193c162 Mon Sep 17 00:00:00 2001 From: Maddy Underwood Date: Thu, 19 Dec 2024 06:34:12 +0000 Subject: [PATCH 07/12] Improved langauge and structure. --- .../cca-essentials/example.md | 62 ++++++++++++++----- 1 file changed, 45 insertions(+), 17 deletions(-) diff --git a/content/learning-paths/servers-and-cloud-computing/cca-essentials/example.md b/content/learning-paths/servers-and-cloud-computing/cca-essentials/example.md index 377f58921..c0f9c41c1 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-essentials/example.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-essentials/example.md @@ -10,9 +10,15 @@ layout: "learningpathall" ## Run the Key Broker Server -The concept of a KBS is a common one in confidential computing, and there are multiple open-source implementations, including the [Trustee](https://github.com/confidential-containers/trustee) from the [CNCF Confidential Containers](https://confidentialcontainers.org/) project. The KBS in this learning path is part of the [Veraison](https://github.com/veraison) project. It has been created specifically for educational purposes and not designed for production use. Its aim is to be small and simple to understand. +#### Background -First, pull the docker container image with the pre-built KBS and then run the container: +The concept of a Key Broker Server (KBS) is a common one in confidential computing, and there are multiple open-source implementations, including the [Trustee](https://github.com/confidential-containers/trustee) from the [CNCF Confidential Containers](https://confidentialcontainers.org/) project. + +The KBS in this Learning Path is part of the [Veraison](https://github.com/veraison) project. It has been created specifically for educational purposes, so is intentionally small and simple to understand, and is not designed for production use. + +#### Get started + +First, pull the docker container image with the pre-built KBS, and then run the container: ```bash docker pull armswdev/cca-learning-path:cca-key-broker-v1 @@ -39,7 +45,7 @@ The output should look like: inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0 valid_lft forever preferred_lft forever ``` -Start the key broker server on the `eth0` network interface: +Start the KBS on the `eth0` network interface: ```bash ./keybroker-server -v --addr 172.17.0.2 @@ -53,29 +59,33 @@ INFO Actix runtime found; starting in Actix runtime INFO starting service: "actix-web-service-172.17.0.2:8088", workers: 16, listening on: 172.17.0.2:8088 ``` -With the key broker server running in one terminal, open up a new terminal in which you will run the key broker client. +With the key broker server running in one terminal, open up a new terminal in which you will run the key broker client in the next step. ## Run the Key Broker Client -In a new terminal, pull the docker container image which contains the FVP and pre-built software binaries to run the key broker client in a realm. +In the new terminal that you have just opened, pull the docker container image that contains the FVP and pre-built software binaries to run the key broker client in a realm. ```bash docker pull armswdev/cca-learning-path:cca-simulation-v1 ``` -Now run this docker container: +Now run the docker container: ```bash docker run --rm -it armswdev/cca-learning-path:cca-simulation-v1 ``` -Within you running container, launch the `run-cca-fvp.sh` script to run the Arm CCA pre-built binaries on the FVP: +Within your running container, launch the `run-cca-fvp.sh` script to run the Arm CCA pre-built binaries on the FVP: ```bash ./run-cca-fvp.sh ``` The run-cca-fvp.sh script uses the screen command to connect to the different UARTs in the FVP. -You should see the host Linux kernel boot on your terminal. You will be prompted to log in to the host. Enter root as the username: +You should see the host Linux kernel boot on your terminal. + +You will be prompted to log in to the host. + +Enter root as the username: ```output [ 4.169458] Run /sbin/init as init process @@ -101,7 +111,11 @@ Use kvmtool to launch guest Linux in a Realm: cd /cca ./lkvm run --realm --disable-sve --irqchip=gicv3-its --firmware KVMTOOL_EFI.fd -c 1 -m 512 --no-pvtime --force-pci --disk guest-disk.img --measurement-algo=sha256 --restricted_mem ``` -You should see the realm boot. After boot up, you will be prompted to log in at the guest Linux prompt. Use root again as the username: +You should see the realm boot. + +After boot up, you will be prompted to log in at the guest Linux prompt. + +Use root again as the username: ```output Starting syslogd: OK @@ -120,21 +134,28 @@ realm login: root (realm) # ``` -Now run the key broker client application in the realm. Use the endpoint address that the key broker server is listening on in the other terminal: +Now run the key broker client application in the realm. + +Use the endpoint address that the key broker server is listening in on the other terminal: + ```bash cd /cca ./keybroker-app -v --endpoint http://172.17.0.2:8088 skywalker ``` -In the command above `skywalker` is the key name that is requested from the key broker server. After some time, you should see the following output: +In the command above, `skywalker` is the key name that is requested from the key broker server. + +After some time, you should see the following output: ``` INFO Requesting key named 'skywalker' from the keybroker server with URL http://172.17.0.2:8088/keys/v1/key/skywalker INFO Challenge (64 bytes) = [0f, ea, c4, e2, 24, 4e, fa, dc, 1d, ea, ea, 3d, 60, eb, a6, 8f, f1, ed, 1a, 07, 35, cb, 5b, 1b, cf, 5b, 21, a4, bc, 14, 65, c2, 21, 3f, bf, 33, a0, b0, 7c, 78, 3a, a6, 32, c6, 34, be, ff, 45, 98, f4, 17, b1, 24, 71, 4f, 9c, 75, 58, 37, 3a, 28, ea, 97, 33] INFO Submitting evidence to URL http://172.17.0.2:8088/keys/v1/evidence/3974368321 INFO Attestation failure :-( ! AttestationFailure: No attestation result was obtained. No known-good reference values. ``` -You can see from the key broker client application output that the `skywalker` key is requested from the key broker server, which did send a challenge. The key broker client application uses the challenge to submit its evidence back to the key broker server, but it gets an attestation failure. This is because the server does not have any known good reference values. +You can see from the key broker client application output that the `skywalker` key is requested from the key broker server, which did send a challenge. -Now look at the key broker server output on the terminal where the server is running. It will look like: +The key broker client application uses the challenge to submit its evidence back to the key broker server, but it receives an attestation failure. This is because the server does not have any known good reference values. + +Now look at the key broker server output on the terminal where the server is running. It will look like this: ```output INFO Known-good RIM values are missing. If you trust the client that submitted @@ -143,16 +164,23 @@ command-line option to populate it with known-good RIM values: --reference-values <(echo '{ "reference-values": [ "tiA66VOokO071FfsCHr7es02vUbtVH5FpLLqTzT7jps=" ] }') INFO Evidence submitted for challenge 1302147796: no attestation result was obtained. No known-good reference values. ``` -From the server output you will notice that it did create the challenge for the key broker application, but it complains that it has no known good reference values. It does however provide a way to provision the key broker server with known good values if the client is trusted. -In a production environment, the known good reference value would be generated using a deployment specific process, but for demonstration purposes and simplification, you will use the value proposed by the key broker server. +From the server output, you can see that it did create the challenge for the key broker application, but it reports that it has no known good reference values. + +It does however provide a way to provision the key broker server with known good values if the client is trusted. + +In a production environment, the known good reference value is generated using a deployment- specific process, but for demonstration purposes and simplification, you will use the value proposed by the key broker server. + +Now go ahead and terminate the running instance of the key broker server using Ctrl+C and restart it with the known good reference value. + +Notice here that you need to copy the `--reference-values` argument directly from the previous error message reported by the key broker. -Now go ahead and terminate the running instance of the key broker server(ctrl+C) and restart it with the known good reference value. Notice here that you need to copy the `--reference-values` argument directly from the previous error message reported by the key broker. When running this next command, ensure that you are using exactly that value, for example:: +When running this next command, ensure that you are using exactly that value, for example:: ```bash ./keybroker-server -v --addr 172.17.0.2 --reference-values <(echo '{ "reference-values": [ "tiA66VOokO071FfsCHr7es02vUbtVH5FpLLqTzT7jps=" ] }') ``` -On the terminal with the running realm, re-run the key broker client application with the exact same command line parameters as before: +On the terminal with the running realm, rerun the key broker client application with the exact same command line parameters as before: ```bash ./keybroker-app -v --endpoint http://172.17.0.2:8088 skywalker From eb18eaf2318d7fd44c19a85ac0b052dd82376980 Mon Sep 17 00:00:00 2001 From: Maddy Underwood Date: Thu, 19 Dec 2024 10:50:14 +0000 Subject: [PATCH 08/12] Further improvements to language. Added tite to image. --- .../cca-essentials/_index.md | 4 ++-- .../cca-essentials/cca-essentials.md | 24 ++++++++++--------- .../cca-essentials/example.md | 4 ++-- 3 files changed, 17 insertions(+), 15 deletions(-) diff --git a/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md b/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md index 0c61b2c34..d7150c980 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md @@ -1,9 +1,9 @@ --- -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 learn how to use attestation 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: - Describe how you can use attestation with Arm's Confidential Computing Architecture (CCA). diff --git a/content/learning-paths/servers-and-cloud-computing/cca-essentials/cca-essentials.md b/content/learning-paths/servers-and-cloud-computing/cca-essentials/cca-essentials.md index 498aa7f6f..92dc99af5 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-essentials/cca-essentials.md +++ b/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 +## 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 offers a provable level of confidential isolation. In this particular Learning Path, the target compute environment is the 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. +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 releases 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 checks the token's cryptographic signature and verifies 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 uses 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 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. +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, for further information, 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. +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. + +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. The attestation verification service is hosted by Linaro, so it is not necessary for you to build or deploy this service yourself. -Shown in this figure below is the software architecture you will construct to run the attestation example. +Figure 1 demonstrates the software architecture that you will construct to run the attestation example. -![cca-essentials](cca-essentials.png) +![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. +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. diff --git a/content/learning-paths/servers-and-cloud-computing/cca-essentials/example.md b/content/learning-paths/servers-and-cloud-computing/cca-essentials/example.md index c0f9c41c1..85897f66a 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-essentials/example.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-essentials/example.md @@ -174,7 +174,7 @@ Now go ahead and terminate the running instance of the key broker server using C Notice here that you need to copy the `--reference-values` argument directly from the previous error message reported by the key broker. -When running this next command, ensure that you are using exactly that value, for example:: +When running this next command, ensure that you are using exactly that value, for example: ```bash ./keybroker-server -v --addr 172.17.0.2 --reference-values <(echo '{ "reference-values": [ "tiA66VOokO071FfsCHr7es02vUbtVH5FpLLqTzT7jps=" ] }') @@ -186,7 +186,7 @@ On the terminal with the running realm, rerun the key broker client application ./keybroker-app -v --endpoint http://172.17.0.2:8088 skywalker ``` -You should now get a successful attestion as shown: +You should now get a successful attestation as shown: ```output INFO Requesting key named 'skywalker' from the keybroker server with URL http://172.17.0.2:8088/keys/v1/key/skywalker From 0a8da62d649b5a3ee402646c41db61d61d9fb4f7 Mon Sep 17 00:00:00 2001 From: Maddy Underwood Date: Thu, 19 Dec 2024 11:15:27 +0000 Subject: [PATCH 09/12] Clarifying language. --- .../servers-and-cloud-computing/cca-essentials/example.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/learning-paths/servers-and-cloud-computing/cca-essentials/example.md b/content/learning-paths/servers-and-cloud-computing/cca-essentials/example.md index 85897f66a..b19ad7c4f 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-essentials/example.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-essentials/example.md @@ -174,7 +174,7 @@ Now go ahead and terminate the running instance of the key broker server using C Notice here that you need to copy the `--reference-values` argument directly from the previous error message reported by the key broker. -When running this next command, ensure that you are using exactly that value, for example: +When running the next command, ensure that you are copying the exact value reported, for example: ```bash ./keybroker-server -v --addr 172.17.0.2 --reference-values <(echo '{ "reference-values": [ "tiA66VOokO071FfsCHr7es02vUbtVH5FpLLqTzT7jps=" ] }') From 2319f015856416fa370a450ffef12f7712072817 Mon Sep 17 00:00:00 2001 From: Maddy Underwood <167196745+madeline-underwood@users.noreply.github.com> Date: Thu, 19 Dec 2024 12:08:31 +0000 Subject: [PATCH 10/12] Final tweak. --- .../servers-and-cloud-computing/cca-essentials/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md b/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md index d7150c980..6c253cd82 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md @@ -7,7 +7,7 @@ who_is_this_for: This is an advanced topic for software developers who want to l learning_objectives: - 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) with support for RME extensions. + - 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: From 906f7ab7130c6d291f2f77d79184689a9d17f24d Mon Sep 17 00:00:00 2001 From: Maddy Underwood Date: Fri, 20 Dec 2024 16:52:29 +0000 Subject: [PATCH 11/12] Corrected detail after Andy's review. --- .../servers-and-cloud-computing/cca-essentials/example.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/learning-paths/servers-and-cloud-computing/cca-essentials/example.md b/content/learning-paths/servers-and-cloud-computing/cca-essentials/example.md index b19ad7c4f..fa712eb9d 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-essentials/example.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-essentials/example.md @@ -45,7 +45,7 @@ The output should look like: inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0 valid_lft forever preferred_lft forever ``` -Start the KBS on the `eth0` network interface: +Start the KBS on the `eth0` network interface, and replace 172.17.0.2 shown in the example below with the IP address corresponding to eth0 in the output of "ip -c a" above. ```bash ./keybroker-server -v --addr 172.17.0.2 From c836efaf544ae9e5ccef71ce26687e306e4fa0c1 Mon Sep 17 00:00:00 2001 From: Maddy Underwood Date: Fri, 20 Dec 2024 16:55:05 +0000 Subject: [PATCH 12/12] Final tweak. --- .../servers-and-cloud-computing/cca-essentials/example.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/learning-paths/servers-and-cloud-computing/cca-essentials/example.md b/content/learning-paths/servers-and-cloud-computing/cca-essentials/example.md index fa712eb9d..6424081f4 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-essentials/example.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-essentials/example.md @@ -45,7 +45,7 @@ The output should look like: inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0 valid_lft forever preferred_lft forever ``` -Start the KBS on the `eth0` network interface, and replace 172.17.0.2 shown in the example below with the IP address corresponding to eth0 in the output of "ip -c a" above. +Start the KBS on the `eth0` network interface, and replace 172.17.0.2 shown in the command below with the IP address corresponding to eth0 in the output of "ip -c a" above. ```bash ./keybroker-server -v --addr 172.17.0.2