Questions about the nature of Canton keys with an external GCP KMS + recommended best practice for key provisioning

Hi all,

I am setting up a Canton on Fabric environment using a distributed domain topology with GCP KMS and had a few questions regarding the provisioning of Canton keys via GCP KMS.

I am including a table of cryptographic keys used by Canton extracted from the docs, along with their configurability in GCP KMS for reference.

Questions:

1. Some of the keys are not configurable in KMS. I understand that files for certificate/private key pairs for TLS/mTLS are referenced in the node’s config files.
   How can the View encryption key and Session encryption key for the participant node configured?
2. Why are only some keys configurable in KMS but not all of them?
3. Can any of the KMS-configurable keys technically be identical across each node? (i.e can the same namespace key, signing key be used by 2 different participant nodes and the domain manager node?)
4. Is there a recommendation on a minimal subset of unique keys to use for each key type across Canton nodes in such that the total number of unique keys required is minimized while ensuring key security is still adequate according to best practices from a security perspective? Assume that the nodes are entirely owned by a single organization if it’s relevant.
5. Is there a different recommendation for key provisioning if some of the nodes are owned by a different organization? I.E different legal entity owning a separate Sequencer and Participant node in an entirely separate GCP network, as in the case with a federated ledger architecture

Thank you!

Hi Julius

1. The view encryption keys and the session encryption keys are generated and managed by the Canton participant nodes. They reside in memory for a short duration of time. You do not need to configure those.
2. For the above symmetric keys, generating and storing them inside a KMS would put significant load on the KMS, both in terms of number of keys and data transmitted, as those keys are used once or for a short duration of time. It also means the payload to be encrypted have to be transmitted to the network-based KMS. Instead of having TLS private keys inside a KMS and used by Canton, the alternative is to use a cloud-based load balancer that terminates TLS connections and has its private keys inside a KMS.
3. Technically its possible to share keys across nodes and use the same signing key for multiple purposes if all the nodes belong to the same organization, but there are a few caveats to call out: The risk of key compromise is getting larger as multiple nodes will be affected. The namespace signing root key cannot easily be rotated, if it is getting compromised a manual disaster recovery procedure has to be followed. Regular signing keys can be rotated through the admin console.
4. At least separate the namespace signing key from the protocol signing key to allow rotation for the frequently used protocol signing key. If you use the same namespace key across all nodes, that mans every node can manipulate the topology state of all the other nodes. If you use the same protocol signing key for all nodes (participants, mediator, sequencer) you have the risk that one nodes impersonates another one. In a nutshell, if one node/key is compromised, the entire system will be compromised.
5. You should not share signing nor encryption keys across nodes from different organizations as it breaks down the authorization and privacy guarantees of Canton.

This was very helpful.
Thank you!