A few notes on AWS Nitro Enclaves: KMS integration

What it is

The third post in Trail of Bits' Nitro Enclaves series, focused specifically on the enclave↔KMS communication channel. It catalogs the two security mechanisms KMS offers enclaves, the operational risks that survive correct cryptography, and a developer-side checklist for defeating passive attacks.

How it works

Two mechanisms are in play, and both hang on attestation:

• PCR-restricted key policies — a CMK key policy can authorize only requests carrying a fresh, correctly signed attestation document with expected PCR values. Restricting by PCRs 0–2 limits access to a specific enclave version; PCR8 (the EIF signing certificate) restricts access to enclaves built by the same developer, with developer identity protected inside KMS. The enclave still needs ordinary IAM credentials to reach KMS at all.
• Response encryption to the enclave's public key — the enclave ships an asymmetric public key inside the attestation document (via the Recipient parameter), and KMS encrypts sensitive response fields to it, so only the requesting enclave sees the output.

Only GenerateDataKey, GenerateDataKeyPair, Decrypt, DeriveSharedSecret, and GenerateRandom support these protections. Encrypt does not — enclaves can call it, but with no attestation checks. The intended pattern is therefore envelope encryption via data keys, never direct CMK use: KMS hands back a plaintext data key plus that key encrypted to the CMK; the app encrypts locally, drops the plaintext, and stores the wrapped key alongside ciphertext.

What to do

The page's passive-attack checklist (attacker controls all inputs and any data at rest outside the enclave):

• Every KMS request carries the Recipient parameter.
• Encryption context is used on supported operations, is chosen by the enclave, and is not fully attacker-controlled.
• Encrypt and GenerateDataKey are authorized properly.
• Data encrypted with data keys has context; key commitment is considered.
• The correct CMK is used: hardcode the CMK ARN, and check keyId in the response rather than trusting the identifier round-trip.

Caveats

• KMS's attestation verification does not by itself prevent misuse — these mitigations are the developer's responsibility.
• The checklist addresses passive attackers only; the post separately notes active attackers can modify all traffic in and out of the enclave (that discussion is cut off in the fetched text).
• On using GenerateRandom for extra entropy, the authors are explicitly non-committal: enclaves already get high-quality entropy from the hypervisor, and the added complexity may not be worth it.
• The passive-attack landscape depends on specific system design; the checklist is a floor, not a proof of correctness.