# Offline Payment of Central Bank Digital Currency Based on a Trusted Platform Module
## 4 Results and Discussion
### 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.