AWS Setup for Enclave

Signing Certificate

The signing certificate is used to sign the EIF file. Its SHA-384 hash becomes PCR8 — the KMS key policy condition that gates decryption.

1. Generate a signing keypair (do this once, store the key securely):

   openssl ecparam -name secp384r1 -genkey -noout -out signing_key.pem
   openssl req -new -x509 -key signing_key.pem -out signing_cert.pem \
     -days 3650 -subj "/CN=containment-chamber"

2. Extract the PCR8 hash (after building the EIF):

   nitro-cli build-enclave \
      --docker-uri containment-chamber:latest-enclave \
     --signing-certificate signing_cert.pem \
     --private-key signing_key.pem \
     --output-file enclave.eif
   
   nitro-cli describe-eif --eif-path enclave.eif | jq -r '.Measurements.PCR8'
   # → abc123def456...  (your PCR8 hash)

3. Extract the PCR0 hash (changes on every rebuild):

   nitro-cli describe-eif --eif-path enclave.eif | jq -r '.Measurements.PCR0'
   # → 789xyz...  (your PCR0 hash)

Protect the signing key

Anyone with the signing key can sign a malicious enclave that passes PCR8. Store it in a hardware security module or a separate, restricted AWS account. PCR0 provides defense-in-depth: even with the signing key, an attacker cannot forge the binary hash.

Terraform Configuration

Use the enclave Terraform example to create the infrastructure with attestation-gated KMS key policies:

cd terraform/examples/enclave

terraform init
terraform apply \
  -var 'primary_profile=account-a' \
  -var 'secondary_b_profile=account-b' \
  -var 'secondary_c_profile=account-c' \
  -var 'enclave_signing_cert_hash=<PCR8_HASH>' \
  -var 'enclave_pcr0_hashes=["<PCR0_HASH>"]'

KMS Key Policy Structure

The Terraform example creates KMS key policies with:

• kms:Decrypt — requires PCR8 (always) + PCR0 (when provided) + PCR3 (optional)
• kms:Encrypt — allowed to the same signer role without an attestation condition. KMS does not support RecipientAttestation on Encrypt; the share plaintext originates inside the enclave and is sent to KMS over TLS.

# PCR8 — signing certificate hash (required)
# PCR0 — image hash (required for production)
# PCR3 — parent IAM role hash (optional, extra lockdown)

PCR8-only is for dev/test only

PCR8 alone is insufficient for production. If the signing key is compromised, an attacker can sign a malicious enclave. Always set enclave_pcr0_hashes in production.

IAM Configuration

The signer IAM role needs:

• DynamoDB access (keystore + antislashing tables)
• KMS access for table encryption keys (via IAM policy)
• kms:Encrypt and kms:Decrypt for Shamir keys. In cross-account setups, both the caller IAM policy and the target KMS key policy must allow the signer role.

For production enclave deployments, prefer N attestation-gated KMS keys in N AWS accounts, administered by different people or teams. This keeps the enclave memory boundary from depending on one AWS account administrator: changing one key policy, compromising one account, or disabling one KMS key is not enough to recover or deny the chamber master key when the Shamir threshold is chosen correctly.

Use the same separation for the enclave KMS policies as for standard DynamoDB+KMS mode, but add Nitro attestation conditions to every Shamir KMS key. Each account should independently review and approve PCR changes during upgrades.

For EKS deployments, configure IRSA or EKS Pod Identity:

# IRSA
kubectl annotate serviceaccount containment-chamber \
  eks.amazonaws.com/role-arn=arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME

# EKS Pod Identity
aws eks create-pod-identity-association \
  --cluster-name my-cluster \
  --namespace default \
  --service-account containment-chamber \
  --role-arn arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME