How to Design a Public Key Infrastructure for a Central Bank Digital

Currency

Makan Raﬁee

and Lars Hupel

2 a

secunet Security Networks AG, Kurf

urstenstr. 58, 45138 Essen, Germany

Giesecke+Devrient GmbH, Prinzregentenstr. 161, 81677 M

unchen, Germany

ﬁ

Keywords:

Central Bank Digital Currency, CBDC, Public Key Infrastructure, PKI.

Abstract:

Central Bank Digital Currency (CBDC) is a new form of money, issued by a country’s or region’s central

bank, that can be used for a variety of payment scenarios. Depending on its concrete implementation, there are

many participants in a production CBDC ecosystem, including the central bank, commercial banks, merchants,

individuals, and wallet providers. There is a need for robust and scalable Public Key Infrastructure (PKI) for

CBDC to ensure the continued trust of all entities in the system. This paper discusses the criteria that should

ﬂow into the design of a PKI and proposes a certiﬁcate hierarchy, together with a rollover concept ensuring

continuous operation of the system. We further consider several peculiarities, such as the circulation of ofﬂine-

capable hardware wallets.

1 INTRODUCTION

Central Bank Digital Currency (CBDC) is a digital

means of payment, issued by a country’s (or region’s)

central bank, denominated in the national currency.

According to the latest results of the annual CBDC

survey conducted by the Bank for International Settle-

ments, 94% of the respondents say they are working

on digital currency (Di Iorio et al., 2024). As of 2025,

many major central banks are pushing forward with

CBDC, including the European Central Bank with

their Digital Euro project.

While many of the projects are not yet in produc-

tion stage, there is an emerging view that a full launch

encompasses at least the following criteria (Hupel and

Raﬁee, 2024):

• continuous and uninterrupted availability for an

indeﬁnite amount of time, i.e. no unannounced

shutdown,

• real legal tender that can always be exchanged at

face value with cash and deposit money,

• no system resets, i.e. holdings will remain valid,

• upgrade and maintenance work requires little to

no intervention from users, except for long-term

hardware upgrades, similar to the 2-5 year cycle

of bank cards and smartphones.

https://orcid.org/0000-0002-8442-856X

Because CBDC is public digital infrastructure, it

needs to satisfy the highest resilience and security

standards, at least on par with national settlement and

payment systems.

But there are also additional requirements unique

to CBDC: As opposed to traditional banking infras-

tructure, a CBDC would operate in 24/7 mode and has

thus very little room for maintenance and/or down-

time.

Public Key Infrastructure The backbone of any

digital currency is the correct use of cryptographic

materials and choosing appropriate security levels.

This includes selecting the right algorithms for en-

cryption, key exchange, digital signatures, and hash

functions. More succinctly: getting the cryptographic

primitives right.

But just picking the right algorithm is not enough

to build trust in the whole system. Key material needs

to be uniquely and veriﬁably connected to all enti-

ties. Many entities need to be authenticated before

payments can happen, for example:

• wallets need to authenticate each other;

• the central bank want to ensure that only autho-

rized wallets are used to hold currency; and

• commercial banks need to conﬁrm that the coun-

terparties they are exchanging money with are

genuinely who they claim to be.

696

Raﬁee, M. and Hupel, L.

How to Design a Public Key Infrastructure for a Central Bank Digital Currency.

DOI: 10.5220/0013562300003979

In Proceedings of the 22nd International Conference on Security and Cryptography (SECRYPT 2025), pages 696-704

ISBN: 978-989-758-760-3; ISSN: 2184-7711

Public Key Infrastructure (PKI) is the solution to

these problems. By mapping public key materials to

abstract entities in a certiﬁcate, participants in the net-

work can always rely on the authenticity of their com-

munication partners. This requires a root of trust—a

central authority—from which all certiﬁcates are de-

rived. In the case of CBDC, this would be the central

bank.

Trusting these derived certiﬁcates is a result of

users trusting the central bank. For that, the central

bank must have proper processes in place to ensure

a secure certiﬁcate life cycle. This entails handling

Certiﬁcate Signing Requests (CSR), rights and roles,

and organisational procedures. RFC 3647 (Ford et al.,

2003) provides a good overview of key considerations

for designing a PKI.

