Security of a CBDC (2024)

Taxonomy

Foundations

Security is built on the concepts of confidentiality, integrity and availability.1 In addition to these qualities, the CBDC system must also ensure the central bank has sole authority over issuance and redemption. A CBDC system will need to establish a layered defence strategy and make use of well-established cyber security techniques and processes. As security is a primary attribute for a CBDC, considerations for it may constrain the attributes and use cases of the chosen CBDC solution.

Confidentiality

Confidentiality translates into privacy of holdings, transactions and identities. Storage of information should be as minimal as needed to operate a CBDC system. Leakage of confidential information dramatically increases the severity of a breach. Know your customer (KYC) requirements and anti–money laundering (AML) and anti–terrorist financing (ATF) legislation (see Darbha and Arora 2020) may entail storing and linking personally identifiable information (PII) to value stores and transactions.

Integrity

Protection against counterfeiting and double-spending must be enforced in all CBDC use cases, as must the correctness and finality of all transactions. Unlike with physical bank notes, a core risk for a CBDC system is double-spending—that is, the ability to spend the same value more than once. Digital signatures can eliminate counterfeiting; but additional copy protection mechanisms are needed to avoid double-spending: these mechanisms include tamper-resistant hardware in local store-of-value devices, organizational authority in a central ledger or consensus in distributed ledger systems.

Availability

Availability, in the context of a CBDC, translates into the system’s ability to withstand large-scale cyber attacks. Disruptions, such as a distributed denial of service (DDoS)2 or a botnet3 attack, may temporarily limit or disable access to the system. Standard cyber security techniques can reinforce public end-points and connected systems to mitigate the impact of such attacks.

System components

CBDC systems can be broken down into functional sub-components for security analysis. Regardless of the nature of a specific CBDC solution and its underlying store of value, all CBDC solutions will consist of a user-facing, interactive “front-end” component that connects to a remote “back-end” system.

The front-end component can be:

• a dedicated device
• a software application running on a mobile or desktop platform
• a web interface
• a combination of the above

The back-end system may consist of at least:

• a secure, private and resilient data storage system
• a set of public-facing access points for connections to front-end components
• supporting and redundant components (e.g., firewalls, backups)

By breaking down a CBDC solution this way, the central bank can assess it for security threats at both the component level and the solution level.

Risk profile

From a security perspective, the system risk is tied to the location of the store of value. Systems where the value is stored locally on front-end components must concentrate on protecting end-user devices and applets from security threats, whereas systems where the value is stored remotely must concentrate more on the security of back-end systems. A hybrid design that joins both local and remote stores of value into a unified CBDC system may maximize usability but experience increased system risk due to a permutation of threat vectors.

Certain attributes of a CBDC are mutually exclusive depending on where the value is stored. Online payments are simple to implement with centralized systems, whereas offline transactions are straightforward to implement with dedicated devices. Privacy of transactions is another attribute to consider, as local store-of-value devices may embed transaction history. Offline forms of payment are extremely resilient in times of disaster (power failure, network failure) and crisis. These and other considerations shape the risk profile of a proposed CBDC system.

Technology options

Centralized systems

A typical centralized system is a centralized ledger that stores accounts and transactions, where account balances are derived from the current state of the ledger. Such systems may be holdings- or value-based and could be built on a centralized, distributed or federated infrastructure. The accounts could be pseudo-anonymous and transferable, where knowledge of a secret is sufficient to prove ownership.

The security profile of centralized systems is mature and well-understood. Threats are mitigated using standard IT security strategies such as dedicated links, firewalls and whitelists. Front-end components would connect to publicly available end-points that would need to be resilient against DDoS and other network attacks.

Public distributed ledger technologies

Public DLTs are poor candidates for a CBDC solution. The security profile of a public DLT cannot guarantee that a central bank would have control over currency issuance or member participation. Existing threats may be exploited by organized criminals or nation states (advanced persistent threats) to perform large-scale attacks. Such routes include:

• taking control of the majority number of nodes
• impersonating nodes to perform malicious actions
• exploiting vulnerabilities in smart contracts (design, tooling and implementation)

The Bank will continue to monitor the field of public DLTs as new innovations and emerging risks provide information on the use of permissioned DLTs within a CBDC.

Permissioned distributed ledger technologies

Permissioned DLTs are similar to centralized ledgers from a security perspective and are more amenable than public DLTs to a CBDC solution. Regardless of whether they have shared or tiered architecture, permissioned DLTs would allow a central bank to:

• control issuance (members are vetted and perform specific roles)
• govern participation based on the granularity of the controls and access management policies
• control confidentiality through a combination of cryptographic techniques, ledger tiers and private channels
• enforce non-repudiation to mitigate disputes between participants

