Skip to main content

Key storage

Custody never stores private keys. Instead, every wallet's signing capability is split into shares that live in independent locations, and any subset below the threshold leaks no information about the underlying key. This page describes how those shares are protected at rest and at use.

Shares, not keys​

A share is one piece of an additive secret-sharing scheme over the secp256k1 curve: the full private key x is x = x₁ + x₂ + … + xₙ (mod q). Because scalar multiplication distributes over addition, all parties can collaborate on a signature without any of them ever materialising x.

The practical consequence: shares can be rotated (re-randomised while the public key is held constant), but the underlying key cannot. This is the property every other control on this page is designed to protect.

At rest​

Each share is encrypted with AWS KMS before being written to the operational database. The KMS key policy is bound to the cryptographic hash of the enclave image that is allowed to call Decrypt; any drift in that image — for example, a tampered build — produces a different hash and is silently denied.

This means that a Custody platform administrator with full AWS console access cannot read a share. They have no path to invoke the workload that the policy authorises, only the policy that authorises some workload.

At use​

Decryption only happens inside an AWS Nitro Enclave. The enclave has no persistent disk, no terminal, no network access, and no shared memory with the parent host. Communication with the parent is restricted to a VSOCK channel.

Calls to KMS originate from the enclave through a proxy on the parent host; the request carries a cryptographic attestation document signed by the AWS Nitro hypervisor. KMS validates that attestation against the policy before returning the decrypted material — meaning that even if the proxy were compromised, it cannot trick KMS into releasing a share to itself.

Trade-offs​

This design trades portability for guarantees. The combination of KMS attestation + Nitro Enclave is AWS-specific; migrating off AWS would require swapping both for an equivalent stack (e.g. Confidential Containers on a different provider). The vendor lock-in was an explicit, accepted trade-off in exchange for an unconditional zero-trust property: no role, no operator, no admin can read share material outside the authorised enclave image.

Out of scope here​

  • The threshold and rotation cadence for shares — see Key lifecycle.
  • The disaster-recovery copy of shares stored outside AWS — see Backup & recovery.
  • The HD-derivation strategy that maps wallets to addresses — see Key management.