The Trust Problem
If the enclave is a black box that nobody can inspect, how does AWS Key Management Service (KMS) know it's safe to hand over a decryption key? You need a way to prove — cryptographically, not just by policy — that the code running inside the enclave is exactly the code you approved, and not something an attacker has tampered with.
This is solved by cryptographic attestation, a process where the enclave proves its own identity by presenting a signed document describing exactly what it is.
How Attestation Works
Step 1 — Measurement at boot time.
When the enclave boots, the Nitro Hypervisor measures the Enclave Image File (EIF) — the binary that contains your application. "Measuring" means computing a series of cryptographic hashes (SHA-384) over the image contents, the kernel, the boot ramdisk, and the application. These hashes are called Platform Configuration Registers (PCRs), borrowed from the Trusted Platform Module (TPM) concept. PCR0 covers the entire image; PCR1 covers the kernel; PCR2 covers the application. The values are deterministic: the same image always produces the same PCR values.
Step 2 — The attestation document.
The enclave calls the Nitro Hypervisor's local attestation API and requests a signed document. The hypervisor produces an attestation document containing:
- The PCR values (the image fingerprints)
- The EC2 instance ID and region
- The IAM role attached to the parent instance
- A timestamp
- A public key generated inside the enclave (for optional end-to-end encryption)
This document is signed by the AWS Nitro Attestation PKI — a certificate chain rooted in AWS's hardware root of trust. The enclave cannot forge this document; only the hypervisor can produce it.
Step 3 — KMS key policy enforcement.
You configure your KMS key with a condition that checks the PCR values in the attestation document:
{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::123456789012:role/my-enclave-role" },
"Action": "kms:Decrypt",
"Resource": "*",
"Condition": {
"StringEqualsIgnoreCase": {
"kms:RecipientAttestation:PCR0": "a1b2c3d4e5f6..."
}
}
}
Step 4 — The result.
When the enclave calls KMS to decrypt a data key, it includes the attestation document in the request. KMS verifies the AWS signature on the document, extracts the PCR values, and checks them against the key policy. If they match, KMS releases the key — directly to the enclave, encrypted with the enclave's public key so the parent cannot intercept it. If an attacker modifies even a single byte of your enclave image, PCR0 changes, the policy check fails, and KMS refuses.
Interviewers often ask: "How is Nitro Enclave attestation different from just using IAM roles?" The key distinction is that IAM roles prove who is making the request (the EC2 instance identity), but attestation proves what code is running. An attacker who compromises the parent EC2 instance inherits its IAM role — but they cannot forge the PCR values in the attestation document because those are signed by the Nitro Hypervisor's hardware root of trust. Attestation is code-identity; IAM is instance-identity.