Lesson 6.1 · 14 min read

The attested key release pattern

Envelope encryption plus attestation: the TEE proves itself, then receives a data key wrapped to its own ephemeral public key.

Why attestation must gate the key

Memory encryption protects data while the TEE runs. But data usually arrives encrypted, and the TEE needs a key to decrypt it. If that key is available to anyone with the right IAM role, the host operator can simply ask for it too, and confidentiality collapses. The fix is to make key release conditional on attestation.

The key service never returns plaintext to the caller's network path; only the private key inside the TEE can unwrap the response.

On AWS

For Nitro Enclaves, the enclave calls KMS Decrypt, GenerateDataKey or GenerateRandom with a Recipient parameter containing its signed attestation document. KMS validates the document, evaluates the key policy conditions, and returns the result in CiphertextForRecipient, encrypted to the public key inside the attestation document. The parent instance relays the bytes but cannot decrypt them.

json

{
  "Sid": "AllowDecryptOnlyFromApprovedEnclave",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111122223333:role/enclave-parent" },
  "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
  "Resource": "*",
  "Condition": {
    "StringEqualsIgnoreCase": {
      "kms:RecipientAttestation:PCR3": "<sha384 of parent role ARN>",
      "kms:RecipientAttestation:PCR8": "<sha384 of EIF signing certificate>"
    }
  }
}

Key policy statement requiring an attested enclave (structure per the AWS KMS Developer Guide)

Key takeaways

Attestation must gate key release, otherwise the host can request the key itself.
Return keys wrapped to an ephemeral public key that is bound into the evidence.
Audit the whole policy: one unconditioned Allow defeats the design.