Offline Payment of Central Bank Digital Currency Based on a Trusted Platform Module

Abstract

The implementation of Central Bank Digital Currencies (CBDCs) faces significant challenges in achieving the same level of anonymity and convenience in offline transactions as cash. This limitation imposes considerable constraints on the development and widespread adoption of CBDCs. Unlike cash, digital currencies, similar to other electronic payment methods, necessitate internet or other network connectivity to verify payment eligibility. This study proposes a secure offline payment model for CBDCs that operates independently of internet or network connections by utilizing a Trusted Platform Module (TPM) to enhance the security of digital currency transactions. Additionally, the monotonic counter, the basic component of the TPM, is integrated into this model to prevent double spending in a completely offline environment. Our research presents a protocol model that combines these easily implementable technologies to facilitate the efficient processing of transactions in CBDCs entirely offline. However, it is crucial to acknowledge the security implications associated with the TPMs and near-field communications upon which this protocol relies.

1. Introduction

With the rapid digitization of finance worldwide, the emergence of cryptocurrencies, such as Bitcoin, serves as a significant catalyst for change in payment and settlement systems. Traditionally, financial institutions have acted as intermediaries for payment methods, generating various revenues from payment services. However, the rise of cryptocurrencies, which operate without intermediaries, heralds a revolutionary shift in this conventional system. Furthermore, as finance continues to digitize, current electronic payment methods remain largely based on cash. Since cryptocurrencies are not tied to cash, central banks globally recognize them as competitors to cash and are closely monitoring their proliferation [1,2]. Additionally, central banks have begun to explore the feasibility of issuing cryptocurrency like Central Bank Digital Currencies (CBDCs) [3,4]. However, there are numerous limitations associated with the use of CBDCs. Generally, CBDCs inherit the constraints of electronic payment method, including issues related to anonymity and offline transactions [5,6,7]. In particular, offline environments are isolated and can be vulnerable to numerous breaches, making them risky and challenging for immediate attack detection. In this study, a CBDC model is proposed to facilitate peer-to-peer (P2P) payments in a completely offline environment. Most CBDCs currently under research require an online connection, similarly to existing electronic payment systems or cryptocurrencies. Therefore, it is crucial to develop a CBDC that can operate in environments without an online network, akin to cash transactions. Our proposed model incorporates several security elements, including a Trusted Platform Module (TPM), a secure hardware device, and JSON Web Tokens (JWTs) that contain digital signatures. The remainder of this paper is organized as follows: Section 2 introduces the literature review of this study. Section 3 describes our method, notation, and the detailed protocol of our model. In Section 4, we analyze the results and discussions. Finally, we conclude in Section 5.

2. Literature Review

For cash transactions, once the sender and receiver meet and the exchange is completed, all claim–obligation relationships are immediately extinguished without the involvement of any financial institutions or payment service providers. In contrast, electronic payment methods require the presence of an intermediary, as both the sender and receiver must be connected to the internet or other networks to facilitate the transaction. In other words, when an individual makes a credit card purchase or an online e-commerce payment, he or she must be online to access the payment service provider. This connection is essential for checking the account balance, verifying the legitimacy of the transaction, and preventing the risk of double spending; this risk can also apply to blockchain [8]. These constraints similarly apply to the use of CBDC. Consequently, many organizations have been researching offline payment solutions for CBDC to overcome these limitations. For instance, the Bank for International Settlements (BIS) and the Bank of Canada have recently published the results of a study detailing the identification of security requirements for offline CBDC payments [9,10]. Additionally, the European Central Bank announced procurement details for digital euro projects in January 2024, highlighting offline payments as a challenge that needs to be addressed [11].

Since the late 1980s, studies on electronic payments have been conducted continuously. These studies have particularly focused on the application of cryptographic technology to address security and privacy concerns, such as preventing counterfeiting and double spending, while also providing anonymity. However, the primary objective of these studies has been to explore methods for secure transactions, based on the assumption that most parties involved in a transaction must be connected to the internet or other networks. Consequently, typical peer-to-peer payments using electronic devices require either both of the sender’s and receiver’s terminals to be connected to the internet, or at least one of the terminals (such as a Point Of Sales) to be connected to the internet or local payment networks, as illustrated in Figure 1a,b. The scenario depicted in Figure 1b can be classified as a hybrid environment.

In a recent study, Dmitrienko et al. proposed an offline payment model to prevent double spending [12]. However, it is challenging to regard it as a fully offline model, as it requires access to the blockchain network for token validation. Similarly to cash transactions, our ultimate goal is to facilitate payments in situations where an internet connection between the two parties is not reliably available. To achieve this, short-range wireless communication, such as the peer-to-peer (P2P) mode of Bluetooth or Near Field Communication (NFC), is essential between terminals. However, this study does not focus on the security of wireless communication itself but rather on transactions after the connection is established. Additionally, it is proposed that the P2P payment model discussed in this study is based on tokenized CBDC, which can be transferred between different terminals. Figure 2 illustrates an example of the complete offline P2P payment environment that serves as the foundation for this study.