Permissioned DLTs remain vulnerable to risks such as collusion, impersonation and rogue actors. Furthermore, node interconnections, consensus mechanisms and privacy techniques remain susceptible to the same threats as public DLT systems. Individual nodes operating at participating institutions become high-value targets, so that each node may require a layered defence strategy similar to a typical centralized system. Therefore, any cost savings from using permissioned DLTs may be minor from the perspective of infrastructure security. Limited access rights and strong governance should safeguard node interconnections and consensus mechanisms against typical DLT attacks. But these would require coordination between participating entities.

Tiered ledger systems, where holdings and transaction data may be partitioned to intermediaries, are attractive from privacy and business-model perspectives; however, deployment of a tiered DLT may degrade security. Synchronization errors between tiers lead to double-spend risk, as malicious actors may exploit network-level attacks to disrupt communications between inter-ledger nodes.

Dedicated devices

The other extreme from centralized systems are dedicated devices. Single-purpose dedicated CBDC devices that are portable and secure may store value, credentials, transaction logs and other ancillary data locally on the device. Both online and peer-to-peer CBDC transfers are supported and network access is optional, making dedicated devices highly available in times of crisis where network connectivity may be sporadic or absent.

Resistance to tampering

Devices typically rely on tamper-resistant hardware (e.g., secure elements, physically unclonable functions or the equivalent) to maintain the integrity and confidentiality of a CBDC. Breaches result in the loss of both confidentiality and integrity, as user credentials, funds and transaction data are all at risk of being compromised. In addition, constraints arising from Bank policy (e.g., limits on transaction amounts and balances) must also be protected, because modifying them could allow the misuse of CBDC funds.

The literature is still unclear on whether tamper-resistant devices can survive unbreached for long periods of offline use. To safeguard a CBDC operating offline for extended periods, additional layers of defence may be needed in the forms of:

• local authentication (PIN, password or biometrics) mechanisms to deter theft
• hard limits on balances, transaction counts and transaction values to mitigate the impact of breaches and enforce compliance with AML legislation
• on-device analytics—or more practically, periodic synchronization with a trusted verification service—to allow identification of suspicious transactions
• a continuously available (24/7/365) validation service to strengthen consumer and merchant confidence

Extended offline usage, akin to cash-like usage, is still an open problem, and the Bank is actively monitoring this research area. Tamper-resistant hardware coupled with a validation service could be a viable CBDC offering.

Smartphone integration

A CBDC could be locally stored on a smartphone, although they can be notoriously difficult to secure. This is because smartphones can run multiple concurrent applications, have open physical ports and can connect to arbitrary networks. As such, any CBDC store of value and supporting application running on a smartphone would have a complex, multi-factor threat surface. In addition, manufacturers exert control over the platform and can limit access to critical system components, including embedded secure enclaves4 and subscriber identity module (SIM) cards.

Software alone is currently insufficient to secure CBDC assets in a smartphone environment, although advances have been made in this area. Maturing technologies—such as hom*omorphic encryption,5 white box cryptography6 and virtual secure elements—are expected to improve software security in the medium to long term; it remains to be seen whether these technologies can achieve parity with existing tamper-resistant devices that are commercially available.

Hybrid systems

Centralized and distributed systems cannot intrinsically support offline transactions; a connection to the back-end is needed. Hybrid designs that combine centralized systems with dedicated devices hold great promise in satisfying the needs of many different types of end-users. Some examples of technologies that could be bolted onto centralized systems to enable offline access include:

• side-channels7
• (hashed) time-locked contracts8
• tokenization schemes (Chaum 1983; Rivest and Shamir 1997; Calhoun et al. 2019)
• commitment schemes (Pedersen 1991)
• signature schemes (Schnorr 1989)

Many of these proposed technologies are untested in production environments. Furthermore, threats would multiply due to system coupling. For example, a cryptographic flaw in a commitment scheme could leak user privacy, compromising user funds. Similarly, a device breach in a tokenization scheme could enable that device to illegitimately create but legitimately deposit CBDC funds. Security threats arising from the combination of technologies must be as well-understood as the threats individual to each technology.

Topics under consideration

Biometrics

Biometrics are a convenient authentication mechanism that can minimize friction during transactions. Biometrics simplify authentication and can lead to a deviceless CBDC. System designers must be careful incorporating biometrics into a CBDC. This is because identifiers cannot be changed once leaked and malicious entities may try to exploit biometric stores to impersonate users or commit fraud. Use of biometrics is viable if:

• biometrics are stored securely within tamper-resistant hardware, and
• interactions with back-end systems (deposits/withdrawals) rely on other authentication mechanisms (see Darbha and Arora 2020).

Cloud technologies

The use of cloud technologies to deploy a CBDC can improve availability. Databases and endpoints deployed in the cloud can be dynamically configured to scale with operational load and maximize country-wide availability. Important caveats must, however, be considered:

• CBDC solutions relying on custom hardware may prove difficult or impossible to integrate into a remote cloud platform.
• The central bank would need assurances the vendor takes suitable precautions to isolate CBDC-specific resources from other clients to prevent information leakage.
• A CBDC system could store PII data in the cloud only if the vendor guarantees that sensitive data will reside within national borders.

Large-scale attacks

