Security Hardening

Security best practices for validator and Super Validator nodes

Third-party Daml apps

As an SV operator, you are most welcome to review, install, and use third-party Daml apps provided you install third-party Daml apps on a validator node separate from your SV node.

Installing additional Daml apps on an SV node is not supported and may compromise its secure operations. In particular, refrain from manually uploading additional .dar files to your SV node or manually connecting it to third-party synchronizers.

If you want to run third-party applications, deploy a separate validator node for that purpose. Keep your SV node dedicated to its core functions.

External KMS for managing participant keys

By default, Canton participants use cryptographic keys that are generated by the participant itself and stored in the regular database used by the participant. To improve key security, participants can be configured to use an external Key Management System (KMS) to generate and store keys. Consult the official Canton documentation on KMS support for additional details and a list of supported KMS providers. Participants deployed as part of a Splice deployment support the External Key Storage mode of KMS usage.

Official support for KMS-based operation of sequencers and mediators that are part of an SV deployment is planned for a future release.

General configuration

Refer to the Canton documentation on configuring KMS support for determining the right configuration options for your desired KMS provider.

When configuring KMS through Helm values:

• Values in the kms section of the participant Helm chart are implicitly mapped to the Canton participant crypto.kms config. All configuration keys supported by Canton are supported, not only those shown in the examples. Key names in camelCase are automatically converted to kebab-case.
• Use .additionalEnvVars, .extraVolumeMounts, and .extraVolumes fields of the Splice participant Helm chart to set extra environment variables and mount files for KMS authentication.
• Make sure your KMS configuration is always included in the values files you pass to helm install participant ... or helm upgrade participant ....

Google Cloud KMS

Refer to the Canton documentation for a list of supported configuration options and their meaning, as well as for instructions on configuring authentication to the KMS. Splice participants support the External Key Storage mode, so the authentication credentials you supply must correspond to a GCP service account with the following IAM permissions:

• cloudkms.cryptoKeyVersions.create
• cloudkms.cryptoKeyVersions.useToDecrypt
• cloudkms.cryptoKeyVersions.useToSign
• cloudkms.cryptoKeyVersions.get
• cloudkms.cryptoKeyVersions.viewPublicKey

You can grant the Cloud KMS Admin and Cloud KMS Crypto Operator roles to the validator KMS service account.

A mock GCP KMS configuration is available in apps/app/src/pack/examples/sv-helm/kms-participant-gcp-values.yaml.

Amazon Web Services KMS

Refer to the Canton documentation for a list of supported configuration options and their meaning, as well as for instructions on configuring authentication to the KMS. Splice participants support the External Key Storage mode, so the authentication credentials you supply must correspond to an entity with the following IAM permissions:

• kms:CreateKey
• kms:TagResource
• kms:Decrypt
• kms:Sign
• kms:DescribeKey
• kms:GetPublicKey

A mock AWS KMS configuration is available in apps/app/src/pack/examples/sv-helm/kms-participant-aws-values.yaml.

Migrating from software keys to KMS

It is not supported to migrate an existing participant from “non-KMS-based” to “KMS-based” operation, or to migrate from one KMS provider to another. The main reason is that a participant’s root namespace key cannot be rotated, and importing it from a potentially unsafe location into a KMS would diminish the security gain of using the KMS. Some KMS providers do not support importing existing keys at all and can only manage keys generated by the KMS itself.

For SV nodes, the recommended approach to migrate to KMS is:

1. Set up a fresh SV from scratch with the desired KMS configuration. Synchronize with the other SV operators to onboard it with weight 0.
2. Synchronize with the other SV operators to move your SV weight to the new SV, setting the weight of the older SV to 0.
3. Transfer all relevant assets from the older SV to a validator or the new KMS-enabled SV.
4. Synchronize with the other SV operators to offboard the older SV.
5. Retire the older SV.

For validator nodes, the approach is simpler:

1. Set up a fresh validator from scratch with the desired KMS configuration.
2. Transfer all relevant assets from the existing non-KMS validator to the new KMS-enabled validator.
3. Retire the non-KMS validator.

CometBFT governance key with KMS

When using an external KMS for participant keys, you must also manage the CometBFT governance key externally. The default method of managing this key through the participant is not supported with KMS-enabled participants.

Generate a CometBFT governance key:

# Generate the private key
openssl genpkey -algorithm ed25519 -out cometbft-governance-keys.pem

# Extract and encode the keys
public_key_base64=$(openssl pkey -in cometbft-governance-keys.pem -pubout -outform DER | tail -c 32 | base64 | tr -d "\n")
private_key_base64=$(openssl pkey -in cometbft-governance-keys.pem -outform DER | tail -c 32 | base64 | tr -d "\n")

echo "{"
echo "  \"publicKey\": \"$public_key_base64\","
echo "  \"privateKey\": \"$private_key_base64\""
echo "}"

# Clean up
rm cometbft-governance-keys.pem

Save the output to a file (e.g., cometbft-governance-keys.json) and create a Kubernetes secret:

kubectl create secret --namespace sv generic splice-app-sv-cometbft-governance-key \
  --from-literal=publicKey="$(jq -r .public cometbft-governance-keys.json)" \
  --from-literal=privateKey="$(jq -r .private cometbft-governance-keys.json)"

Then set cometBFT.externalGovernanceKey to true in the splice-sv-node Helm chart.

General security recommendations

• Back up node identities to a secure location such as a secret manager. Identity backups contain private keys for your participant, sequencer, and mediator.
• Rotate credentials and tokens regularly.
• Restrict network access to your SV node’s admin endpoints.
• Monitor participant logs for ACS_COMMITMENT_MISMATCH warnings, which may indicate integrity issues.