There have been several recent studies in this area. Aboulaiz et al. analyzed various offline CBDC payment systems, including a complete offline environment model [13]. They approached their study of offline payments as a complementary solution in the event of online network failures. Their analysis included four models, with

Table 1. Offline payment services and study [13].

Model Name	Key Features	Type
Stripe [14,15]	The client receives a secret from the server and sends it to the Stripe server to process the payment. The legitimacy of the payment is verified once the terminal is online	Hybrid
UPI lite [16,17]	Payment instructions are issued offline, but the verification takes place once the terminal is online	Hybrid
Matera [18]	Payment instructions are issued offline, but the payee needs to be online	Hybrid
Crunchfish’s digital cash [19,20]	Payment instructions are securely generated using V-key and V-OS VSE. Merchants can store payment information and synchronize offline payments once connected to the internet	Hybrid
OPERA [21]	Offline payments are facilitated using one-time readable memory, digital signature, and a token counter	Complete offline

summarizing the key features of each. While they examined one of the models, OPERA, as a complete offline payment solution, they also highlighted several shortcomings that could hinder the widespread adoption of OPERA. These challenges include the requirement for a specific type of memory, such as one-time readable memory, and a complex token security infrastructure.

Meanwhile, Chu et al. [22] delineated the security requirements for offline CBDC payments, which include unforgeability, non-repudiation, verifiability, prevention of double spending, and anonymity. This study will address these requirements in detail in Section 4.

3. Methodology

3.1. Core Features of Proposed Model

To implement a secure CBDC payment system in a completely offline environment, several widely utilized technologies are employed. Firstly, a TPM is used as a security device, along with its counter, which serves as a fundamental aspect of this study. By leveraging the TPM counter, it becomes possible to determine whether a payment has been executed, even in a fully offline environment. For efficiency and convenience, a token-based approach is adopted, specifically utilizing JSON Web Tokens (JWTs), which are inherently verifiable. Furthermore, the generation of a valid payment token must be performed by the counterparty to mitigate the risk of fraud by the device owner. The digital signature provided by the TPM is utilized for payment verification and to ensure non-repudiation. The following outlines the core features of the proposed model.

• Applying the TPM and its counter: The TPM was developed by the Trusted Computing Group (TCG) [23]. The TPM fundamentally consists of hardware-based cryptographic chips and a standardized framework for managing these chips through embedded software, which enhances compatibility among various cryptographic components. The TPM specification was formalized as ISO/IEC 11889 in 2015. Specifically, the TPM functions as a system-independent security chip designed to be impervious to external access. Utilizing this characteristic, the TPM generates and securely stores cryptographic keys and executes cryptographic operations internally to ensure robust security. In the TPM 2.0 specification, the rights of the user and the platform owner are restricted, preventing users from modifying the TPM’s functionalities [24]. The TPM is widely utilized across various devices, including smartphones and notebook PCs. The main functions of a TPM encompass boot security, authentication, data protection, device protection, and the prevention of unauthorized access [25,26,27]. Moreover, TPM 2.0 introduces a versatile monotonic counter stored in non-volatile memory, characterized by a non-decreasing value that is resistant to tampering due to its internal location within the TPM. This monotonic counter is particularly advantageous, as it can be employed in conjunction with specific messages to ascertain whether a message has been reused. A study conducted by Sarmenta et al. demonstrated the feasibility of implementing a secure payment method utilizing the TPM’s monotonic counter within an untrusted platform [28]. In the present study, the monotonic counter within an offline platform is employed to detect instances of double spending, and detailed payment processes will be presented in the subsequent section.
• Applying the ID (identification) certificate: Each offline CBDC wallet is equipped with a public key pair within the TPM for transaction purposes and is secured by an ID certificate issued by the CBDC institution or a Certificate Authority. Subscribers are required to verify their identity upon receipt of the ID certificate, which contains an identifier for the subscriber’s offline CBDC wallet rather than their actual name. This identifier must not be linked to any personal information of the subscriber and is utilized for administrative purposes by the CBDC institution. The certificate is included and transmitted with the transaction. To enhance efficiency, particularly in terms of ID certificate validation and verification, it is essential that all such certificates share the same domain or root.
• Applying the JSON Web Token (JWT) for offline CBDC format: JWT is a standard established by the Internet Engineering Task Force (IETF), RFC 7519. It is widely employed in web applications for the secure transmission of information, particularly in the areas of authentication and authorization. A JWT consists of three components, which are separated by dots: Header.Payload.Signature. Given that JWT supports both public key digital signatures and private claims for specialized applications, it can be effectively utilized in offline CBDC implementations. While the Header and Signature components conform to the JWT standard, the Payload component requires a new definition specifically designed for offline CBDC applications. The following seven claims have been newly defined, as illustrated in

  Table 2. Private claims for offline CBDC.

  Private Claims	Meaning
  “cbSta”	Status of offline CBDC token the values of which are “Tp “, “ON”. Tp: temporary token, ON: made in the offline but not yet confirmed in the online. Where “N” is the number of generations of the offline CBDC token. Especially, “O1” is the first offline token generated from online.
  “cbRt”	Transaction number (RT) of the Offline CBDC.
  “cbOwn”	Owner ID of Token. Owner ID should be the subject name in the ID certificate.
  “cbOtcn”	TPM counter number of the Owner offline CBDC wallet.
  “cbAmt”	Transaction amount
  “cbEds”	Endorser ID of Token. Endorser ID should be the subject name in the ID certificate.
  “cbEtcn”	TPM counter number of the Endorser offline CBDC wallet.

  . It is essential that all of these claims be regarded as mandatory within the context of offline CBDC tokens.

