# Key management planning

This topic explains the *key management system* (KMS) options available in Ripple Custody, and helps you choose the right approach for your organization.

## What is a key management system (KMS)?

A *key management system* (KMS) is the core of any digital asset custody solution. It manages the entire lifecycle of cryptographic keys:

- **Generation**: Securely creating new keys
- **Storage**: Protecting keys from unauthorized access
- **Usage**: Using keys to sign transactions without exposing them
- **Rotation & Destruction**: Securely retiring old keys


In Ripple Custody, all cryptographic keys — including notary keys, vault keys, and blockchain account keys — are generated and stored securely using a KMS. The vault component is the only part of the platform that communicates with the KMS. The KMS performs all sensitive operations. Private keys are never exposed to the core platform or the network.

For a deeper understanding of key management concepts, see [Key management](/products/custody/v1.34/overview/key-management).

## Supported KMSs

Ripple Custody supports both HSM- and MPC-based configurations. Choose the model that best fits your security, operational, and compliance needs. This abstraction layer allows you to align with your current infrastructure investments (e.g., existing HSMs) or adopt cloud-native models (MPC). Each time you initialize and register a new vault, you must specify which key management model it will use: HSM or MPC.

## Hardware security modules (HSMs)

### What is an HSM?

An HSM (hardware security module) is a dedicated, tamper-resistant hardware device. Think of it as a physical safe or a secure "black box" designed for one purpose: to protect cryptographic keys.

The core principle of an HSM is that private keys never leave the device. The HSM generates, stores, and uses keys internally. Only the outputs of cryptographic operations (like a signature) are ever exported.

### How HSMs work

HSMs protect keys using two primary methods:

- **Physical security**: The hardware is certified (e.g., FIPS 140-2 Level 3+) to be tamper-resistant and tamper-evident. It is sealed in a secure enclosure. Any attempt to physically breach it (by drilling, opening, or applying extreme temperatures) triggers the device to "zeroize," or erase all the keys it holds.
- **Logical security**: The device runs a secure, minimal operating system. It only exposes a strict cryptographic API, meaning applications can request operations (like "sign this transaction") but cannot extract the private keys themselves.


### How HSMs work in Ripple Custody

In addition to signing, the platform uses the HSM to generate and securely protect the master seeds for blockchain accounts. It supports deterministic key derivation strategies like BIP32 and SLIP10.

The core signing workflow is as follows:

1. The vault component needs to sign a transaction.
2. It sends the transaction data (or a hash of it) to the HSM with a "sign" command, specifying which key to use.
3. The HSM performs the signing operation internally using the private key it protects.
4. The HSM returns only the resulting digital signature to the vault. The private key itself is never exposed.


### FIPS certification levels

All HSMs supported by Ripple Custody meet or exceed **FIPS 140-2 Level 3** certification, the industry standard for cryptographic hardware security. FIPS certification levels indicate the security assurance of the hardware:

| Level | Security Requirements |
|  --- | --- |
| **Level 3** (minimum) | Tamper-evident physical security, identity-based authentication, physical separation between interfaces |
| **Level 4** (highest) | All Level 3 requirements plus environmental failure protection and active tamper response |




### Supported HSMs

Ripple Custody supports several industry-standard HSMs. For a complete list of supported KMS platforms and integration guides, see [Key Management System Integration](/products/custody/v1.34/how-to/integrate-kms/overview).

**SecuroSys availability**: SecuroSys HSM integrations are available on a case-by-case basis. Contact your Ripple account team to discuss availability and requirements for your deployment.



## Multi-party computation (MPC)

### What is MPC?

MPC (multi-party computation) is a cryptographic protocol, not a single piece of hardware. It allows a group of parties (or nodes) to jointly compute a function, like signing a transaction. No single party ever knows the other parties' secret inputs.

The core principle of MPC is that no single, complete private key ever needs to exist in one place. The key is generated in a distributed state, split into several "shards" (or secret shares) held by different parties. To sign a transaction, the parties collaborate to produce a signature. They never combine their individual shards.

### How MPC works

MPC replaces the hardware approach with a distributed mathematical one:

- **Distributed key generation (DKG)**: A group of nodes (e.g., 4 nodes) run a protocol. At the end, each node holds a unique key shard. No single node, nor any external party, ever sees the full private key. A corresponding public key is created that the world can see and use to send funds.
- **Threshold Signing (TSS)**: To sign a transaction, a minimum number ("threshold") of the parties (e.g., 3-of-4) must collaborate:
  1. Each of the collaborating nodes uses its secret shard to create a partial signature.
  2. These partial signatures are mathematically combined to create one final, valid signature for the public key.
  3. This final signature is cryptographically identical to one that would have been created by a single private key.
  4. An attacker must compromise the full threshold of nodes (e.g., 3) to forge a signature. Compromising only 1 or 2 nodes yields nothing.


### MPC in Ripple Custody

MPC is a key management option available in Ripple Custody:

