Security Model
The Carabaas security model is built on three pillars: MPC threshold cryptography (no single party holds a complete key), hardware enclave isolation (secrets are inaccessible to infrastructure operators), and multi-layer encryption at rest (defense-in-depth for stored data).
No Single Party Holds a Complete Key
A complete private key is never instantiated — not in any cosigner's memory, not on any disk, and not anywhere in the platform. This is a mathematical property of the MPC protocol, not a policy control.
- During vault setup, each cosigner independently generates its own key share. No party computes or distributes the full private key.
- During signing, cosigners execute a multi-round protocol that produces a valid signature without any party computing the full key. Each cosigner contributes a partial computation; the platform assembles the result.
- During key rotation (reshare), key shares are re-encrypted for the new cosigner. The full key is never assembled.
Consequence: Compromising a single cosigner — even with full root access, memory dump, and all disk contents — does not expose the complete wallet private key.
Enclave Isolation
In production, the cosigner runs inside an AWS Nitro Enclave — a hardware-isolated virtual machine with no persistent storage, no network access, and no interactive access (no SSH, no shell).
The parent application on the host EC2 instance acts as a message relay only — it handles networking and file I/O but never has access to key material, encryption keys, or the cosigner's identity private key.
What Stays Inside the Enclave
| Inside Enclave (never exits) | Crosses VSOCK Boundary |
|---|---|
| BIP39 mnemonic & seed | Encrypted mnemonic shares (opaque ciphertext) |
| Master private keys | Derived public keys and chaincodes |
| MPC key shares (plaintext) | Encrypted MPC key files |
| Cosigner RSA-4096 private key | Signed JWTs, public key + id |
| Storage encryption KEK | Final assembled signatures |
Attestation
The enclave produces AWS Nitro attestation documents — cryptographically signed by the Nitro Hypervisor — proving the identity and integrity of the running code:
| PCR Register | Content |
|---|---|
| PCR0 | Hash of the enclave image (EIF) |
| PCR1 | Hash of the Linux kernel |
| PCR2 | Hash of the application |
| PCR8 | Hash of the signing certificate (if signed) |
Unseal key holders should verify the attestation document before submitting their passwords, confirming they are communicating with a genuine, unmodified enclave.
Multi-Layer Encryption at Rest
All sensitive data is protected by multiple independent encryption layers:
| Layer | Algorithm | Key Source | Purpose |
|---|---|---|---|
| 1 | EBS volume encryption | AWS KMS CMK, tied to IAM role | Infrastructure-level disk encryption |
| 2 | AES-256-GCM (app-level) | HKDF-derived KEK inside enclave | MPC key file envelope encryption |
| 3 | AES-256-GCM + Argon2id | Password-derived key (64 MiB, p=4) | Mnemonic share encryption |
Even if all layers are defeated, the attacker obtains only one MPC key share — not the complete wallet key.
Storage Tiers
| Property | Tier 1: Local Disk | Tier 2: S3 + KMS | Tier 3: Physical HSM |
|---|---|---|---|
| Seed location | Enclave memory | Enclave memory | HSM hardware (never in memory) |
| File encryption | HKDF from seed | KMS DEK (PCR-attested) | HSM wrapping key |
| Access control | OS file permissions | KMS policy + PCR attestation | HSM CU credentials |
| Durability | Single disk | S3 (11 nines) | HSM cluster (multi-AZ) |
| Compliance | SOC 2 | SOC 2 | SOC 2 + FIPS 140-2 L3 |
Seal / Unseal Security
The seal/unseal mechanism ensures that technical personnel cannot access cryptographic material. Even with full root access, the cosigner remains inert until unsealed by designated key holders.
Key security properties:
- Separation of duties — infrastructure operators are distinct from unseal key holders. Neither role alone can access secrets.
- No persistent plaintext — the mnemonic exists only in enclave memory while READY. It is never written to disk in plaintext.
- 2-of-3 threshold — a single compromised key holder cannot unseal the cosigner.
- Rate limiting — 5 failed unseal attempts trigger exponential backoff lockout (1 min to 1 hour max).
- Auto-seal on restart — every process restart, server reboot, or software upgrade returns the cosigner to SEALED state.
See Seal / Unseal for the full lifecycle.
Signing Security
The cosigner implements CMP (Canetti–Maurer–Paillier) for ECDSA and an asymmetric protocol for EdDSA.
| Algorithm | Curve | Use Case |
|---|---|---|
| ECDSA | secp256k1 | Bitcoin, Ethereum, and compatible chains |
| ECDSA | secp256r1 (P-256) | Blockchains using the NIST P-256 curve |
| EdDSA | Ed25519 | Solana, Cardano, and compatible chains |
Before signing, the cosigner independently verifies quorum approval signatures. After signing, it independently verifies the assembled signature using the derived public key — rejecting it if verification fails.
Threat Model Summary
| Threat | Protection | How |
|---|---|---|
| Provider goes rogue or ceases operations | Merchant can recover independently | Per-vault key ejection or escrowed seed backup; provider cannot block recovery |
| Single-party key theft | Mathematically impossible | MPC 2-of-2 threshold; complete key is never instantiated anywhere |
| Unauthorized transactions | Merchant-controlled governance | Quorum approval policies, role-based access, signing requires merchant's cosigner |
| Server / infrastructure compromise | Zero key material exposed | AWS Nitro Enclave isolation; host process is relay only; multi-layer encryption at rest |
| Insider threat (provider or merchant) | No unilateral access to keys | Separation of duties: infrastructure operators ≠ unseal key holders ≠ approvers |
| Compromised platform infrastructure | Cannot extract key shares or bypass approval | MPC protocol guarantee; cosigner independently verifies quorum before signing |
| Disk theft / forensics | Multi-layer encryption | AES-256-GCM (app) + KMS (infra) + Argon2id passwords; three independent layers |
| Unseal key holder compromise (1 of 3) | No impact | Shamir threshold not met; single share reveals zero information (information-theoretic) |
| Modified enclave image | Detected via attestation | PCR hash changes on any modification; unseal key holders verify before submitting |
Cryptographic Primitives
| Primitive | Usage |
|---|---|
| AES-256-GCM | Share encryption, key file envelope encryption, identity encryption |
| Argon2id (t=3, m=64MiB, p=4) | Password-based key derivation for unseal shares |
| HKDF-SHA256 | Storage KEK derivation from seed |
| HMAC-SHA512 | BIP32 master key derivation |
| RSA-4096 (RS256, OAEP) | Cosigner identity, JWT signing, reshare encryption |
| Ed25519 | Unseal key holder identity, challenge-response auth |
| Shamir Secret Sharing | Mnemonic splitting (2-of-3 threshold) |
| BIP32 / BIP44 | Hierarchical deterministic key derivation |
| Nitro Attestation (COSE_Sign1) | Enclave code integrity proof via PCR registers |
Data in Transit
| Channel | Protocol | Authentication | Encryption |
|---|---|---|---|
| Cosigner ↔ Platform | WebSocket | JWT (RS256, signed inside enclave) | TLS |
| Unseal Key Holder ↔ Cosigner | HTTPS | Challenge-response (Ed25519) | TLS |
| Parent ↔ Enclave | VSOCK | Hypervisor-mediated | N/A (isolated channel) |
| API Client ↔ Platform | HTTPS | Self-signed JWT (RS256) | TLS |
Regulatory Alignment
The Carabaas self-custody platform aligns with:
- EU MiCA (Article 75) — custody safeguarding requirements
- DORA (Articles 28–30) — ICT third-party risk management and exit planning
- EBA outsourcing guidelines — proportionality, due diligence, exit strategies
- U.S. state custody expectations — key control, segregation, auditability
The merchant remains the regulated entity. Carabaas is classified as an ICT infrastructure provider, not a custodian — it cannot independently authorize, execute, or block transactions.
See Compliance & Regulatory for detailed positioning.