The example of JWT for offline CBDC is as follows:

• Header: {“alg”:”ES256”,”typ”;”JWT”}
• Payload: {“cbSta”:”O2”,”cbRt”:”679”,”cbOwn”:”WOff1039”,”cbOtcn”:”16”,”cbAmt”:”$60”, “cbEds”: “WOff9120”,”cbEtcn”:”981”}
• Signature (with ECDSA-SHA256 algorithm): {kvwd02iy9zq6lwFsnbG4Gz-aXUJXzV vyQC1BseLWfIrzncHA1IN32EZbVByMAV8mqHqvwNdGqQafviT3GG7kG Q}
• Encoded offline CBDC JWT (base64) = eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.-eyJjYlN0YSI6Ik8yIiwiY2JSdCI6IjY3OSIsImNiT3duIjoiV09mZjEwMzkiLCJjYk90Y24i OiIxNiIsImNiQW10IjoiJDYwIiwiY2JFZHMiOiJXT2ZmOTEyMCIsImNiRXRjbiI6Ijk4 MSJ9.kvwd02iy9zq6lwFsnbG4Gz-aXUJXzVvyQC1BseLWfIrzncHA1IN32EZbVByM AV8mqHqvwNdGqQafviT3GG7kGQ

4.

Separation of offline CBDC wallet from online CBDC wallet: Offline wallets are utilized exclusively in scenarios where they are completely offline, and the offline tokens are initially derived from online tokens, as illustrated in Figure 3. Payment tokens that are utilized in online transactions can be transferred to offline environments through established procedures; conversely, offline payment tokens can be converted back into online tokens. It is important to note that while various types of online payment tokens and transactions are prevalent in the real world, this study focuses solely on the payment processes involving tokens within offline wallets, which operate in a completely offline context. Furthermore, the offline tokens examined in this study are not self-generated; rather, they are structured such that one party in the transaction generates and guarantees the token for the other party. And the conversion of online tokens to offline tokens necessitates a procedure that includes a guarantee from a CBDC operator, which will be the subject of future research.

5.

Secure P2P communication: The offline payment mechanism for CBDC should utilize a peer-to-peer (P2P) data exchange mode that relies on short-range wireless communication technologies, such as Bluetooth and NFC. Furthermore, each payment message must be transmitted and received through a secure channel established between offline wallets. However, the process of establishing this secure channel for P2P communication is beyond the scope of the present study. Therefore, it is assumed that CBDC transactions take place over a secure wireless communication network. All short-range communication sessions for offline transactions involving CBDC must be encrypted using a temporarily generated key.

6.

Use of all valid tokens for input: All valid tokens held by the sender must be employed concurrently during the payment process. Therefore, each payment transaction necessitates the inclusion of all valid tokens from the sender as input, while simultaneously converting the payment amount and the sender’s remaining balance into two output tokens. This procedure is crucial for the effective management of valid tokens.

3.2. Notations and Definitions

Our model conceptualizes the TPM as an independent entity, distinct from the Offline CBDC wallet (OffCW) and the subscriber. The symbols A, B, OffCW_A, OffCW_B, TPM_A, and TPM_B are employed to denote the respective entities: Sender, Receiver, Sender’s offline CBDC wallet, Receiver’s offline CBDC wallet, Sender’s TPM, and Receiver’s TPM. Additionally, the following symbols are utilized to represent messages within our protocol.