Focusing on CBDC, this paper explores PKI de-

sign decisions, authenticated entities requiring certiﬁ-

cates, and how a seamless certiﬁcate rollover can be

handled.

2 RELATED WORK

The literature has already acknowledged the need

for robust and scalable Public Key Infrastructure for

CBDC and other digital asset systems.

Several publications (Chu et al., 2022; Christodor-

escu et al., 2020; Zhang, 2024; Yang et al., 2022)

highlight the use of PKI for ofﬂine payments. The

core idea is that wallets carry certiﬁcates signed by an

authority, e.g. the central bank. These can be used for

mutual authentication between a pair of wallets before

or during a transaction. This establishes trust in an

ofﬂine scenario. Illegitimate wallets are consequently

excluded from the system and cannot inject counter-

feit money. As Chu et al. (2022) summarize, a PKI

“allows safe transactions even though the certiﬁcate

authority is ofﬂine, since a certiﬁcate states whether

the counterpart is a trusted user”.

Takaragi et al. (2023) investigate the role PKI

plays for Know-your-customer (KYC) checks. The

authors develop a privacy-enhanced PKI by which a

“ﬁnancial institution veriﬁes the identity of a prospec-

tive customer,” based on the national ID, while simul-

taneously protecting the customer’s personal informa-

tion.

According to Han et al. (2019), a PKI is a core

ingredient for the regulatory layer of a CBDC. Their

goal is “the supervision of objects such as banks and

third parties in network layer and users and transac-

tion in user layer.” Similarly, Zhang (2024) writes

that the role of PKI is “maintaining trust within the

network of entities authorized to operate the CBDC

system”.

Our previous research (Hupel and Raﬁee, 2024)

identiﬁes PKI as an instrumental part of any CBDC

ecosystem. In particular, we have evaluated the vari-

ous cryptographic keys and their algorithms involved,

to understand how they are affected by the migra-

tion to post-quantum cryptography. This is echoed

by Zhang, who explains that “the PKI infrastruc-

ture adopted by the central bank should be quantum

ready” (Zhang, 2024).

In the related ﬁeld of Distributed Ledger Technol-

ogy (DLT), there is literature outlining the use of PKI

for operating permissioned ledgers, i.e., where access

control limits the participation in the system. For ex-

ample, Hyperledger Fabric, uses PKI for “signature

generation, veriﬁcation, and authentication” (Camp-

bell, 2019). Pal et al. (2021) survey some PKI strate-

gies for major blockchain protocols.

The ISO has published Technical Report (TR)

24374, entitled “Security information for PKI in

blockchain and DLT implementations”. It discusses

“the impact of different types of key management pro-

cesses that are required for PKI implementations in

Blockchain and DLT projects” (International Organi-

zation for Standardization, 2023).

3 PARTICIPANTS IN A CBDC

ECOSYSTEM

For this paper, we assume a CBDC system with the

following characteristics:

• a two-tier distribution model, i.e., the central

bank manages the supply of money and commer-

cial banks are responsible for distributing money

to individuals and businesses;

• unbanked individuals are included, i.e., people

without a formal bank account can get access to

CBDC, with notable groups being rural citizens

without access to a bank branch, children, and

tourists;

• a wide spectrum of wallets are available, allow-

ing for both online and ofﬂine payments, espe-

cially hardware wallets embodied e.g. as smart-

cards;

• at least the payment scenarios C2B/B2C

(customer-to-business/business-to-customer) and

P2P (person-to-person) are supported;

Project Aurum (BIS Innovation Hub, 2022) distin-

guishes some further subtypes, but they are irrelevant for

this paper

How to Design a Public Key Infrastructure for a Central Bank Digital Currency

697

Central bank

Bank A Bank B Bank C

CBDC verification

Interbank

settlement

Top-up &

withdrawal

Bank A customer

Unbanked citizen

P2P transfer

Bank C customer

Bank C ATM

Online payment

initiation

Merchant

POS payment

initiation

Backend

communication

CBDC verification

Card manufacturing

Wallet personalization

Figure 1: Participants and communication channels in a CBDC ecosystem.

• a central bank ledger validates transactions,

with the concrete operational model (DLT/non-

DLT) abstracted for this paper.

