Nitro Enclave Overview

Containment Chamber can run inside an AWS Nitro Enclave — an isolated compute environment with hardware-enforced memory encryption. When running in enclave mode, validator BLS private keys only exist decrypted inside the enclave’s protected memory. Even a fully compromised EC2 instance cannot access them.

Nitro mode is selected with tee.platform: nitro. It also requires tls.mode: atls and a persistent signer_state backend. The enclave exposes the signing API over vsock, and the parent EC2 instance only forwards bytes between TCP clients, AWS services, and the enclave.

Security Model

The enclave security model rests on three pillars:

1. Memory isolation — The Nitro hypervisor encrypts enclave memory with a key that never leaves the hardware. The parent EC2 instance, AWS operators, and anyone with physical access to the machine cannot read enclave memory.

2. Attestation — The Nitro Security Module (NSM) produces signed attestation documents proving: “This enclave is running this exact binary, with these PCR measurements.” KMS validates these documents before releasing key material.

3. Reproducible builds — Anyone can rebuild the enclave binary from source and verify the PCR0 hash matches the published release. This makes the attestation independently verifiable.

Architecture

The enclave uses a parent-side vsock-proxy per outbound endpoint: KMS, DynamoDB, STS or Pod Identity, and optionally PostgreSQL for anti-slashing. For each configured endpoint, the enclave maps the hostname to a unique loopback address and forwards that local TCP connection over vsock to the parent. End-to-end TLS is preserved — the parent moves bytes but does not terminate the connection.

aTLS is mandatory in Nitro mode. The enclave generates an ephemeral TLS key, asks the NSM for an attestation document bound to the key’s SPKI hash, and embeds that document in the X.509 certificate. Clients can verify the certificate against Nitro PCR measurements before sending signing or operator traffic.

What the Enclave Protects

Threat	Without Enclave	With Enclave
Compromised EC2 instance	❌ Attacker reads key material from memory	✅ Enclave memory is hardware-encrypted
Compromised KMS credentials	❌ Attacker calls KMS directly	✅ KMS requires valid NSM attestation
Malicious enclave binary	❌ No verification	✅ PCR0 hash must match expected value
Compromised signing certificate	❌ Attacker signs malicious binary	✅ PCR0 still blocks wrong binary

The Unverifiable Link

PCR Values

Nitro Enclaves use Platform Configuration Registers (PCRs) to record measurements:

PCR	What It Measures	Changes When
PCR0	Hash of the entire EIF binary	Every rebuild
PCR8	Hash of the signing certificate	Signing key rotation
PCR3	Hash of the parent IAM role ARN	IAM role changes

Production deployments should enforce both PCR8 and PCR0. PCR8 alone is insufficient — if the signing key is compromised, an attacker can sign a malicious binary that passes PCR8. PCR0 prevents this because it pins to the exact binary hash.

With reproducible builds, each key holder can independently verify PCR0 by rebuilding from source.

KMS Custody

Nitro Enclaves isolate decrypted key material from the parent instance, but KMS policy control is still part of the trust model. For production, use multiple Shamir KMS keys across separate AWS accounts, with separate administrators. Each account should enforce the enclave attestation policy on its own key and independently approve PCR updates during upgrades.

This prevents one AWS account admin from unilaterally changing every KMS policy or disabling every share. Choose the threshold to match your availability and governance needs, such as 2-of-3 for simple custody separation or 3-of-5 for a higher collusion bar.

Next Steps

AWS Setup — KMS key policies, signing certificates, IAM
Deployment — Helm chart, K8s prerequisites
Operations — PCR rotation, troubleshooting