• Auth-code:User authentication code for Offline CBDC wallet execution.
• R_X: Random number of entity X.
• R_T: Transaction number. See the equation in Step 9–2
• PK_X: Public key pair of entity X for digital signature.
• SK_X: Symmetric key of entity X for encryption of information in OffCW.
• SRK_X: Symmetric key of entity X’s TPM for encryption of SK_X.
• Cert_X: OffCW’s digital certificate (ID certificate) of entity X.
• ID_X: OffCW’s ID of entity X in ID certificate.
• C_X: Monotonic counter value of entity X’s TPM.
• Bal_X: Token balance of entity X.
• E_SKx{M}: Message M is encrypted with symmetric key SK_X.
• D_SKx{M}: Message M is decrypted with symmetric key SK_X.
• Sign_PKx{M}: The signing value of message M with private key PK_X.
• Verify{M}: The legitimacy of the message M is verified by the digital signature, calculation etc.
• Req{M}: Request for message M.
• Req{“M”}: Request action of message M.
• : Communication between applications on the device.
• : Communication between devices.

3.3. Offline CBDC Model Protocol

Prior to the transaction, both the sender (A) and the receiver (B) should install an OffCW on their devices equipped with TPM. During the installation of the OffCW, each entity is required to obtain an ID certificate for its OffCW, following a verification of its identity. To initiate the transaction, each entity executes its OffCW program and establishes a connection with the other party through short-range wireless communication. The execution of the OffCW program necessitates the implementation of a security procedure, such as the entry of an authentication code, to verify the identities of the entities involved.

Each OffCW encrypts and stores its valid tokens, which can be utilized for transactions, along with the corresponding ID certificates (Cert_X) for each valid token. Additionally, each TPM securely retains the digital signature generation key (PK_X) and the OffCW’s ID certificate, which contains the digital signature verification key. Furthermore, the non-volatile memory within the TPM houses a monotonic counter (C_X) and the total sum of currently valid tokens (Bal_X). The TPM also stores a decryption key (SRK_X) that is capable of decrypting another decryption key (SK_X), which, in turn, decrypts the values stored within the OffCW. The protocol delineates two types of communication: internal communication between the OffCW and the TPM, and external communication among OffCWs. Figure 4 illustrates the OffCW and the TPM information pertaining to the entity.

Step (1) A (Sender) OffCW_A:		Auth-code (program activate), Req{“Choose a Sender service”}
B (Receiver) OffCW_B:		Auth-code (program activate), Req{“Choose a Receiver service”}
Step (2) OffCW_B TPM_B:		Req{RB, CB, “Decrypt ESRKB{SKB}”}
Step (3) TPM_B OffCW_B OffCW_A: MB = [RB, CB, SignPKx{RB, CB}, Cert_B]
Step (4) OffCW_A:		Verify{MB}
Step (5) OffCW_A A (Sender):		Req{“Input Payment”, “Verify IDB”}
Step (6) A (Sender) OffCW_A:		Input the payment amount “T”
Step (7) OffCW_A TPM_A:		Req{RA, “Increase CA”, “Decrypt ESRKA{SKA}”}
Step (8) TPM_A OffCW_A:		MA = [RA, CA + 1, SKA, Cert_A]
Step (9) OffCW_A:		DSKA{Valid tokens, Cert_N}
(9–1) SUM = ${\sum }^N”cbAmt$N”, where “cbAmtN” is the valid input token’s “cbAmt”.  (9–2) K = SUM − T, RT = [{(${\sum }^{N}cbRt$N) + RA + RB + CA + 1+CB} mod RA] + RA,  where “cbRtN” is the valid input token’s RT  (9–3) gen_A = Header.Payload{“cbSta”:”Tp”,”cbRt”:RT,”cbOwn”:IDA,”cbOtcn”:CA +     1, “cbAmt”: K,”cbEds”:IDB,”cbEtcn”:CB}  where, the “Header” will be defined by CBDC institution.  (9–4) gen_B = Header.Payload{“cbSta”:”OX “,”cbRt”:RT,”cbOwn”:IDB,”cbOtcn”:CB,     “cbAmt”:T,”cbEds”:IDA,”cbEtcn”:CA + 1}  where, X in “OX” is the value by adding 1 to the largest number of N in input valid     token’s cbSta. (input tokens = valid tokens).
Step (10) OffCW_A TPM_A:		gen_A, gen_B, Req{“Sign gen_A”, “Sign gen_B”, “if Bal_A = SUM, True, False”}
Step (11) TPM_A OffCW_A:		SignPKA{gen_A}, SignPKA{gen_B}, True
Step (12) OffCW_A:		Token_t = Header.gen_A.SignPKA{gen_A}, Token_B = Header.gen_B.SignPKA{gen_B}
Step (13) OffCW_A OffCW_B:		MA = [Token_t, Token_B, Cert_A, Input tokens and related tokens, Cert_N, RA]
Step (14) OffCW_B:		Verify{MA}, ESKB{Token_B, Cert_A, Input tokens, Cert_N}
(14–1) new_gen_A = Header.Payload      {“cbSta”:”OX”,”cbRt”:RT,”cbOwn”:IDA,”cbOtcn”: CA +      1,”cbAmt”:K,”cbEds”:IDB,”cbEtcn”:CB}
tep (15) OffCW_B TPM_B:		new_gen_A, Req{“Sign new_gen_A”, “Balance update: Bal_B + T}
Step (16) OffCW_B B (receiver)		Req{“Confirm the amount T and the balance displayed on the screen”}
Step (17) TPM_B OffCW_B OffCW_A:           Token_A = Header.new_gen_A.SignPKB{new_gen_A}
Step (18) OffCW_A:		Verify{Token_A}, ESKA{Token_A, Cert_B, Input tokens, Cert_N}
Step (19) OffCW_A TPM_A:		Req{“Balance update: Bal_A = K”}
Step (20) OffCW_A A (sender)		Req{“Confirm the balance displayed on the screen”}