Figure 1 shows the participants and communication

channels.

The assumptions speciﬁed above give rise to a

CBDC system that works similarly to cash. As the

Hong Kong Monetary Authority points out, a CBDC

is “best designed as part of a two-tier system, with

an appropriate division of labour between the central

bank and private sector intermediaries for the distribu-

tion and circulation of CBDC” (Hong Kong Monetary

Authority, 2021).

This section spells out the participants in the sys-

tem and what their roles and responsibilities are: (1)

the central bank, (2) ﬁnancial service providers, and

(3) individuals and businesses.

As noted above, wallets can come in different

form factors, including hardware wallets such as

smartcards. They are typically manufactured by a

dedicated entity (see also Figure 1). But we set aside

card manufacturing for now and will revisit this later

in §4.1.2.

To keep it as simple as possible, we exclude a

treatment of risk management, including fraud detec-

tion and investigation. This may require additional

participants and communication channels.

Central Bank. The central bank focuses on “pro-

viding the core, foundational infrastructure of a

CBDC, guaranteeing the stability of its value and

overseeing the system’s security” (Hong Kong Mone-

tary Authority, 2021). This includes, but is not limited

to:

• manage the monetary supply through minting and

burning of CBDC;

• operate the central bank ledger and validating

transactions (Central Register);

• distribute CBDC to commercial banks;

• set rules and regulations for participants;

• operate the root certiﬁcate authority of the PKI.

To a limited extent, the central bank could also pro-

vide CBDC wallets, for example to allow commercial

banks the 1:1 exchange of central bank reserves for

CBDC.

The central bank provides various communication

channels. Any participant can query the Central Reg-

ister to validate CBDC. It must also communicate

with FSPs.

Financial Service Providers. Commercial banks,

or more broadly, ﬁnancial service providers (FSPs),

are responsible “to provide retail services to cus-

tomers on a competitive basis, and leverage their net-

work effects to innovate in business and service mod-

els” (Hong Kong Monetary Authority, 2021). Just like

today, banks are the ﬁrst point of contact for individu-

als and businesses. Their services include, but are not

limited to:

• perform user onboarding, e.g. by checking their

identity, to comply with Know-your-customer

(KYC) regulation;

• open and operate custodial customer wallets, and

develop smartphone apps for customers to access

their funds;

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

698

• issue hardware devices to customers and (poten-

tially) unbanked individuals, to allow for ofﬂine

payments and to enable unbanked people to par-

ticipate in the CBDC ecosystem;

• distribute CBDC to their customers by provid-

ing exchange between deposit money, cash and

CBDC;

• value-add services such as insurances.

FSPs communicate directly with their customers,

with the central bank, and with other FSPs. They also

provide communication channels to initiate and exe-

cute payments at the point of sale, as well as ATM

operations, which may be proxied through existing

systems and is therefore not speciﬁc to CBDC.

Note that some jurisdictions are considering the

central bank to also act as a retail service provider, for

example to aid ﬁnancial inclusion. In other jurisdic-

tions, non-banks (such as post ofﬁces) are thought to

take over this role.

Individuals and Businesses. Finally, the users of

the system: individuals and businesses are exchang-

ing CBDC with each other and/or use CBDC to pay

for goods and services.

While details differ across jurisdictions, the most

typical representatives of this group are local residents

and merchants (both physical and online). Subject

to various limits, they can obtain CBDC wallets and

transact with each other. As opposed to traditional

payment systems, CBDC payments are symmetric: a

merchant’s wallet will differ from an individual’s wal-

let only in conﬁguration.

Depending on the precise payment scenario, wal-

lets will use different communication channels for ex-

ecuting payments. In ofﬂine situations, it will typi-

cally be a connection based on proximity protocols

such as NFC or Bluetooth, establishing direct peer-

to-peer communication. But there can also be online

scenarios, where a user instructs their FSP to execute

a payment.

4 PKI CONCEPT

Just like cash, the trust in CBDC derives from the

trust of participants in the central bank. This trust is

the foundation of the secure operation of any CBDC

ecosystem. As outlined above, such an ecosystem re-

quires a number of entities.

These entities have a wide range of requirements.

For example, some entities are operated by the cen-

tral bank itself, while others are completely outside

Root CA

