Protecting the Authority to Use Keys: Provider Security Best Practices for the Canton Network

01 - PURPOSE AND USE

Attackers do not need to steal keys if they can use the authority attached to them. In February 2025, Bybit lost about US$1.5 billion after its signers approved a manipulated transaction presented through a compromised wallet interface; the keys were never extracted, and the FBI attributed the theft to North Korean actors [1]. Binance has also reported unauthorized withdrawals with no evidence of private-key leakage [2]. Canton operators face the same class of threat, including compromised node keys and unauthorized use of credentials.

This article offers practices for operators to consider when protecting the authority attached to their keys, so that a foothold in one part of the estate is less likely to become control of signing authority. It looks beyond Canton configuration to the applications, identities, databases, hosts and recovery systems around the node.

Who This Is For

These practices are for organizations operating Canton participant or validator nodes, or signing services for them, whether on Kubernetes, virtual machines or managed services.

How to Use this Document

The practices are suggestions for how to think about these risks, not requirements. They are not a certification, audit standard or compliance test, and adopting them does not mean an environment is secure. Each practice is followed by questions that can help you assess your own position. Every environment differs, so each operator will need to weigh the practices against its own risks and seek independent advice where appropriate.

02 - THREE RISKS TO SEPARATE

• Key theft: extraction, copying or export of key material.
• Misuse of signing authority: valid keys used to sign a transaction the owner did not intend.
• Excessive application permissions: a service or identity holding more rights than its role requires.

These risks are worth assessing separately. A control that prevents key theft does not, by itself, prevent misuse of signing authority.

03 - PRACTICES TO CONSIDER

A. Operating Environment

Making it harder for a foothold to become a breach.

A1 Private, Authenticated Management

Consider keeping participant and validator Admin APIs and orchestration management off the public Internet, authenticating and authorizing internal analytics and support requests, and exposing only the client and peer services your intended audiences need. Private-network location alone is a weak basis for trust. [3]

Ask: Could an external scan find an Admin API or orchestration endpoint? Would an unauthenticated internal request to the Admin API succeed?

A2 Restricted Analytics and Databases

Consider giving reporting dedicated read-only roles or restricted views, segregated from node key and identity records; removing application DBA and owner rights and unnecessary OS-execution features; and restricting database connectivity. [4]

Ask: Could analytics credentials read key or identity records, write data, or run operating-system commands?

A3 Isolated Workloads and Egress

Consider separating sensitive nodes and signers from exposed and lower-trust services, defaulting workload ingress and egress to deny with only required dependencies allowed, and restricting unnecessary cloud-metadata access. [5]

Ask: From a lower-trust workload, can you reach a signer or the cloud-metadata endpoint in the live network, not only on paper?

A4 Narrow Identities and Secrets

Consider giving each service and environment its own minimal permissions, using short-lived credentials where supported, removing unused service-account tokens and broad secret or role access, and keeping secrets out of images, repositories and logs. [6]

Ask: When were permissions last reviewed for each identity? Would a secret scan of images, repositories and logs find anything live?

A5 Hardened Hosts and Runtimes

Consider a regular patching cadence for systems and dependencies, endpoint and runtime detection, non-root execution, and restrictions on privilege escalation, host mounts and privileged containers where applicable. [7][8]

Ask: How current is patching? Would a request to run a root or privileged container be accepted?

A6 Controlled People and Releases

Consider phishing-resistant MFA, separate administrator identities, controlled elevation and support access, independent review of every change, and pinned image digests or verified signatures before deployment. [9][5]

Ask: Could an unreviewed change or an unsigned image reach production? Can an administrator sign in without phishing-resistant MFA?

B. Authority and Recovery

Making it harder for valid access to become harmful execution.

B1 Key Custody and Use Permissions

Consider holding keys in appropriate external, non-exportable KMS or cold HSM storage, and granting permission to use a key separately from permission to administer key policy and grants. Canton external-key storage differs from envelope encryption, which decrypts database-held keys in memory, so it helps to know which mode you run. [10]

Note: in some cloud KMS services, including AWS KMS, cleanly separating permission to use a key from permission to administer it is difficult, so the separation may need deliberate design and testing.