Figure 5 is an example of the proposed model. In this scenario, Alice is required to transfer USD 60 to Bob. Alice possesses a total of USD 100, which consists of three valid tokens: Token_A_O1, valued at USD 20 and confirmed by a CBDC institution; Token_A_O2, valued at USD 30 and received from Ann; and Token_A_O3, valued at USD 50 and received from Chan. Furthermore, Alice’s current counter value is 15, while Bob’s current counter value is 981. For the purposes of this example, for convenience, the IDs have been replaced with the respective names of the entities involved.

Token_A_O1 represents the initial token exchanged from an online to an offline context, with the value of ‘cbSta’ designated as O1 (see Table 2). The transaction number, denoted as ‘cbRt’, is recorded as 0, indicating that this is the first token exchanged from an online wallet. The first offline token will display a counter value (’cbOtcn’) of 0, as the counterparty in this transaction is a central bank, and the token is secured by the signature of the central bank. Assuming that token_A_O2 originated from a token that was traded once in an offline transaction, the value of ‘cbSta’ will be O2. The transaction number, ‘cbRt’, was recorded as 712, and this token also reflects the current counter value of Alice’s TPM. It was received from a transaction with Ann, whose counter value, ‘cbEtcn’, was 39 at the time of the transaction, and token_A_O2 is validated by Ann’s digital signature. Similarly, if we assume that token_A_O4 originated from a token that was traded offline three times, the value of ‘cbSta’ would be O4. This token is guaranteed by Chan, whose TPM counter was 42 at the time of the transaction.

In order to provide a more comprehensive understanding of the transaction process, Alice and Bob first engage in the offline CBDC wallet program and choose the appropriate function from the on-screen menu. Alice will designate herself as the ‘Sender’, whereas Bob will identify himself as the ‘Receiver’. Alice and Bob subsequently position their devices in close proximity to establish a secure short-range wireless communication link, utilizing technologies such as Bluetooth or NFC. Upon successful establishment of this communication, Bob’s offline CBDC wallet transmits his current TPM counter number along with a random number to Alice’s offline CBDC wallet. All transmitted values are digitally signed, and Bob’s ID certificate, which includes the signature verification key, is sent to facilitate the signature verification process. Following this, Alice’s wallet verifies the received data and displays Bob’s ID and the input box for the remittance on the screen. After Alice confirms Bob’s ID and inputs the desired amount, USD 60, her wallet requests an increment of the counter and a random number from the TPM_A. Upon receipt of the increased counter and random number from the TPM_A, Alice’s wallet generates two tokens based on this information. The first token, referred to as Token_t, represents Alice’s balance and is valued at USD 40. As this is a temporary token, the value of ‘cbSta’ is designated as T_p. The transaction number (R_T) is computed by Alice’s wallet in accordance with the established calculation rules to derive the value ‘cbRt’.

The R_T is calculated according to step 9–2, as follows:

R_T = [ {R₁(0) + R₂(712) + R₃(39) + R_B(7721) + R_A(512) + C_A(15 + 1) + C_B(981)} mod R_A(512)] + R_A(512) = 765

(1)

The incremented value of Alice’s TPM counter is denoted as ‘cbOtcn’ (16). The second token, referred to as Token_B_O5, serves as the remittance token, with the value ‘cbSta’ assigned to O5, as the maximum value of the input tokens’ ‘cbSta’ is O4. The transaction number (R_T) also corresponds to the temporary token. Since the ownership of this token will be transferred to Bob, it includes Bob’s ID and his current TPM counter number. Both tokens are signed by Alice’s TPM and transmitted to Bob’s wallet, accompanied by Alice’s ID certificate and all input tokens.