| Characteristic | Description |
|  --- | --- |
| **Scheme** | Ripple's proprietary 3-of-4 threshold signing scheme. |
| **Distribution** | Key shards are distributed across both customer-hosted and Ripple-hosted infrastructure. This design ensures no unilateral key usage — neither you nor Ripple can move funds alone. |
| **Deployment** | Cloud-native, supporting flexible node deployment in environments like AWS and Azure. |
| **Resilience** | Built-in shard recovery prevents data loss; Ripple-hosted nodes ensure high availability (HA). |


For MPC deployment details, see:

- [MPC Integration Overview](/products/custody/v1.34/how-to/integrate-kms/mpc/overview)
- [MPC Deployment on AWS](/products/custody/v1.34/how-to/integrate-kms/mpc/aws-deployment)
- [MPC Backup and Recovery](/products/custody/v1.34/how-to/integrate-kms/mpc/backups)


## Comparison: HSM vs. MPC

| Feature | Hardware Security Module (HSM) | Multi-Party Computation (MPC) |
|  --- | --- | --- |
| **Core principle** | Hardware security: A hardware device protects a complete key. | Distributed algorithm: A cryptographic protocol where no complete key ever exists. |
| **Key storage** | A single, complete private key exists but is deeply protected inside the hardware. | No single private key exists. It is distributed as mathematical shards across multiple nodes. |
| **Security model** | Relies on tamper-resistant hardware (FIPS 140-2/3+) and logical access controls. | Cryptographic: Relies on threshold math. An attacker must breach m-of-n nodes to forge a signature. |
| **Deployment** | Physical appliance in a data center or a rented hardware instance (e.g., AWS CloudHSM). | Cloud-native software nodes that can be deployed across different regions or even different clouds. |
| **Signing operation** | A single, low-latency API call to the hardware. | A multi-round communication protocol between m-of-n nodes. Requires network connectivity and liveness. |
| **Resilience** | The HSM device is a single point of failure. Requires dedicated, often complex, high-availability (HA) clustering. | Natively resilient to node failure. Can tolerate the loss of n-m nodes (e.g., 1 node in a 3-of-4 scheme) with no downtime. |
| **Backup & recovery** | Backups are physical (e.g., smart cards) and require a secure, offline procedure for high-assurance recovery. | Shards can be "reshared" (re-created and distributed) or recovered online, without downtime. |
| **Algorithm flexibility** | Rigid. Adding new blockchain signing algorithms often requires a firmware update from the hardware vendor. | Flexible. New signing algorithms are a software update to the nodes. |


### Performance considerations

Signing latency is a critical factor for high-volume transaction use cases:

| Metric | HSM | MPC |
|  --- | --- | --- |
| **Typical signing latency** | < 10 ms | 100–500 ms |
| **Latency factors** | Single API call to local hardware | Multi-round network protocol between nodes |
| **Throughput** | High (hardware-limited) | Moderate (network-limited) |
| **Best for** | High-frequency trading, real-time payments | Standard custody operations, batch processing |


**Performance trade-off**: HSMs offer lower latency but require complex HA clustering for resilience. MPC has higher latency but provides native fault tolerance. Choose based on your transaction volume and latency requirements.

### Cost considerations

| Factor | HSM | MPC |
|  --- | --- | --- |
| **Upfront cost** | High (hardware purchase, installation) | Low (no hardware required) |
| **Operational cost** | Lower (hardware maintenance, power, cooling) | Subscription-based (cloud infrastructure) |
| **Staffing** | Requires specialized HSM expertise | Standard cloud/DevOps skills |
| **Scaling cost** | Step function (new hardware per capacity tier) | Linear (add cloud resources as needed) |


## Which model should you choose?

### Choose an HSM if:

- You are a large financial institution with significant existing investment in HSMs and the specialized staff to manage them.
- Your internal risk and compliance framework is built on the gold standard of FIPS-certified, tamper-proof hardware.
- Your operational model prioritizes the lowest possible latency for a single, non-interactive signing operation.
- Your primary security concern is preventing key extraction from a single, well-defended perimeter (your data center).


### Choose MPC if:

- You are a cloud-native organization or prefer a flexible, cloud-first deployment model (AWS, Azure).
- You need operational agility and want to avoid managing physical hardware.
- Your security model is built on distributed trust, eliminating any single point of failure. You want multiple layers of redundancy so no single person or system can unilaterally access funds.
- You require high availability and flexible disaster recovery (like online shard recovery). You can accommodate the network-interactive nature of threshold signing.


## Next steps

- **Review resilience requirements**: See [Resilience planning](/products/custody/v1.34/deployment/planning/resilience) for HA/DR considerations.
- **Assess team readiness**: See [Personnel and expertise requirements](/products/custody/v1.34/deployment/planning/readiness) for required expertise.
- **Choose your KMS**: Select from the [Supported HSMs](#supported-hsms) or [MPC](#mpc-overview) options above.
- **Review production best practices**: See [Production best practices](/products/custody/v1.34/how-to/integrate-kms/production-best-practices).
- **Plan blockchain nodes connectivity**: See [Blockchain node planning](/products/custody/v1.34/deployment/planning/blockchain-nodes).