# Key management

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

## Types of keys

Ripple Custody works with the following three types of cryptographic keys:

- User keys
- Governance engine and vault keys
- Blockchain account keys


Governance engine, vault, and blockchain keys are generated and stored securely by the custodian, using their preferred key management system (KMS).

The main properties of the three types of keys are as follows:

| Property | User keys | Governance engine and vault keys | Blockchain keys |
|  --- | --- | --- | --- |
| **Role** | Sign user decisions | Sign application data | Sign transactions |
| **Algorithm** | ECDSA secp256r1 | EdDSA Ed25519 | Blockchain-specific |
| **Key length** | 256-bit | 256-bit | Blockchain-specific |
| **Storage** | Mobile phone 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 governance engine and vault components | On-chain address sweeping |
| **Revocation** | Lock a user | Redeploy governance engine and vault components | Funds transferable to a new account |


### User keys

All users (human or machine) that require read or write access to the Ripple Custody platform are associated with a key. User keys are used to enforce governance of data updates in Ripple Custody, as follows:

- A user private key is stored externally and is never communicated to Ripple Custody. The private key is used to authenticate user requests to Ripple Custody, such as submission of a signed request to update an entity, or submission of a signed approval or rejection of an entity update request.
- The public key corresponding to the user private key is stored in the database and used by the governance engine to verify the signature of all update requests submitted by the user.


A valid public key is in DER format with Base64 encoding, as in the following example:


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

User public keys are registered within the trusted state of Ripple Custody to prevent any risk of identity tampering on the server side. Registering a user public key is subject to a dedicated user creation intent, such as for any other critical state mutation.

Users are responsible for their own keys. They can safely store user keys, sign intent submissions, and submit approvals and rejections of intents in the Ripple Custody mobile application or Windows desktop app. The mobile application stores keys in the device secure enclave, which is a requirement for the app to function properly. For users of the Windows desktop app, the 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, you can choose any other type of KMS.

User keys are generated by the user during system setup or registration.

For more information about user key generation, see [Register](/products/custody/v1.34/api/get-started/register) in the Ripple Custody API guide.

### Governance engine and vault keys

The governance engine and vault use keys to authenticate messages that pass between them and demonstrate authenticity to components external to Ripple Custody.

- The governance engine uses its private key to sign the root of the Merkle tree, thus securing the state of the system. It also uses a private key to authenticate messages dedicated to external components.
- The vault uses its private key to authenticate payloads dedicated to external components.


Governance engine keys and vault keys are generated during deployment.

### Blockchain keys

Ripple Custody uses blockchain keys to sign the transactions of a given account. The signature algorithm they use can vary according to the requirements of the underlying ledger protocols.

During account creation, Ripple Custody generates blockchain keys from the master seed using different strategies, depending on the KMS. Ripple Custody supports the following strategies:

- Deterministic key derivation strategies, such as BIP32 and SLIP10, in both hard and soft derivations: With hard derivation, each new derivation (for example, for the generation of a new address) needs access to the master seed in the vault, while soft derivation does not.
- Random key generation strategies: The key material for the new wallet is not derived at all from the seed, but generated randomly.


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

For more information about key derivation for accounts and ledgers, see [Key derivation](/products/custody/v1.34/concepts/key-management).

## Key management systems (KMSs)

Ripple Custody works with two main types of KMS:

- *Hardware security modules* (HSM): A secure environment for storage and use of sensitive data, such as cryptographic keys.
- *Multi-party computation* (MPC) systems: A protocol in which storage and use of cryptographic keys is distributed across multiple nodes. Each node manages its own private data in the form of a *key shard*. When a cryptographic signature is required, multiple nodes to work together to generate the signature.


For more information about supported key management systems in Ripple Custody, see [Initialize and connect a KMS](/products/custody/v1.34/get-started/deployment/deploy-kms).

The following table compares the two KMS types supported by Ripple Custody:

| Feature | HSM | MPC |
|  --- | --- | --- |
| Security | Potential vulnerability due to single point of failure if no replication. | Distributed nature, removing single point of failure. This distribution of sensitive data and computation into less sensitive pieces permits the use of a slightly less secure environment than an HSM. Requires more complex coordination. |
| Accessibility | Requires physical access, offers strong control but less flexibility. | Software-based, offers high flexibility and remote access. |
| Scalability/speed | Can handle very high number of workloads. | The more parties required to sign, the slower the MPC gets. |
| Cost | High up-front and maintenance cost. | Low up-front cost with ongoing cost of multiple party management. |
| Flexibility | Low | High |
| Key management | Centralized, firm control but potential vulnerability. | Decentralized, offers robust protection for the aggregate secret by avoiding its construction. |
| Environment | Good for environments with fixed physical infrastructure. | Good for dynamic environments and cloud infrastructures. |