All cryptographic keys are generated and stored in a Key Management System (KMS). Private keys are never exposed to the platform.
- Three key types: User keys (for approvals), system keys (for internal security), and blockchain keys (for signing transactions).
- Two protection models: HSM (complete keys in tamper-proof hardware) or MPC (keys split across multiple parties).
- Your choice: HSMs for strict compliance requirements. MPC for cloud-native, distributed trust.
- Private keys never leave protection: The platform requests signatures without ever seeing actual private keys.
Key management is the core of custody security — whoever controls the keys controls the assets. Your KMS choice (HSM vs. MPC) affects your compliance posture, backup and disaster recovery options, operational complexity, and cost structure. HSMs provide the auditability and certifications (FIPS 140-2, Common Criteria) that regulators often require, while MPC eliminates single points of failure and enables more flexible deployment architectures.
For architects and operators: This is a foundational decision that cannot be easily changed post-deployment. Evaluate your compliance requirements, geographic distribution needs, and operational capabilities before selecting. See KMS planning for detailed selection guidance.
Before reading this page, you should understand:
- Security architecture - The zero-trust security model and three pillars of security
Ripple Custody uses three types of cryptographic keys:
| Property | User keys | notary & vault keys | Blockchain keys |
|---|---|---|---|
| Role | Sign user decisions (intents) | Sign application data | Sign transactions |
| Algorithm | ECDSA secp256r1, secp256k1, or Ed25519 | EdDSA Ed25519 | Blockchain-specific |
| Key length | 256-bit | 256-bit | Blockchain-specific |
| Storage | Mobile secure enclave, YubiKey, or KMS | KMS | KMS |
| Backup | None needed | Smart card and wrapped export | Smart card and wrapped export |
| Rotation | Lock user and create a new one | Redeploy notary and vault | On-chain address sweeping |
| Revocation | Lock user | Redeploy notary and vault | Funds transferable to new account |
All users (human or machine) that require access to Ripple Custody are associated with a key pair:
- Read access: Users can query data (accounts, balances, transactions) after authenticating with their key
- Write access: Users can submit intents (transfers, policy changes) by signing them with their private key
Key storage:
- Private key: Stored externally (never communicated to the platform). Used to authenticate requests and sign intents.
- Public key: Stored in the database (DER format, Base64 encoded). Used by the notary to verify signatures.
User public keys are registered within the trusted state to prevent identity tampering. Users can store keys in the Ripple Custody mobile app (device secure enclave) or Windows desktop app (YubiKey).
- notary: Uses its private key to sign the Merkle tree root (securing system state) and to authenticate messages to external components.
- vault: Uses its private key to authenticate payloads to external components.
These keys are generated during deployment and stored in your KMS. A key exchange during setup ensures mutual trust between the notary and vault. For details on how these components communicate securely, see Secure communication.
Blockchain keys sign transactions for accounts. The signature algorithm varies by ledger protocol. During account creation, keys are derived from a master seed using:
- Deterministic derivation (BIP32, SLIP10): Hard derivation requires master seed access; soft derivation does not.
- Random generation: Key material is generated randomly, not derived from the seed.
For more information, see Key derivation.
A KMS manages the entire lifecycle of cryptographic keys: generation, storage, usage, rotation, and destruction. The vault component is the only part of the platform that communicates with the KMS.
An HSM is a dedicated, tamper-resistant hardware device. The core principle: private keys never leave the device.
How HSMs protect keys:
- Physical security: FIPS 140-2 Level 3+ certified. Tamper-resistant enclosure with environmental sensors. Any breach triggers "zeroization" (key erasure).
- Logical security: Minimal operating system exposes only a cryptographic API. Applications request operations ("sign this") but cannot extract keys.
Signing workflow:
- vault sends transaction data to HSM with "sign" command.
- HSM performs signing internally using protected private key.
- HSM returns only the signature—key never exposed.
MPC is a cryptographic protocol where no single, complete private key ever exists. The key is split into "shards" held by different parties.
How MPC works:
- Distributed key generation (DKG): Nodes run a protocol where each ends up with a unique shard. No node sees the full key. A corresponding public key is created.
- Threshold signing (TSS): To sign, a threshold of nodes (e.g., 3-of-4) collaborate:
- Each participating node creates a partial signature using its shard.
- Partial signatures combine into one valid signature.
- The full private key is never reconstructed.
MPC in Ripple Custody:
- Scheme: Ripple's proprietary 3-of-4 threshold signing
- Distribution: Shards across customer-hosted and Ripple-hosted infrastructure
- Security: No unilateral key usage—neither you nor Ripple can move funds alone
- Resilience: Built-in shard recovery; tolerates node failures
For detailed MPC configuration and deployment, see MPC integration guide.
| Feature | HSM | MPC |
|---|---|---|
| Core Principle | Hardware security: Device protects complete key | Distributed algorithm: No complete key exists |
| Key Storage | Single key deeply protected in hardware | Key distributed as mathematical shards |
| Security Model | Tamper-resistant hardware (FIPS 140-2/3+) | Threshold math—attacker must breach m-of-n nodes |
| Deployment | Physical appliance or cloud HSM service | Cloud-native software nodes |
| Signing Operation | Single, low-latency API call | Multi-round protocol between nodes |
| Resilience | Single point of failure (requires HA clustering) | Natively resilient; tolerates n-m node failures |
| Backup & Recovery | Physical (smart cards), offline procedures | Shards can be reshared online, no downtime |
| Algorithm Flexibility | Rigid—new algorithms need firmware updates | Flexible—software updates to nodes |
| Cost | High upfront (hardware) + maintenance | Low upfront, ongoing cloud/service fees |
- You have significant existing HSM investment and specialized staff
- Your compliance framework requires FIPS 140-2/3 certified, tamper-proof hardware
- You prioritize lowest possible signing latency
- Your security model is perimeter-based (single, well-defended location)
- You need decades of regulatory acceptance and proven technology
- You prefer cloud-native, flexible deployment (AWS, GCP, Azure)
- You want to avoid managing physical hardware
- Your security model is distributed trust (no single point of failure)
- You need high availability with online shard recovery
- You value algorithm flexibility for new blockchain support
Both HSM and MPC provide strong key protection—the choice depends on your infrastructure, compliance requirements, and operational preferences. For failure scenarios and recovery procedures, see Disaster recovery.
Both HSM and MPC support deterministic key derivation from a single master seed using hierarchical deterministic (HD) wallet standards. This means you only need to back up one seed to recover all accounts.
For comprehensive details on derivation strategies, supported curves, and KMS platform compatibility, see Key derivation.