## 2 Security Requirements for CBDC and Digital Currencies
### Non-Repudiation  
Repudiation occurs when the entity that received the digital currency maliciously insists that they did not receive it or that the digital currency they received is fake. [PERSON] and [PERSON] [57] stated the conditions in which repudiation could occur.  
* The entity that received the digital currency insists that the signature on the digital currency is a forgery;
* The signature is not a forgery, but the entity that received the digital currency insists that the cash was obtained via: 1. Unconscionable conduct during transactions; 2. Fraud instigated by a third party; 3. The undue influence exerted by a third party.  
[PERSON] and [PERSON] [57] specified the requirements to prevent issues of repudiation in cryptocurrency as follows:  
* A service that provides proof of the integrity and origin of data, both in an unforgeable relationship, which any third party can verify at any time during the authentication process;
* An authentication with high assurance that cannot subsequently be refuted.  
Research studies on computer networks, such as [PERSON] and [PERSON] [58], [PERSON] and [PERSON] [59], [PERSON] and [PERSON] [60], and [PERSON] et al. [61], focused on the non-repudiation protocol. Specifically, [PERSON] et al. [61] proposed the following requirements for fair non-repudiation protocol (FNRP):  
* FNRP should provide the payer non-repudiation of receipt to verify the transaction from the Adjudicator;
* FNRP should provide the payee non-repudiation of origin to verify the transaction from the Adjudicator;
* When FNRP ends, the transaction parties should obtain both non-repudiation of receipt and non-repudiation of origin (all together, the non-repudiation evidence, NRE). If the receipt and origin evidence are not obtained, the transaction can be seen as problematic;
* FNRP with the trusted third party (TTP) must individually create an NRE regardless of TTP involvement;
* FNRP that does not use the trusted third party (TTP) should present fairness probabilistically;
* FNRP can be terminated by the transaction parties who have confirmed that FNRP has secured fairness after a reasonable period.  
Cryptocurrencies cut off the possibility of repudiation by keeping the transaction data in each block in the blockchain. Specifically, due to the base logic that the longest block is selected as the main chain and more than 50% of hashing power or stakes is needed to create the fake chain, the possible repudiating attempts by substituting the existing main chain for the fake one can rarely occur. According to [PERSON] [62], in the Bitcoin system, when 10 new blocks are added to the current main chain, the possibility of deleting the existing block by an attacker even with 10% of the mining power is only 0.0000012%. In addition, the Ethereum system prevents the possibility of repudiation by using the hash function Keccak-256 to perform the message digest for the data logged in each block and writing the hash value to the block at the same time. According to IBM, a message digest is defined as a fixed-size numeric representation of the contents of a message, computed by a hash function [63]. According to [PERSON] [64], an attacker needs the value of the reversed Keccak-256 function to maliciously alter the contents in the block with a hash value, but realistically, it is impossible.  
Regarding CBDCs, not many discussions have been had regarding non-repudiation. According to [PERSON] [65], the CBDC based on DLT in which only approved authorities are allowed to verify transactions and manage the ledger, the so-called permissioned CBDCs in Figure 1, was regarded as a solution for the repudiation problem, as approved authorities can provide a non-repudiation policy [65]. However, the permissioned CBDCs are vulnerable to the manipulation of the blockchain. Therefore, to use the permissioned CBDCs as a solution for non-repudiation, additional security safeguards that prevent manipulation of the blockchain are needed [65].