Security Model
Containment Chamber protects validator signing keys by keeping private key material inside the signer boundary, checking every signature request before signing, and separating operational authority across auth policies, anti-slashing storage, KMS keys, and optional operator quorum.
This page defines the security assumptions and limits. 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 |
| Operator unseal credentials | Never store passphrases or YubiKey secrets |
| Auth tokens | Store only HMAC-hashed token material |
| Slashing history | Preserve complete signing history 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 signing history.
- 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.
- Operators: must protect unseal credentials and management tokens.
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 a chamber master key, and that master key is not persisted in plaintext. Filesystem keystores are supported for Web3Signer-compatible deployments, but they are not a strong at-rest protection boundary when the keystore passwords are stored alongside the files.
Single KMS-key compromise. DynamoDB mode can split the master key across multiple KMS-wrapped Shamir shares, so one KMS key alone is insufficient when the threshold 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 aTLS verification, the parent host can move traffic but cannot directly read enclave memory or KMS plaintext released to the enclave.
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 decrypt enough KMS-wrapped shares to meet the configured threshold, they can reconstruct the master key for DynamoDB-stored validator keys.
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 operator credentials without backup quorum. Operator quorum protects unseal, but lost passphrases or YubiKeys can make the chamber unavailable if the remaining operators cannot meet the threshold.
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 | DynamoDB key source |
| Seal/unseal gating | DynamoDB key source |
| aTLS attestation | Nitro Enclave / aTLS deployments |
Operational Guidance
Section titled “Operational Guidance”- Use PostgreSQL anti-slashing for multi-instance production deployments.
- Use operator quorum when KMS-only auto-unseal is too much trust in AWS credentials alone.
- Use Nitro Enclave mode when the parent host must not see plaintext key material.
- Keep management tokens in a secrets manager and prefer narrowly scoped client tokens.
- Monitor slashing rejections, auth failures, signer state, KMS errors, and canary-key signing.
For deployment-specific steps, see Production Hardening and Observability.