An operational CBDC will draw attention from organized crime syndicates and nation states capable of hosting large-scale attacks. Primary threats include:

• persistent or sustained network attacks (DDoS, botnet) causing outage of critical CBDC services
• supply-side attacks9 against components used in infrastructure and end-user devices
• side-channel attacks10 against end-user devices and applications

Social engineering attacks against end-users are not considered a primary threat but would be an attractive avenue for organized crime. Although not a traditional attack, disinformation campaigns may discredit a new CBDC technology and could negatively affect the Bank’s perceived competence in the public eye.

DLT systems are vulnerable to DDoS attacks, as each transaction requires network interactions with other nodes. Dedicated devices could also be affected but to a lesser degree, as such attacks could temporarily disrupt onboarding services, withdrawal/deposit functions and validation services. Actors can coordinate DDoS attacks with minimal investment in time and resources if they leverage existing botnets. This contrasts with attacks that inject a back door into a tamper-resistant integrated circuit, which would require specialized knowledge, protected information on the specific device and access to the fabrication process. Furthermore, a malicious bit of hardware could be traced back to a specific fabrication step, whereas in a carefully conducted DDoS attack, the actor can maintain plausible deniability.

Even if successful large-scale attacks do not jeopardize the integrity of a CBDC, they would erode public confidence in the system. A CBDC system would therefore need continuous monitoring with periodic audits to assess resilience. In addition, the chosen solution would need to follow best practices to mitigate risk and keep components up-to-date as new vulnerabilities emerge.

Crypto-agility and quantum hardness

Crypto-agility may define the long-term operational security of a CBDC. As the computing environment and the cryptography underpinning a CBDC develop, new flaws and attacks will emerge against algorithms previously considered to be foolproof. A crypto-agile CBDC should be able to patch or upgrade the underlying primitive operations while minimizing operational downtime.

On the surface, centralized and DLT systems appear more crypto-agile. Fewer components need to be patched and these have robust connectivity. Dedicated devices pose a challenge to crypto-agility as devices may remain offline for a long time if lost or forgotten or kept as emergency savings. Devices from many vintages may be expected to inter-operate without compromising the security guarantees of the overall system. Technology solutions to manage the offline problem do exist: for example, using a non-rechargeable battery to limit the device’s lifespan or pre-programming a fixed number of transactions beyond which the device is required to reconnect. Being suitably prepared for crypto-agility will ensure the long-term viability of a CBDC system.

As quantum computing nears practicality, quantum hardness11 of cryptographic primitives will become increasingly more relevant. Existing cryptographic operations will need to be replaced by quantum-hard variants. Quantum preparedness is therefore an essential element of the overall crypto-agility plan.

Governance

Criticality

A CBDC may be classified as critical financial infrastructure. As such, it may have to comply with the National Strategy for Critical Infrastructure (Public Safety Canada 2009) and become a core component of the Bank’s financial management infrastructure. Storage and use of sensitive data for analytics may require compliance with the Privacy Act.

Central bank control

Dedicated CBDC devices would enable vertical integration by incorporating Bank-controlled tamper-resistant hardware into a generic or custom format (see Miedema et al. 2020 for details). All components of a single-purpose device (hardware, firmware, software, cryptography) would be under the central bank’s purview. As faults and attack vectors emerge, the central bank could take decisive action, either directly or through trusted channels, to mitigate the impact of a breach. The central bank could issue patches or remove or replace defective products in the marketplace, much as it currently does with bank notes. Visual and covert security features could be integrated into devices to make tampering evident and bolster public confidence.

The central bank could make portions of the device or application publicly accessible to foster innovation. Bug bounties could be issued to engage the larger technical community of ethical hackers and academics in identifying points of vulnerability within the system. The central bank could choose to allow licensed vendors to issue their own front-end devices and applications in addition to its own reference device or application, provided a suitable governance and oversight model exists and central bank exclusitivity on issuance can be upheld.

Compliance

Compliance with AML and ATF legislation may require the CBDC system to share information with other government agencies, including law enforcement. Confidentiality and integrity of a CBDC solution may be compromised if compliance introduces back-door access (e.g., “master” keys) because such a back door could be breached by unauthorized actors. The Bank needs to explore solutions that enact due process where there is a request by authorities, such as law enforcement, to reveal information. For example, multiple agencies could hold fragments of a decryption key that could only be released once a court issues a warrant.

Standards

Currently, no accepted standards for the security of a CBDC exist, although individual sub-components may be subject to existing standards (e.g., FIPS-140 [NIST 2001] and Common Criteria12 for tamper-resistant devices) and ecosystem standards are being actively explored.13 Existing security standards such as PCI-DSS,14 EMV15 and GlobalPlatform16 help secure the current payment systems. Central banks may choose to look toward implementing similar standards for a CBDC. Given the many forms a CBDC could take, and the limited consensus on the preferred approach, standards are unlikely to be established in the near future. The Bank may choose to coordinate with government agencies, other central banks and industry consortiums on standards and regulations.