Containment Chamber protects validator signing keys by keeping private key material inside the signer boundary, checking every signature request before signing, and anchoring custody in a set of AWS KMS keys rather than operator passphrases or quorum handshakes.
The kms_auto-static model: the chamber master key is a 256-bit secret Shamir-split M-of-N across N AWS KMS custody keys; each share is individually KMS-wrapped and stored in the MASTER_KEY DynamoDB row. The trust anchor is the static ceremony parameter set — compiled into the binary and PCR0-measured on Nitro builds, or supplied in a trusted ceremony: config block on standard deployments. Custody parameters are not operator-supplied at runtime; they are part of the deployed artifact.
This page defines the security assumptions and limits. For the detailed adversary analysis — exactly what a compromised parent can and cannot do — see Threat & Risk Model. For component layout and deployment modes, see Architecture Overview.
Assets Protected
Section titled “Assets Protected”| Asset | Protection goal |
|---|---|
| Validator BLS private keys | Never expose through APIs, logs, config files, or persistent plaintext storage |
| DynamoDB master key | Keep plaintext only in memory while the chamber is unsealed; split M-of-N across KMS keys at rest |
| Auth tokens | Persist only HMAC-hashed token material in state-backed mode; resolve stateless static_auth secrets from config/env and hash them in memory at boot |
| Slashing history | Preserve non-regressing slashing-protection state before approving new signatures |
Trust Boundaries
Section titled “Trust Boundaries”Standard Mode
Section titled “Standard Mode”In standard mode, the host running the signer is inside the trust boundary. A compromised kernel, root account, or container runtime can read process memory or replace the binary. Use host hardening, network isolation, and least-privilege deployment controls to reduce that risk.
Nitro Enclave Mode
Section titled “Nitro Enclave Mode”In Nitro Enclave mode, the parent EC2 instance or Kubernetes pod is outside the key-material trust boundary. It can forward bytes, provide bootstrap services, and observe metadata such as timing, but decrypted validator keys and reconstructed master-key material stay inside enclave memory.
Nitro mode still trusts AWS Nitro attestation, AWS KMS policy enforcement, and the correctness of the enclave image being measured. See Nitro Enclave Overview for the full model.
External Systems
Section titled “External Systems”Containment Chamber depends on configured external systems:
- Anti-slashing backend: must preserve accurate, non-regressing signing safety state.
- AWS KMS: must enforce key policies and decrypt only for authorized callers or attested enclaves.
- DynamoDB state/key tables: must preserve encrypted key material and chamber state rows with integrity.
What It Protects Against
Section titled “What It Protects Against”Unauthorized signing. Auth policies can restrict callers by API scope, validator key, signing operation, and optional CIDR binding.
Slashable duplicate signing. Anti-slashing checks run before every signature. PostgreSQL is recommended for multi-instance production deployments; SQLite and DynamoDB are available for other deployment models.
Plaintext key persistence in DynamoDB mode. DynamoDB validator keys are encrypted under the chamber master key, which is never stored in plaintext. The master key lives Shamir-split across KMS custody keys; reconstructing it requires at least kms_threshold KMS decrypts from the ceremony key set.
Single KMS-key compromise. Because the master key is Shamir-split M-of-N, compromising one KMS key is insufficient when the threshold M is greater than one.
Accidental secret leakage. Private keys and plaintext tokens are not returned by APIs or written to logs. Secrets are zeroized when dropped, and Linux builds disable core dumps.
Compromised parent host in Nitro mode. With attested KMS and RA-TLS verification, the parent host can move traffic but cannot read enclave memory or KMS plaintext released only to the attested enclave.
Share renumbering and splicing attacks. Even if an attacker has DynamoDB write access, the share_hmac field — a master-key-keyed HMAC over each share’s share_id and every wrap’s (kms_key_arn, blob) — prevents forging a row with renumbered or spliced shares that would pass Shamir reconstruction.
Forged SEAL_OVERRIDE latches. The SEAL_OVERRIDE row carries an HMAC over (sealed_at, sealed_by_replica, reason) computed by a master-key subkey. The watcher verifies this HMAC before honouring a seal — a forged or tampered latch fails the watcher tick rather than triggering an unauthorized seal.
What It Does Not Protect Against
Section titled “What It Does Not Protect Against”A fully compromised standard-mode host. Root-level access to the host can read process memory or replace the running binary. Use Nitro Enclave mode when the parent host should not be trusted with plaintext key material.
Enough compromised KMS keys. If an attacker can obtain plaintext decrypts from kms_threshold or more of the ceremony KMS keys, they can reconstruct the master key. Protect KMS key policies, IAM, and CloudTrail accordingly.
Tampered anti-slashing history. If an attacker can delete or rewrite slashing-protection records, the signer may approve signatures it should reject. Protect the backend with authentication, network controls, backups, and restricted write access.
Malicious or compromised validator clients. The signer can restrict what a client may request, but it cannot prove the validator client’s fork choice is honest.
Lost root token with a deleted ROOT_TOKEN_BOOTSTRAP row. The root management token is age-encrypted to root_token_recipients and stored in the ROOT_TOKEN_BOOTSTRAP DynamoDB row at auto-init. If both the decrypted token and the row are lost before any client tokens are created, re-create by IAM-deleting the ROOT_TOKEN_BOOTSTRAP row and restarting — boot re-creates iff the row is absent. Plan accordingly.
Custody Integrity Layers
Section titled “Custody Integrity Layers”The following layers protect the master key and custody state independently; each must be defeated in sequence for a custody attack to succeed.
Master-key commitment
Section titled “Master-key commitment”The MASTER_KEY row carries master_key_hash: a SHA-256 commitment to the plaintext master key, computed at auto-init and re-verified after every KMS auto-unseal. If reconstructed key bytes do not match the stored commitment — whether due to a share substitution attack or storage corruption — unseal fails closed.
Share-binding HMAC
Section titled “Share-binding HMAC”share_hmac in the MASTER_KEY row is an HMAC-SHA256 value keyed by a master-key subkey, computed over each share’s share_id and every wrap’s (kms_key_arn, blob) in canonical order. A DynamoDB-write attacker without the master key cannot produce a valid share_hmac for a modified share layout. Verified immediately after the master-key commitment check during auto-unseal.
KMS-ARN gate
Section titled “KMS-ARN gate”The auto-unseal path accepts decrypted share blobs only when the kms_key_arn reported by DynamoDB is present in the ceremony key set’s ARN list. Blobs wrapped under out-of-ceremony keys are rejected, regardless of whether KMS decrypts them. On Nitro, the ceremony ARN list is part of the PCR0-measured binary — changing which KMS keys are trusted requires a measurable rebuild.
Per-row DynamoDB HMAC
Section titled “Per-row DynamoDB HMAC”Individual DynamoDB rows carrying sensitive state (auth tokens, policies) are HMAC-authenticated by master-key-derived subkeys. A DynamoDB-write attacker without the master key cannot forge a row whose HMAC verifies.
SEAL_OVERRIDE HMAC
Section titled “SEAL_OVERRIDE HMAC”The SEAL_OVERRIDE row carries an HMAC over (sealed_at, sealed_by_replica, reason) computed by a master-key subkey. The watcher verifies this HMAC before honouring the latch. A forged or tampered SEAL_OVERRIDE row — written by an attacker with DynamoDB write access but not the master key — causes the watcher tick to fail rather than sealing the replica (RC8 tamper detection). When the master key is not available (pre-unseal), the latch is honoured conservatively: any present latch stops boot.
Attested KMS decrypts (Nitro)
Section titled “Attested KMS decrypts (Nitro)”On Nitro, every KMS decrypt uses RecipientAttestation: the KMS response is encrypted to a public key generated inside the enclave and bound to the NSM attestation document. A valid decrypt can only be consumed inside the measured enclave. The parent host cannot intercept or pre-compute KMS plaintext for a different binary.
Built-In Protections
Section titled “Built-In Protections”| Protection | Applies when |
|---|---|
| Check-before-sign anti-slashing | Always, with configured backend |
| Auth policy enforcement | When policies or unauthenticated policy are configured |
| HMAC-hashed auth tokens | Auth enabled |
| Constant-time token comparison | Auth enabled |
| Secret zeroization | Always |
| Core dump prevention | Linux |
| Memory locking | Linux, when permitted by host capabilities |
| Master-key Shamir splitting (M-of-N across KMS keys) | DynamoDB key source |
| Master-key commitment verification on unseal | DynamoDB key source |
| Share-binding HMAC | DynamoDB key source |
| KMS-ARN gate (ceremony key set) | DynamoDB key source |
| SEAL_OVERRIDE HMAC (tamper detection) | DynamoDB key source |
| Seal/unseal gating | DynamoDB key source |
| RA-TLS attestation | Nitro Enclave / RA-TLS deployments |
| PCR0-measured ceremony static | Nitro Enclave |
Operational Guidance
Section titled “Operational Guidance”- Use PostgreSQL anti-slashing for multi-instance production deployments.
- Use Nitro Enclave mode when the parent host must not see plaintext key material.
- Set
kms_threshold≥ 2 with KMS keys in distinct AWS accounts or regions to require multi-key compromise. - Keep management tokens in a secrets manager and prefer narrowly scoped client tokens.
- Protect DynamoDB write access at the IAM level; write access alone is insufficient for a custody attack, but DynamoDB integrity is a defence-in-depth layer.
- Monitor slashing rejections, auth failures, signer state, KMS errors, and canary-key signing.
For deployment-specific steps, see Production Hardening and Observability.
Next Steps
Section titled “Next Steps”- Architecture Overview — how the signer is structured and how requests flow
- Threat & Risk Model — adversaries, the untrusted-parent capability analysis, and the residual risks you must mitigate
- Production Hardening — turn the model into concrete hardening steps
- Auth Policies & Tokens — configure per-key, per-operation access control