Central Bank

Financial CAOperational CA Hardware CA

Manufacturer

CA 1

Manufacturer

CA 2

FSP 1 FSP 2 FSP 3

Minting Timestamp Register Auxiliary

services

Figure 2: Proposed PKI hierarchy.

its control. This section explains the certiﬁcate hier-

archy, as well as technical and procedural concerns.

4.1 Hierarchy

The central bank is the trust anchor of the whole sys-

tem, but cannot perform all necessary processes re-

quired for a trustworthy system. It must, therefore,

delegate trust towards other entities, such as ﬁnan-

cial service providers or manufacturers. That notwith-

standing, the central bank still holds full responsibil-

ity for their correct operation, and therefore operates

the Root CA.

Therefore, the central bank imposes requirements

to these thirds parties and enforces compliance. Ide-

ally, the processes carried out by third parties shall be

audited by the central bank.

The requirements in this policy could be pub-

lished. This enables participants to understand how

the PKI operates and establishes a factual basis for

their trust.

Certiﬁcates with similar security levels should be

clustered under the same Certiﬁcate Authority (CA),

since certiﬁcates issued by the CA fulﬁll the same re-

quirements towards issuance, revocation, delivery and

further relevant processes. We cluster certiﬁcates into

three categories (Figure 2).

4.1.1 FSP Certiﬁcates

A ﬁnancial service provider may only participate in

the CBDC ecosystem after the central bank’s ap-

proval. After onboarding, they would be equipped

with a certiﬁcate that allows them to prove their iden-

tity to customers and other FSPs.

FSPs are authorized to open and operate wallets

for customers. The FSPs will typically also have

custody of private key material of their customers.

Whenever a payment across banks is made, the par-

ties need to make sure that their respective counter-

party holds a valid CBDC wallet.

From the user perspective, being a customer of an

FSP already assumes (implicit) trust towards the FSP.

How to Design a Public Key Infrastructure for a Central Bank Digital Currency

699

Therefore, FSPs are already trusted to route payments

to the desired receiver wallet, and no additional secu-

rity gain can be achieved by equipping each online

wallet with their own key material to authenticate the

wallet. The necessary trust is already achieved by val-

idating the FSP certiﬁcate, and let the FSP take care

of routing and payment ﬂows.

This way, there are trust relationships between a

user and their bank, as well as between a bank and the

central bank, but not between different banks.

4.1.2 Smartcard Certiﬁcates

Similar to credit cards, the FSPs are responsible for

distributing hardware wallets, such as smartcards, to

their customers.

In a CBDC ecosystem, peer-to-peer payments be-

tween wallets are allowed. This means that not all

payments are routed through an intermediary. As a

consequence, smartcards must be able to authenticate

each other directly, which is especially important for

ofﬂine payments.

The central bank bears ultimate responsibility that

all smartcards are trustworthy. Since central banks

typically do not manufacture those themselves, they

will delegate this process to trusted smartcard manu-

facturers.

To guarantee ﬂexibility and limit dependence on a

singular smartcard manufacturer, multiple manufac-

turers should be supported.

Hence, the central bank should:

• select a number of trustworthy smartcard manu-

facturers;

• issue and provide each smartcard manufacturer

with an individual certiﬁcate;

• deliver the Root CA certiﬁcate securely to those

manufacturers;

• ensure that the manufacturers comply with the

rules and process requirements, which should

happen contractually and with the help of a Certi-

ﬁcation Practice Statement (Ford et al., 2003);

• perform on-site audits on the facilities to ensure

the manufacturers comply with the requirements

(optional).

Parts of this could also be delegated through FSPs,

who may want to follow their own procurement pro-

cedures.

4.1.3 Operational Certiﬁcates

The tasks that are performed by the central bank

might be performed by different entities within the

central bank itself. Naturally, this implies that mul-

tiple entities within the central bank need to hold in-

dividual certiﬁcates, for example:

Minting. A system authorized to mint new money in

a secure environment. There may also be person-

alized certiﬁcates for one or more central bank

employees carrying private key material in a se-

cure device.

Central Register. A ledger tracking authenticity of

money, thereby conﬁrming the validity of digi-

tal money; this system itself might be hierarchical

(depending on choice of DLT or not).

