- Overview
- Tutorials
- How Tos
- Download
- Install
- Configure
- Secure
- TLS API Configuration
- Configure API Authentication and Authorization with JWT
- Configure API Limits
- Set Resource Limits
- Crypto key management
- Restrict key usage
- Namespace Key Management
- Key management service (KMS) configuration
- Optimize
- Observe
- Operate
- Initializing node identity manually
- Canton Console
- Synchronizer connections
- High Availability Usage
- Manage Daml packages and archives
- Participant Node pruning
- Party Management
- Party Replication
- Decentralized party overview
- Setup an External Party
- Ledger API User Management
- Node Traffic Management
- Identity Management
- Upgrade
- Decommission
- Recover
- Troubleshoot
- Explanations
- Reference
Note
This page is a work in progress. It may contain incomplete or incorrect information.
Migrate to external key storage with a KMS¶
After creating a new Participant with the right configuration that connects to a KMS-compatible Synchronizer (e.g. running KMS or JCE with KMS-supported encryption and signing keys), you must transfer all parties, active contracts and DARs from the old Participant to the new one. The identities of the two Participants are different so you need to rewrite your contracts to refer to the new party ids. With this method, you can easily migrate your old Participant that runs an older protocol version to a new Participant with KMS enabled, that can run a more recent protocol version. Furthermore, you do not need to safe-keep the old node’s root namespace key, because your Participant namespace changes. However, for it to work a single operator must control all the contracts or all Participant operators have to agree on this rewrite.
Warning
This only works for a single operator or if all other Participant operators agree and follow the same steps.
First, you must recreate all parties of the old Participant in the new Participant, keeping the same display name, but resulting in different ids due to the new namespace key:
Secondly, you should migrate your DARs to the new Participant:
Finally, you need to transfer the active contracts of all the parties from the old Participant to the new one and rewrite the party ids mentioned in those contracts to match the new party ids. You can then connect to the new Synchronizer:
The result is a new Participant node, in a different namespace, with its keys stored and managed by a KMS connected to a Synchronizer that can communicate using the appropriate cryptographic schemes.
You need to follow the same steps if you want to migrate a Participant back to using a non-KMS provider.
Interoperability with other nodes¶
By default, Canton nodes use the jce crypto provider, which is compatible with other nodes that use external KMS providers
to store Canton private keys. If you change the default jce provider and use different cryptographic schemes,
you must ensure that it supports the same algorithms and key schemes as the KMS providers, in order to interoperate with other
KMS-enabled Canton nodes.
See this table for a description of cryptographic schemes supported by the KMS provider.