# Key management

Executive summary
**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.


Why this matters
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 [Key management planning](/products/custody/deployment/planning/key-management) for detailed selection guidance.

Prerequisites
Before reading this page, you should understand:

- [Security model](/products/custody/overview/security-model) - The zero-trust security model and three pillars of security


## Types of keys

Ripple Custody uses asymmetric cryptography throughout to ensure integrity and non-repudiation.

Ripple Custody uses three types of cryptographic keys:

- User keys
- Notary and vault keys
- Blockchain account 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 |


### User keys

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.


A valid public key is in DER format with Base64 encoding:


```bash
"MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEe32vCCfM0LXmT6VuZo4AykiZ8YfBMB92nKNX8K+PRhN7/qPhILzGlOv/7kDyefTxHSrytXG28OB0cPwErlHgyQ=="
```

User public keys are registered within the trusted state to prevent identity tampering. Registering a user public key is a governed state change, such as a user creation intent or the genesis setup for initial users.

Users are responsible for protecting their own private keys. The Ripple Custody mobile application stores keys in the device secure enclave. For Windows desktop app users, keys are stored in a YubiKey, which provides smart card functionality based on the Personal Identity Verification (PIV) interface. YubiKey 5 FIPS Series devices are required for Windows desktop use. Alternatively, customers can use another KMS approach.

For API signing setup, see [Generate a key pair and register a public key](/products/custody/identity-and-access/authentication/generate-api-keys-and-register).

### Notary and vault keys

- **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](/products/custody/overview/security/secure-communication).

### Blockchain keys

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.


These strategies store keys in the database, wrapped with the master seed where applicable.

For more information, see [Key derivation](/products/custody/accounts-and-assets/accounts/account-key-derivation-and-ledger-compatibility).

## Key Management Systems (KMS)

A KMS manages the lifecycle of protected cryptographic keys: generation, storage, usage, rotation, and destruction. Components that need protected signing operations use KMS-backed integrations: the notary signs trusted-state data, the vault derives account keys and signs blockchain transactions, and system-signed intent deployments can use a Gateway-dedicated KMS Connect path for internal proposal signing. Private keys remain inside the configured KMS, HSM, or MPC protection boundary.

For supported KMS platforms and integration guides, see [Integrate a key management system](/products/custody/deployment/integrate-kms/overview).


```mermaid
flowchart LR
    Generate["Generate<br/>Key ceremony"]
    Store["Store<br/>Secure in KMS"]
    Use["Use<br/>Sign requests"]
    Rotate["Rotate<br/>Create new key"]
    Backup["Backup<br/>Smart cards"]

    Generate --> Store --> Use --> Rotate
    Rotate --> Generate
    Use --> Backup
```

### Hardware Security Modules (HSM)

An HSM is a dedicated, tamper-resistant hardware device. The core principle: **private keys never leave the device**.

**How HSMs protect keys:**

1. **Physical security**: [FIPS 140-2](https://csrc.nist.gov/publications/detail/fips/140/2/final) Level 3+ certified. Tamper-resistant enclosure with environmental sensors. Any breach triggers "zeroization" (key erasure).
2. **Logical security**: Minimal operating system exposes only a cryptographic API. Applications request operations ("sign this") but cannot extract keys.


**Signing workflow:**

1. vault sends transaction data to HSM with "sign" command.
2. HSM performs signing internally using protected private key.
3. HSM returns only the signature—key never exposed.


### Multi-Party Computation (MPC)

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:**

1. **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.
2. **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](/products/custody/deployment/integrate-kms/mpc/overview).

## HSM vs MPC comparison

| 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 |
| **Key management control** | Centralized control of protected key material | Distributed control that avoids constructing the aggregate secret |
| **Deployment** | Physical appliance or cloud HSM service | Cloud-native software nodes |
| **Operational environment** | Fixed physical infrastructure or controlled HSM environments | Dynamic or cloud-oriented infrastructure |
| **Accessibility** | Requires access to the HSM environment and operational controls | Software-based model with more flexible remote access |
| **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 |


## Which model should you choose?

### Choose HSM if:

- 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


### Choose MPC if:

- 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


Key Takeaway
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 [Back up, restore, and recover](/products/custody/operations-and-maintenance/backup-and-restore).

## Key derivation

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](/products/custody/accounts-and-assets/accounts/account-key-derivation-and-ledger-compatibility).