Timestamp Service. A backend system that pro-

vides signed timestamps based on a trusted clock.

The exact entities might differ depending on the

broader design decisions for the CBDC.

4.2 Certiﬁcate Format

The state-of-the-art certiﬁcate format used in most in-

dustry use cases is X.509 (Boeyen et al., 2008). In ad-

dition to subject identiﬁer and public key, it provides

many more certiﬁcate ﬁelds.

The X.509 standard has some drawbacks in en-

vironments with limited computation power, such as

IoT devices or smartcards. Any auxiliary data and

certiﬁcate ﬁelds slow down payments.

The obvious choice for a stripped down X.509 cer-

tiﬁcate format, speciﬁcally designed for smartcards,

are Card Veriﬁable (CV) certiﬁcates (International Or-

ganization for Standardization, 2021). They enable

smartcards to perform certiﬁcate operations with lim-

ited resources and power. In contrast to X.509, CV

certiﬁcates are much smaller and do not contain ir-

relevant information, thereby accelerating transaction

processing.

4.3 Revocation

In any PKI, handling compromised certiﬁcates is cru-

cial to ensure prompt invalidation and maintaining the

trust and security of the system. There are two ways

for this:

1. Technical handling of compromised certiﬁcates

(Revocation). The CA can revoke certiﬁcates in

its system and provide this information to the re-

lying partiesin two ways:

(a) Certiﬁcate Revocation Lists (CRLs) are pub-

licly available lists of revoked (but not expired)

certiﬁcates. Whenever a certiﬁcate is validated,

its revocation status can be looked up in the

CRL. CRLs are issued (signed) by the respon-

sible CA (or a dedicated CRL Signer).

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

700

(b) Online Certiﬁcate Status Protocol (OCSP) al-

lows the validating entity of the certiﬁcate

to request the revocation status at a publicly

available OCSP responder, which answers with

good, revoked, or unknown.

2. Organizational handling of compromised certiﬁ-

cates. Certiﬁcates are not technically revoked,

but the validating entities are manually informed

about compromised certiﬁcates.

All of these approaches come with various problems.

CRLs have to be regularly updated, and revocation

information may not be up-to-date at the time of the

revocation check.

OCSP comes with a lot of additional trafﬁc and,

more importantly, with a signiﬁcant privacy risk:

OCSP requests are not encrypted and intercepting this

trafﬁc would reveal the certiﬁcates to be validated.

This would clearly reveal communication metadata,

weakening privacy.

Organizational handling of compromised certiﬁ-

cates is difﬁcult when the relying parties are numer-

ous and unknown.

Payments demand high transaction throughput

and low latency. Any additional data transfer within

a transaction—including revocation status checks—

must be carefully considered. Both CRL and OCSP

lead to slower transactions.

Since the number of certiﬁcates in the PKI fairly

limited, the organizational handling of compromised

certiﬁcates should be considered instead. The rely-

ing parties are mostly controlled by the central bank,

which means that in case of a malicious FSP, the cen-

tral bank can simply unplug them from the system.

The same is applicable to compromised operational

certiﬁcates.

In ofﬂine payment scenarios, CRL and OCSP are

not applicable for the lack of internet connection.

OCSP stapling as an alternative method can be con-

sidered, even though they also increase the trafﬁc and

lead to longer transaction times.

5 CERTIFICATE ROLLOVER

In order to guarantee smooth transition between Root

CA certiﬁcates—and therefore uninterrupted func-

tionality of the PKI—rollover procedures are needed.

For online entities, this is relatively easy, since certiﬁ-

cates can be transmitted online for real-time updates.

This is applicable to every entity in the PKI except for

the smartcards.

Smartcards are ofﬂine entities which may, after

production, rarely connect to an online service. This

Old Root CA

New Root CA

Phase 1 Phase 2 Phase 3

Figure 3: Conceptual CA rollover (standard case).

gives rise to some additional complication that go be-

yond normal rollover procedures.

5.1 Standard Rollover

Normally, a certiﬁcate rollover consists of three

phases (see Figure 3). In the ﬁrst phase, only the old

Root CA certiﬁcate is used to issue certiﬁcates and

verify certiﬁcates based on the old Root CA certiﬁ-

cate.

At the beginning of the second phase, a new Root

