Disclaimer: In case of inaccuracies, please open an issue on Github.
In the realm of cloud computing, the assurance of data security and application integrity is of utmost importance. AWS Nitro Enclaves provide a robust mechanism by creating isolated computing environments specifically designed to safeguard and process highly sensitive information. A pivotal aspect of this security framework is the cryptographic attestation process, which enables external entities to verify the authenticity and integrity of the code and data executing within an enclave.
This article provides a detailed examination of the cryptographic attestation process in AWS Nitro Enclaves, elucidating its operational mechanics, its critical importance, and the methods by which third parties can utilize it to establish trust with enclaves. Additionally, we will analyze the relevant fields for third parties—such as Platform Configuration Registers (PCRs)—and their role in verifying the execution of the correct Docker image within the enclave.
Before diving into attestation, it’s essential to understand the lifecycle of a Nitro Enclave. The process involves several steps, from writing your application code to running the enclave and performing attestation. The developer starts by writing the code for the application you intend to run inside the enclave. This code is designed to handle sensitive data and perform secure computations. The application code is containerized using Docker. This image includes all dependencies and configurations necessary for the application to run. Using the Nitro CLI, the Docker image is converted into an Enclave Image File (EIF). This process includes incorporating precompiled binaries like the kernel and Nitro Secure Module (NSM) driver. The EIF is used to start the enclave via the Nitro Hypervisor. The hypervisor ensures that the enclave runs in an isolated environment with dedicated resources. Once the enclave is running, an attestation document can be requested. This document includes cryptographic measurements and metadata that can be used to verify the integrity and identity of the enclave. External services or verifiers use the attestation document to confirm that the enclave is genuine and running the expected code. This step establishes trust between the enclave and external parties.
+-------------------------+
| Application Code |
| (Written by Developer) |
+------------+------------+
|
1. Compile and Build Code
|
v
+-------------------------+
| Docker Image |
| (Containerized App) |
+------------+------------+
|
2. Build Enclave Image (EIF)
|
v
+----------------------+----------------------+
| Nitro CLI + Precompiled Binaries (Kernel, |
| NSM driver, init) + Docker Image |
+------------+------------+-------------------+
|
3. Generate Enclave Image
(Create EIF Format)
|
v
+-------------------------+
| Enclave Image |
| (EIF File) |
+------------+------------+
|
4. Start Enclave via Nitro Hypervisor
|
v
+-------------------------+
| Nitro Enclave |
| (Running Enclave Image) |
+------------+------------+
|
5. Attestation Process Begins:
- PCR Measurement
- Attestation Document Signing
|
v
+-------------------------+
| External Service/Verifier|
+-------------------------+
|
6. Verify Signed Attestation
(Check PCR Values, Signature)
|
v
+-------------------------+
| Verified Enclave |
| (Trust Established) |
+-------------------------+
Platform Configuration Registers (PCRs) are at the heart of the attestation process. They are cryptographic hashes representing various components and configurations of the enclave. PCRs Overview
PCR0: Hash of the Enclave Image File (EIF) without the section data.
PCR1: Hash of the Linux kernel and bootstrap components.
PCR2: Hash of the application (user code) within the enclave.
PCR3: Hash of the IAM role assigned to the parent EC2 instance.
PCR4: Hash of the instance ID of the parent EC2 instance.
PCR8: Hash of the signing certificate used for the EIF.
To confirm that the enclave is running the correct Docker image (i.e., your application code), a verifying party needs to focus on PCR0, PCR1, and PCR2. The PCR Values are obtained whe building the EIF image using the Nitro CLI, it outputs the PCR measurements.
{
"Measurements": {
"HashAlgorithm": "Sha384 { ... }",
"PCR0": "7fb5c55bc2ecbb68ed99a13d7122abfc0666b926a79d5379bc58b9445c84217f5...",
"PCR1": "235c9e6050abf6b993c915505f3220e2d82b51aff830ad14cbecc2eec1bf0b4a...",
"PCR2": "0f0ac32c300289e872e6ac4d19b0b5ac4a9b020c98295643ff3978610750ce6a..."
}
}
When verifying the attestation document, extract PCR0, PCR1, and PCR2 and compare them to the expected values obtained during the EIF build process. If the PCR values match, you can be confident that the enclave is running the exact Docker image and code you expect.
By signing your EIF with a private key and including the signing certificate, you can use PCR8 to verify that the EIF hasn’t been altered. Developers can use OpenSSL to create a private key and a self-signed certificate. When building the EIF, include the –private-key and –signing-certificate options. Lastly, one should compare the PCR8 value in the attestation document to the expected value from the signed EIF build output.
These are specific PCRs that are correlated to IAM roles in AWS.
PCR3 (IAM Role): By including the hash of the IAM role in PCR3, you ensure that only enclaves running on instances with a specific IAM role can be verified.
PCR4 (Instance ID): Including the hash of the instance ID in PCR4 ties the enclave to a specific EC2 instance.
We previousluy described that one should obtain the attestation document to verify the EIF values initially obtained in the build.
The attestation document ensures:
By validating the attestation document, external services can:
TODO
There are several libraries for obtaining an attestation document in different languages, such as Golang and Rust.
TODO
The transmission of sensitive data to isolated environments such as AWS Nitro Enclaves necessitates robust encryption and authentication mechanisms. Transport Layer Security (TLS) emerges as a cornerstone technology in this domain, offering a suite of cryptographic protocols designed to secure data in transit. Leveraging TLS effectively ensures that payloads intended for enclaves remain confidential and are accessible solely to the authenticated enclave, thereby maintaining the integrity and privacy of the data.
TLS provides end-to-end encryption between two communicating parties, ensuring that any data exchanged is unreadable to potential eavesdroppers. When transmitting payloads to an enclave, TLS serves two primary functions:
Confidentiality: By encrypting the data, TLS ensures that the payload cannot be deciphered by unauthorized entities during transit. This is crucial when dealing with sensitive information that must remain protected against interception.
Integrity and Authenticity: TLS employs cryptographic hashes and digital signatures to verify that the data has not been tampered with and that it originates from a legitimate source. This dual assurance is vital for establishing trust between the payload sender and the enclave.
A critical aspect of using TLS with enclaves is the authentication of the enclave itself. Enclave attestation provides cryptographic proof of the enclave’s identity and its operational integrity. Integrating attestation with TLS involves the following:
Certificate Issuance: Upon successful attestation, the enclave can be issued a certificate by a trusted authority. This certificate includes the enclave’s public key and attestation evidence, linking the certificate to the enclave’s verified state.
Certificate Verification: During the TLS handshake, the enclave presents its certificate to the client. The client verifies this certificate against known trust anchors, ensuring that it corresponds to a genuine and attested enclave.
Secure Key Exchange: With the enclave authenticated, the client can securely exchange session keys, confident that the keys are being shared with the legitimate enclave.
Once the TLS-secured channel is established, the enclave can decrypt the incoming payload using its private key. The enclave’s isolated execution environment ensures that decrypted data remains protected from unauthorized access, even if the host system is compromised. The principles underpinning this process are as follows: