- 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
- Implementing Multi-Sig in Canton
- Additional Topics
- Managing hosting relationships
- Ledger API User Management
- Node Traffic Management
- Identity Management
- Upgrade
- Decommission
- Recover
- Troubleshoot
- Explanations
- Reference
Migrate to external key storage with a KMS with asset transfer¶
In certain situations importing private keys into a KMS is not possible or is deemed insecure, e.g. because the keys have remained unprotected until now and might be compromised. In such cases, the only alternative is to create a new Participant with different keys, a different namespace, and manually transfer all assets from the old Participant to the new. There are currently two scenarios we will explain: (1) migrating a Participant with only external parties, and (2) migrating a participant that hosts local parties.
Participant with only external parties¶
External parties are parties that exist outside of a Participant, using their own keys and their own namespace. As such, any changes to the keys or namespace of the Participant they are associated with do not affect their keys or any information in the contracts they own. Therefore, migrating these assets to a new KMS-enabled Participant is relatively straightforward:
First, start a new Participant with KMS by following this guide. Make sure you have created all the necessary keys and that the Participant starts correctly.
Next, replicate all the external parties from the old Participant to the new KMS-enabled Participant. Once the process is complete and all parties have been replicated, you can decommission the old Participant.
Participant hosting local parties¶
If a Participant hosts local parties, these parties, unlike external parties, share the same namespace and cryptographic keys as the Participant they are hosted on. Therefore, any change to the Participant’s keys will also change a local party’s identity, breaking its connection with its contracts.
The only option for migration in this case is through model-specific transfers from the old party to the new party hosted in the new Participant running a KMS. This is a complex process and heavily depends on the specific contracts and parties being migrated. If this is the only migration alternative, you will need to develop a migration plan, including the correct DAML transactions, to ensure that contracts remain under the control of the new parties hosted on the new Participant.