Ask: Does any identity hold both key-use and key-administration rights? What happens if someone attempts to export key material?

B2 Exact Approval and Loss Limits

Consider binding each approval to the actual payload, destination, amount and network; rejecting changed or replayed approvals on every route; segregating tenants and asset tiers; and checking that cumulative limits hold against concurrent or split requests. [11]

Ask: Would an altered payload, a replayed approval or a split request be caught?

B3 Protected Audit and Response

Consider exporting identity, database, secret, KMS, deployment and transaction logs to independently protected storage; detecting log-feed loss, secret enumeration, rights and delegation changes and unusual outflows; routing alerts to an accountable responder; and keeping live tokens out of logs. [12]

Ask: Would a simulated event reach the right responder? Could a node administrator delete the exported logs?

B4 Containment and Clean Recovery

Consider how containment stops resource-side authority as well as credential renewal: with some identity providers, removing a grant leaves issued tokens usable until they expire. Testing separately protected, encrypted offline or immutable backups and clean rebuilds, and replacing compromised trust before an independently approved restart, also help. [13][7]

Ask: How long does an issued token keep working after revocation? When did you last complete a clean restore?

C. Canton-Specific Considerations

Areas that cannot be left to the protocol or to a signing service.

C1 Scoped Ledger API Rights

Consider scoping Ledger API command, read and administrative rights to each workload and party. Valid authentication is not the same as business approval. [14]

Ask: Could a workload token act or read for a party outside its scope?

C2 Local and External Party Authority

Consider documenting the authority model of each local and external party. Submission-signing thresholds are separate from participant-confirmation thresholds, and both matter. [15]

Ask: For each party, do you know both thresholds and who holds them?

C3 Approval at the Operator Boundary

Consider enforcing transaction limits and independent approval at a non-bypassable application or operator boundary, rather than assuming they are native to Canton or to a generic signing service. External key custody does not replace approval, and running multiple validators does not by itself show independent business-policy enforcement.

Ask: Is there any route that submits a transaction around your approval boundary?

C4 Root Namespace Key

Consider keeping the root namespace key offline with protected, tested backups, operating day to day through an intermediate delegation key, rehearsing emergency key rotation, and alerting on every topology transaction that changes party-to-participant mappings, namespace delegations or keys. Why it matters: the root namespace key can re-delegate identity, remap parties and rotate node keys. It cannot itself be rotated, because the namespace is derived from it. Loss or compromise means rebuilding the node under a new identity and re-establishing every party, delegation and customer connection.

Ask: When did you last restore the root key backup and rehearse rotation? Would a test topology change raise an alert?

C5 Daml Package Vetting

Consider vetting Daml packages like production code. A DAR upload changes what a participant will execute and confirm, so restricting upload and vetting rights, reviewing packages, pinning package IDs and alerting on unexpected changes all reduce risk.

Ask: Who can upload or vet a DAR today, and would you notice an unexpected one?

C6 Ledger API Token Validation

Consider validating Ledger API tokens against a fixed issuer, audience and signing algorithm, with short lifetimes and minimal clock skew; avoiding a single backend user with actAs rights for many parties; and treating participant-admin and user-management rights as signing-equivalent.

Ask: Would a token with the wrong issuer, audience or algorithm, or past expiry, be rejected?

C7 Canton-Native Detection and Availability

Consider monitoring ACS commitment mismatches, unexpected party allocations, sequencer or synchronizer connection changes and unexplained traffic-balance drain, alongside participant liveness and traffic top-up funding. An offline participant misses confirmations and can stall customer workflows.

Ask: Which of these conditions has an alert you have actually tested?

04 - ROLES AND RESPONSIBILITIES

• R1 Defined accountability. Consider defining the roles accountable for validating transaction intent, protecting infrastructure, suspending operations and authorizing restart, and sharing those roles with customers through role-based contacts rather than individual names.
• R2 Delegation review. Consider reviewing existing delegations and released authority separately from new signing.
• R3 Shared responsibilities. Consider documenting your responsibilities alongside those of customers and subcontractors.
• R4 Incident arrangements. Consider agreeing in advance how forensic evidence will be preserved, how notification deadlines will be met and how you will coordinate with the Global Synchronizer’s super validators.
• R5 Protection of key personnel. Consider limiting knowledge of who your signers, approvers, key-ceremony participants and infrastructure administrators are to those with a need to know; encouraging staff to limit what they share publicly about their role, the systems they administer and your key topology; and treating attempts to identify, contact or pressure these staff as security events. Why it matters: attackers who cannot reach the keys may target the people who can use them, through phishing, social engineering and coercion.