CA certiﬁcate is created. New certiﬁcates in this pe-

riod will be issued with the new Root CA certiﬁcate.

Veriﬁcation of certiﬁcates based of the old Root CA

certiﬁcate will be veriﬁed with the old Root CA cer-

tiﬁcate, while certiﬁcates based on the new Root CA

certiﬁcate will be veriﬁed with the new Root CA cer-

tiﬁcate.

Finally, only the new Root CA certiﬁcate is used

to issue new certiﬁcates as well as verifying certiﬁ-

cates. This completes the rollover.

5.2 CBDC and Hardware Wallet

Speciﬁcs

Due to the nature of hardware wallets, certain compli-

cations need to be handled.

Pinning. In order to guarantee functionality and se-

curity over their lifetime, certiﬁcates should be pinned

in smartcards. These pins could be especially pro-

tected, e.g. through hardcoding, to prevent tampering.

For the smartcards, the pinned certiﬁcates are:

• Root CA certiﬁcate

• Timestamp Service certiﬁcate

• Central Register certiﬁcate

In addition to the above-mentioned certiﬁcates, the

smartcard holds its own certiﬁcate chain:

• End-Entity (EE) (wallet) certiﬁcate

• Manufacturer CA certiﬁcate

• Hardware CA certiﬁcate

How to Design a Public Key Infrastructure for a Central Bank Digital Currency

701

Root CA Ramp up. The Root CA certiﬁcate is the

trust anchor on which the PKI builds. When the Root

CA certiﬁcate expires, every certiﬁcate based on that

Root CA certiﬁcate loses its validity. For hardware

wallets thay may be ofﬂine for extended amounts of

time, a new Root CA certiﬁcate has to be created in

advanced to it becoming active. Therefore, as com-

pared to the standard rollover procedure (Figure 3),

we need to add an initial ramp up phase: in this phase,

the new Root CA certiﬁcate is issued, but not active

(i.e., does not sign any certiﬁcates). Still, it would be

installed alongside the old Root CA certiﬁcates in the

smartcards.

Smartcard Manufacturer. The certiﬁcate a manu-

facturer receives has a limited validity time. But, upon

receiving a certiﬁcate, it should be able to manufac-

ture smartcards over a period of timem independent

of the issuing date. PKI rollover should be planed

such that no change in the certiﬁcate chain should be

needed after the initial phase, where all necessary cer-

tiﬁcates for production have been gathered. The va-

lidity of the smartcard manufacturer certiﬁcate has to

be veriﬁable as long as there are smartcards in circu-

lation based on that certiﬁcate.

Smartcard Validity Period. Smartcards that leave

the manufacturer should always have the same life-

time, independent of their manufacturing date. There-

fore, the complete certiﬁcate chain must be veriﬁable

as long as those smartcards are circulating. This is

true not only for online services, but also for mutual

authentication.

5.3 Solution Requirements

We deﬁne the validity period of a smartcard certiﬁ-

cate, denoted as 1u, as the base unit in our concept.

This can be deﬁned by the central bank and will typ-

ically be a few years. All other validity periods are

derived from this unit.

Following the speciﬁcs for CBDC explained in the

previous section, we consider the following require-

ments:

1. All necessary certiﬁcates to conduct payments

must be present on the smartcard for ofﬂine us-

age.

2. Root CA, Central Register and Timestamp Ser-

vice certiﬁcates must be pinned on the smartcard.

3. A smartcard must be usable for its entire lifetime

without updating pinned certiﬁcates.

4. Smartcard manufacturer certiﬁcates must be able

to be issued at any time.

1st Generation

Root CA

Active Passive

2nd Generation

Root CA

Ramp Up Active Passive

3rd Generation

Root CA

Ramp Up Active

...

Figure 4: Conceptual CA rollover (CBDC case with ramp

up phase).

5. Smartcard manufacturers should be able to man-

ufacture smartcards for a deﬁned amount of time

without updating their facilities with new certiﬁ-

cates after receiving all necessary certiﬁcates from

the central bank.

This results in the necessity of a ramp up phase for