Bob’s wallet verifies each value, including signatures, transaction number (R_T), counter number, and others. It subsequently updates the ‘cbSta’ value of the temporary token (Token_t) from T_p to O5 and removes Alice’s signature. Following this, Bob’s wallet displays the amount “T”, USD 60, on the screen. Upon Bob’s confirmation, the token, designated as Token_B_O5, is stored in his wallet. Additionally, Bob’s wallet requests the TPM_B to sign the revised temporary token value (derived from Token_t). Once the wallet receives the signed token, it finalizes Alice’s balance token, referred to as Token_A_O5, and sends it back to Alice’s wallet. When Alice’s wallet displays the updated remaining balance on the screen, USD 40, she confirms the transaction, and the token is subsequently stored in her wallet.

Figure 6 illustrates the tokens that have been preserved in OffCW_A and OffCW_B and their chains. It is imperative that OffCW_A transmits the details regarding the generation of input tokens to verify their validity, while OffCW_B is also responsible for retaining this information.

According to Section 3.1, the sender must consistently generate two new tokens, which represent both the sender’s and the receiver’s tokens. Following the transaction, the sender’s balance will invariably be “K” according to step 19. Notably, the encrypted tokens stored in the offline wallet can be utilized for the final validation of all valid offline tokens when establishing an online connection.

4. Results and Discussion

4.1. Experimental Results of Offline CBDC Token (JWT) and Comparisons

The proposed model represents a sophisticated framework designed to offer a comprehensive and holistic solution for secure offline CBDC payments. This paper presents the results of a preliminary experimental study that investigates the feasibility of the model. A small-scale proof-of-concept prototype was developed to test the cryptographic functions of the TPM, specifically focusing on digital signature verification. The testing environment is detailed as follows [29]. Additionally, a combination of shell commands from TPM tools was employed for the testing process.

• OS–Ubuntu 20.04 LTS,
• TPM simulator–IBMtpm1661,
• TPM software stack–tpm2-tss-3.1.0,
• Resource management daemon–tpm2-abrmd-2.3.1,
• TPM tool–tpm2-tools-4.3.2

Initially, the counter increments were examined within the TPM simulator test environment. Subsequently, the signature value and the verification procedure, as well as the token header and payload, were tested, as illustrated in Figure 7.

And the JWT with RSA-SHA256 is as follows:

• Token = eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJjYlN0YSI6Ik8yIiwiY2JSdCI6Ij Y3OSIsImNiT3duIjoiV09mZjEwMzkiLCJjYk90Y24iOiIxNiIsImNiQW10IjoiJDYwIi wiY2JFZHMiOiJXT2ZmOTEyMCIsImNiRXRjbiI6Ijk4MSJ9.ABQACwEAMj2EVJ7B esO4a3KXKTFWabZ8WyNZZsltIDMghd06ahFTM86qwH11EtgN-h8PSe0tJYQhmg Lp6aLsJZ7jOR7dyMtikhE0SO_ZAY3gEqojvHTEm12c4yv8xDnPKkzSsZKSf3IVX_ VLbXikYoSRYQ9oMQgSeb20VbO2m2srAcLrnIII-ywK4uZp0fMjhlOJ-eUWhr-q3g6 c80BdcS4O0M_e9iZosXH8BUzuGpJJiCU9qTCC0aLSsodaOHb1aaf-2CX1NAjSHlIZ wXoB5jepuVLtBa7vqBGsvqLGjSQqCmcnb9JCT8pYhQ5DgQk4q248HJ4NBze7Qx XAlRLhJ5u3eD-bIg==

Our model distinguishes itself from the hybrid CBDC transaction models discussed in Section 2, including those of Stripe, UPI Lite, Matera, and Crunchfish’s digital cash, by being a CBDC transaction protocol designed for implementation in a fully offline environment, as opposed to a hybrid model. Conversely, it shares several similarities with the OPERA model, particularly in its operation within a completely offline environment, its token-based structure, and its utilization of verifiable signatures. Nonetheless, there are significant differences between the two models, which are outlined in

Table 3. Comparison with the OPERA model.