05 - EVIDENCE OF READINESS

It helps to be able to show these controls working, not only describe them.

• E1 Demonstrated controls. Consider whether you could show that a compromised analytics service cannot gain DBA or cluster privileges, that a stolen token cannot exceed party permissions or limits, and that no single administrator can weaken policy, use the keys and erase evidence.
• E2 Recorded tests. Measured revocation tests, approved-release checks and clean-restore results carry more weight when they are recorded.
• E3 Customer disclosure. Consider how you share outstanding exceptions with customers: under confidentiality, and without exposing exploitable gaps, internal topology or individual staff.
• E4 Independent testing. Independent penetration and red-team testing can confirm or challenge what internal testing finds.
• E5 Framework mapping. Mapping controls to frameworks customers already use, such as SOC 2, ISO 27001 and the CryptoCurrency Security Standard (CCSS), can make them easier to assess.

06 - EXERCISES

• X1 Tabletop exercises. Consider running realistic scenario exercises with operations, security, engineering, legal and leadership teams, for example twice a year and after major changes. Useful scenarios include a stolen signing credential, an insider approving an unusual outflow, a compromised analytics service and a failed clean restore.
• X2 Exercise follow-up. Recording decisions, timings and gaps, and giving each fix an owner and a deadline, turns an exercise into improvement. A summary shared with customers, without naming staff or describing internal topology, can demonstrate readiness.

07 - WHERE A PRACTICE DOES NOT FIT

Where a practice does not suit an environment, it helps to record why, who owns the decision, what compensating safeguards are in place and when the decision will be revisited. A WAF, MFA or private subnet alone rarely substitutes for application authorization and least privilege.

08 - GETTING STARTED

A useful first step: test one high-value, high-risk transaction path using a compromised identity in a safe environment, then note where the practices above would have helped.

09 - REFERENCES

1. FBI IC3, North Korea Responsible for $1.5 Billion Bybit Hack (PSA250226). https://www.ic3.gov/PSA/2025/PSA250226
2. Binance, security update on unauthorized withdrawals. https://www.binance.com/en-AE/support/announcement/detail/c5a8729a97ac486d963784d96c5642d7
3. NIST SP 800-207, Zero Trust Architecture. https://csrc.nist.gov/pubs/sp/800/207/final
4. OWASP Database Security Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html
5. Kubernetes Security Checklist. https://kubernetes.io/docs/concepts/security/security-checklist/
6. OWASP Secrets Management Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
7. CISA #StopRansomware Guide (hardening and recovery). https://www.cisa.gov/stopransomware/ransomware-guide
8. Kubernetes Pod Security Standards. https://kubernetes.io/docs/concepts/security/pod-security-standards/
9. CISA Cross-Sector Cybersecurity Performance Goals 2.0. https://www.cisa.gov/cybersecurity-performance-goals-2-0-cpg-2-0
10. Canton documentation, external key storage with a KMS. https://archived.docs.digitalasset.com/operate/3.4/howtos/secure/kms/mode/external_key_storage.html
11. OWASP Transaction Authorization Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html
12. OWASP Logging Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
13. Auth0, revoke API access. https://auth0.com/docs/get-started/applications/revoke-api-access
14. Canton documentation, security and authorization. https://archived.docs.digitalasset.com/overview/3.5/explanations/canton/security.html
15. Canton documentation, external parties. https://archived.docs.digitalasset.com/overview/3.5/explanations/canton/external-party.html

‍

10 - NOTICE

This document is provided for general information and discussion. It reflects MPCH’s views on security practice as of its date and is not legal, regulatory or professional advice, a certification, or an audit standard. It is not endorsed by the Canton Foundation or the Global Synchronizer’s super validators. Following it does not guarantee against compromise, and MPCH accepts no liability for decisions made in reliance on it. Each operator remains responsible for its own risk assessment and its legal and regulatory obligations.