certain certiﬁcates (Figure 4. The details are ex-

plained per certiﬁcate in the following sections.

5.4 Hardware CA Strand

Manufacturer CA. The smartcard manufacturer

must be able to issue certiﬁcates at any point in time

during its active phase.

The validity period of a the CA certiﬁcate is de-

pendent on two factors. The active time is the period

during which smartcards are manufactured based on

a certain Root CA certiﬁcate. The passive time is the

subsequent validity period of a smartcard, since func-

tionality has to be guaranteed after manufacturing.

Therefore, the active and passive phases of the CA

must each be at least as long as the smartcard validity

period:

Active(Manufacturer CA) ≥ u

Passive(Manufacturer CA) ≥ u

Hardware CA. The same reasoning can be applied

to Hardware CA certiﬁcates, since they also must be

able to issue Manufacturer CA certiﬁcates at any point

in time. Since their validity period is at least 2u, with

each of the phases being at least u, we get:

Active(Hardware CA) ≥ 2u

Passive(Hardware CA) ≥ 2u

5.5 Operational CA Strand

It must be ensured that all circulating smartcards pin

the currently used Central Register certiﬁcate. There-

fore, the ramp up phase of the Central Register cer-

tiﬁcate must be at least the smartcard validity period.

RampUp(Central Register) = u

Active(Central Register) ≥ u

Passive(Central Register) = 0

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

702

Table 1: Rollover timing for each certiﬁcate. Some certiﬁcates have a mandatory ramp up phase. The total validity (last

column) is the sum of the ramp up, active and passive phases.

Ramp up Active Passive Validity

Root CA u ≥ 2u ≥ 2u ≥ 5u

Hardware CA ≥ 2u ≥ 2u ≥ 4u

Manufacturer CA ≥ u ≥ u ≥ 2u

Smartcard u u

Operational CA ≥ 2u ≥ u ≥ 3u

Central Register u ≥ u ≥ 2u

Timestamp Service u ≥ u ≥ 2u

Minting 2u 2u

Financial CA ≥ 2u ≥ u ≥ 3u

FSP 2u 2u

The same applies to the timestamp service: It is

highly recommended to use the same validity period.

Minting. The minting certiﬁcate is not relevant for

smartcards. The only requirement is that its validity

never exceeds the validity of the Operational CA. A

canonical validity period is therefore 2u.

5.6 Financial CA Strand

This strand is not critical, since its certiﬁcates are all

issued online. We can therefore use 2u as the period

for FSP certiﬁcates, and the same values for the Fi-

nancial CA as the Operational CA.

5.7 Root CA

At the time of activation of the new Root CA certiﬁ-

cate, all circulating smartcards must already know the

new certiﬁcate. Therefore, the ramp up phase must be

at least u.

Unlike the Hardware CA and the Manufacturer

CA, the Root CA certiﬁcate does not need to be able

to issue certiﬁcates at all times. Rather, it creates sub-

ordinate CA certiﬁcates only at speciﬁc points. The

only requirement is that issued certiﬁcates are valid

along their whole lifetime.

To ensure that smartcard certiﬁcates issued on the

last day of validity of the Hardware CA, we obtain a

passive phase for the Root CA of at least 2u.

To summarize:

RampUp(Root CA) = u

Passive(Root CA) ≥ 2u

Active(Root CA) + Passive(Root CA) ≥ 4u

There is some degree of freedom in choosing the pre-

cise value of Active(Root).

6 CONCLUSION

We have discussed how any CBDC system needs to

authenticate entities and thus equip them with certiﬁ-

cates. Since the trust in the system hinges on the trust

in the central bank, we proposed to employ a Pub-

lic Key Infrastructure (PKI) operated by the Central

Bank.

In particular, we introduced categories of certiﬁ-

cates with similar security requirements and security

processes, which lead us to a PKI design with con-

crete certiﬁcate authorities.

Furthermore, we investigated certiﬁcate for-

mats and revocation procedures and concluded that

stripped down X.509 certiﬁcates, such as CV Certiﬁ-

cates, are appropriate for CBDC use.

Technical certiﬁcate revocation procedures may

negatively affect transaction throughput and perfor-

mance. As an alternative, operational revocation pro-

cedures turned out to be most appropriate, since, in

contrast to typical PKIs, relying parties are known be-

forehand. This leads to manageable revocation proce-

dures at the relying parties, instead of a singe point

of revocation status checks, such as OCSP responders

and CRLs.

Finally, we proposed a rollover concept for a PKI,

which enables seamless operation despite regularly

scheduled certiﬁcate expirations. This rollover con-

cept is generic and can be tailored to speciﬁc central

bank needs. The smallest unit of validity is the smart-

card validity period, which can be chosen to be any

timeframe desired, and can be multiplied appropri-

ately.

How to Design a Public Key Infrastructure for a Central Bank Digital Currency

703

ACKNOWLEDGEMENTS

We thank our colleagues Nils Abeling, Klaus Alfert,

Tolga Hazerli, and Peter Zeller for discussions on

an early PKI concept. This work has been par-

tially supported by the Federal Ministry of Educa-

tion and Research (BMBF), Verbundprojekt CON-

TAIN (13N16582).

REFERENCES

BIS Innovation Hub (2022). Project Aurum: a prototype for

two-tier central bank digital currency (CBDC).

Boeyen, S., Santesson, S., Polk, T., Housley, R., Farrell, S.,

and Cooper, D. (2008). Internet X.509 Public Key In-

frastructure Certiﬁcate and Certiﬁcate Revocation List

(CRL) Proﬁle. RFC 5280.

Campbell, R. (2019). Transitioning to a Hyperledger Fabric

Quantum-Resistant Classical Hybrid Public Key In-

frastructure. The Journal of the British Blockchain

Association, 2(2):1–11.

Christodorescu, M., Gu, W. C., Kumaresan, R., Minaei,

M., Ozdayi, M., Price, B., Raghuraman, S., Saad, M.,

Shefﬁeld, C., Xu, M., and Zamani, M. (2020). To-

wards a Two-Tier Hierarchical Infrastructure: An Of-

ﬂine Payment System for Central Bank Digital Cur-

rencies.

Chu, Y., Lee, J., Kim, S., Kim, H., Yoon, Y., and Chung,

H. (2022). Review of Ofﬂine Payment Function of

CBDC Considering Security Requirements. Applied

Sciences, 12(9):4488.

Di Iorio, A., Kosse, A., and Mattei, I. (2024). Embracing

diversity, advancing together – results of the 2023 BIS

survey on central bank digital currencies and crypto.

BIS Papers, (147).

Ford, W. S., Chokhani, S., Wu, S., Sabett, R., and Merrill,

C. C. R. (2003). Internet X.509 Public Key Infras-

tructure Certiﬁcate Policy and Certiﬁcation Practices

Framework. RFC 3647.

Han, X., Yuan, Y., and Wang, F.-Y. (2019). A Blockchain-

based Framework for Central Bank Digital Currency.

In IEEE International Conference on Service Opera-

tions and Logistics, and Informatics (SOLI). IEEE.

Hong Kong Monetary Authority (2021). e-HKD: A techni-

cal perspective.

Hupel, L. and Raﬁee, M. (2024). How Does Post-quantum

Cryptography Affect Central Bank Digital Currency?,

page 45–62. Springer Nature Singapore.

International Organization for Standardization (2021).

ISO/IEC 7816-8:2021 Identiﬁcation cards — Inte-

grated circuit cards, Part 8: Commands and mecha-

nisms for security operations.

International Organization for Standardization (2023).

ISO/TR 24374:2023 Financial services — Security in-

formation for PKI in blockchain and DLT implemen-

tations.

Pal, O., Alam, B., Thakur, V., and Singh, S. (2021). Key

management for blockchain technology. ICT Express,

7(1):76–80.

Takaragi, K., Kubota, T., Wohlgemuth, S., Umezawa, K.,

and Koyanagi, H. (2023). Secure Revocation Features

in eKYC - Privacy Protection in Central Bank Digi-

tal Currency. IEICE Transactions on Fundamentals

of Electronics, Communications and Computer Sci-

ences, E106.A(3):325–332.

Yang, B., Zhang, Y., and Tong, D. (2022). DOT-M: A Dual

Ofﬂine Transaction Scheme of Central Bank Digital

Currency for Trusted Mobile Devices, page 233–248.

Springer Nature Switzerland.

Zhang, Z. W. (2024). CBDC Security, page 73–92. Springer

Nature Switzerland.

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

704