Category	OPERA Model	Proposed Model
Key features	* - The distribution of pre-generated tokens with a predetermined value by a financial institution, similarly to the issuance of coins. * - It is necessary to assemble a minimum combination of tokens that corresponds to the transaction amount and subsequently deliver it to the designated recipient.	* - All valid input tokens are categorized into two distinct output tokens: the sending token and the holding token. * - The tokens employed are organized in a token chain.
Security Mechanisms	* - A secure hardware wallet is utilized for the authentication and management of tokens, as well as for the storage of critical information, including encryption keys within a TPM. * - Specific hardware, characterized as one-time readable memory, is employed to safeguard against the reuse of tokens. * - The counter serves to indicate the number of tokens and is utilized for the purpose of transaction verification.	* - The use of a software wallet is essential for the management of tokens, as it securely stores key information, including the encryption key, within a TPM. * - A valid signature message is attached to all tokens. * - A monotonic counter is utilized to track the utilization of the token in prior instances.

.

The OPERA model is predicated on the utilization of secure hardware components, such as one-time readable memory, to facilitate transactions in a complete offline environment. However, as highlighted in the report from Section 2 [15], the requirement for a specific type of memory and a complex token infrastructure may impede its widespread adoption. In contrast, the proposed model employs a secure protocol that incorporates a TPM, counters, and a JWT with a signature, eschewing reliance on hardware techniques. And our model offers the flexibility to segregate transaction amounts unlike the OPERA model that circulates the fixed amount tokens. Furthermore, the proposed model demonstrates high scalability by leveraging a combination of general-purpose technologies that are currently prevalent.

The detailed security considerations for the proposed model, in relation to the requirements outlined in Section 2, are as follows.

4.2. Token Forgery and Non-Repudiation

All tokens transmitted and received offline in this study adhere to the JWT structure.

Token format (JWT) = Header.Payload.Signature

(2)

Tokens require the signature of a guarantor (the receiver), thereby preventing attackers (the sender) from generating a valid token on their own. The guarantor’s signature is produced by a signing key located within the TPM, accompanied by an ID certificate; this process is inherently unforgeable. In a worst-case scenario, if an attacker successfully compromises the TPM and forges a token through collusion with another subscriber, the potential damage inflicted within this digital currency system would be limited to the maximum transaction amount established by policy, even if the counterfeit token is transmitted to a legitimate subscriber. Furthermore, when all offline tokens are eventually shared and reconciled upon establishing an online connection, any compromised or counterfeit tokens can be identified. In terms of non-repudiation, all messages and tokens are equipped with digital signatures. A fundamental characteristic of digital signatures is their provision of non-repudiation.

4.3. CBDC Wallet and TPM Security

The majority of electronic payments conducted on PCs or smartphones are facilitated through digital wallets, which provide subscriber authentication and ensure secure transactions. Consequently, if various risk factors are not considered during the development of digital wallets, these systems may become susceptible to numerous vulnerabilities [30,31]. Breaches of CBDCs are likely to result in significant financial damage. Predominantly, attackers target digital wallets for personal gain. Two potential scenarios can be identified as advantageous for these attackers: first, manipulating their own wallet to generate a substantial quantity of tokens, a process referred to as token counterfeiting; and second, compromising another individual’s wallet to illicitly transfer tokens to their own. However, the latter scenario is not feasible in real-time within the context of our study due to its offline nature. This type of attack can only occur if the perpetrator establishes a direct 1:1 communication link with the victim at a close range, where technologies such as Bluetooth or NFC are applicable, rendering it highly improbable. The most plausible scenario for the second case involves malware that has infiltrated an online environment, subsequently concealing itself within the OffCW and activating under specific conditions, such as a denial-of-service (DoS) attack on the OffCW or the generation of fraudulent payments. However, since complete offline transactions can only occur in close proximity between users who are aware of each other, the likelihood of a DoS attack is very low. Collectively, these considerations indicate that the primary threats to the OffCW stem from either attack by the wallet owner or the presence of malware.

To mitigate the risks posed by unauthorized access and malware, our model is designed to ensure that valid tokens are generated by the counterparty using a secure device known as the TPM. This design leverages the principle that the primary cryptographic keys of the TPM are generated internally within the chip, and that cryptographic operations are conducted within the TPM itself, thereby enhancing security against potential exposure. However, to ensure the integrity of this system, it is imperative that a trusted third-party organization certifies the security of the TPM in the OffCW. To achieve this, TPMs utilized in OffCW applications should obtain Common Criteria (CC) certification and Cryptographic Module Validation Program (CMVP) certification [32,33]. These certifications are essential to verify that the information stored within the TPM is protected from leakage and tampering. In terms of tampering resistance, the TPM must meet both tamper-evident and tamper-proof criteria [34]. Furthermore, only authorized entities, such as the OffCW process, should be permitted to execute specific predefined commands within the TPM. Nevertheless, these countermeasures alone may be insufficient. It is crucial to execute the OffCW within a Trusted Execution Environment (TEE) to enhance security and defend against malware threats [35]. The TEE provides a secure environment for the storage, processing, and protection of critical programs, operating in isolation from the main system. This isolation safeguards the integrity of program code and data, ensuring that code is executed as intended while preventing tampering and the execution of malware or malicious processes. Additionally, secure coding should be implemented in the OffCW application to eliminate security vulnerabilities from the development phase. Moreover, the central bank’s digital currency policy may impose restrictions on the number of token transactions and the maximum volume of tokens held. If deemed necessary, the generation number of offline CBDC tokens, denoted as “N” in “cbSta”, can be limited, for instance, to a maximum of five, or the token’s lifespan can be constrained by incorporating an expiration date within the payload.

4.4. Double Spending

The issue of double spending arises from the fact that a payment token can be reused at any time, as the sender retains access to the digital signature key associated with their digital currency wallet. A primary function of intermediaries or distributed ledger blockchains within payment systems is to prevent the reuse of tokens and transactions through verification processes. However, verifying payment tokens that have already been utilized poses significant challenges when operating offline due to network limitations. In the context of this study, tokens are rendered non-reusable; once a token is utilized, the counter value within the TPM is altered. For each payout instruction, the TPM generates a new token with an updated counter value, ensuring that the counter value of the new token differs from that of any previously used token. Consequently, attempting to reuse a token that has already been utilized will yield a different counter number (specifically, a difference in “cbOtcn” greater than 1). Furthermore, as the counter value is securely stored within the TPM, offline payments are effectively safeguarded against the risk of double spending.

Input token’s “cbOtcn” in Payload = current TPM counter number

(3)

Output token’s “cbOtcn” in Payload = increased TPM counter number

(4)

4.5. Verifiability and Anonymity

As elucidated in this section, each token possesses a digital signature and is accompanied by an ID certificate that facilitates the verification of the token. Furthermore, all tokens can be authenticated concerning their association with the input tokens at the time of their creation, which can be corroborated by the total amount and the transaction number. With respect to anonymity, the names of the token owner and endorser, referred to as “cbOwn” and are designated as the subject names of the ID certificate. These names are independent of the subscriber and are assigned by the CBDC institution overseeing the OffCW.

Table 4. Security analysis of proposed model.

Offline Digital Currency Threats	Proposed Model
Token forgery and non-repudiation	- Token is backed by guarantor’s signature (also prevents fraud by owners) - TPM is accessible only to authorized OffCW and the digital signature key is not exposed to the outside of TPM
Digital wallet breach	- Critical information (e.g., encryption key SRKX) is inside the TPM and most of the information is stored encrypted - Some security countermeasures are more necessary, such as TEE, secure coding, limiting the amount of token held, and limiting the number of token exchanges
Double spending	- The TPM monotonic counter that changes with each transaction to prevent double spending
Verifiability	- Token has the signature with ID certificate - To create a new token, existing valid tokens are required
Anonymity	- The ID certificate (OffCW ID) is applied in this model. The ID is an administrative code by CBDC institution, similar to the serial number on a banknote

provides a summary of the countermeasures associated with the proposed model and its security analysis.

5. Conclusions

The potential of central bank digital currencies can be enhanced by increasing convenience while preserving the essential functions of cash. However, CBDCs, which share characteristics with electronic payment systems, are anticipated to face significant limitations in facilitating offline transactions. Specifically, these currencies require a constant internet connection to prevent double spending and to authenticate transactions, similarly to existing electronic payment methods and token-based blockchain systems. To address these challenges, this study has presented a framework for secure offline payments that does not rely on online ledger verification. This was achieved by storing individual token information within a TPM and employing a technique to ensure the security of each transaction. Nevertheless, the nature of peer-to-peer (P2P) payments allows for frequent fund transfers in offline environments, akin to cash transactions. Furthermore, independent terminal environments are perpetually vulnerable to security attacks, which represent a critical concern for digital currencies. A successful attack in an offline context could potentially result in the generation of unlimited funds, necessitating a cautious approach from monetary policy authorities. Additionally, the proposed model utilizes the internal counter provided by the TPM to mitigate security threats such as double spending; this counter is immutable and always monotonic. While TPMs do possess certain vulnerabilities, they are employed across various domains, including secure booting in Windows. If these vulnerabilities can be addressed, TPMs could prove to be highly beneficial for facilitating offline payments.

This study focuses on the payment process associated with offline tokens, as opposed to the online-to-offline conversion of tokens. It has analyzed the security of offline transactions that utilize short-range wireless communication technologies, such as Bluetooth and NFC. Each payment message must be transmitted and received through a securely established cryptographic channel between offline wallets; however, the establishment of this cryptographic channel is not the primary focus of this research. Furthermore, the reliability of the wireless connection may be compromised due to low bandwidth and signal interference, indicating a need for further research aimed at enhancing the reliability of short-range wireless communication to facilitate the adoption of the CBDC.