*5.2. Security Requirements*

Security requirements countering the security threats identified in Section 5.1 are specified as follows:


contact nodes. The contact nodes running on heterogeneous blockchains should identify and authenticate each other before sharing ledger data.

In Table 1, SR-1 (stablecoin deposit) can prevent ST-1 (breach of contract by originator's transfer agents). This means that if the originator's transfer agent does not pay the transfer amount, excluding the transfer fee to the beneficiary's transfer agent, the stablecoins deposited by the originator's transfer agent are automatically paid to the beneficiary's transfer agent by the smart contract. SR-2 (data encryption in transmission) can prevent ST-2 (ledger data leakage during transmission between contact nodes). This means that although the ledger data are leaked during transmission between the contact nodes running on heterogeneous blockchains, it is difficult to use the leaked ledger data encrypted with a cryptographic algorithm. SR-3 (minimization of the amount of retrieved ledger data) can prevent ST-3 (massive ledger data leakage from blockchains). This means that it is possible to prevent leakage of massive ledger data from blockchains by narrowing down the query conditions to seek ledger data in the contact nodes. SR-4 (election of transfer agents by a consensus algorithm) can prevent the ST-4 (monopoly by specific transfer agents). This means that the monopoly of specific transfer agents can be prevented by electing transfer agents based on the consensus algorithm for each transfer. SR-5 (identification and authentication between the contact nodes) can prevent ST-5 (data request by unauthorized blockchains). This means that the contact nodes running on blockchains which are not registered with BIMS cannot request ledger data from the contact nodes running on blockchains registered with BIMS, in accordance with the results of mutual authentication between contact nodes.

**Table 1.** Relationship between security threats and security requirements.


(Note: ST = security threat; SR = security requirement).

#### **6. Discussion and Conclusions**

The main objective of this paper is to propose an interoperable architecture between heterogeneous blockchains, and a new decentralized P2P service model for the transfer between blockchain-based heterogeneous cryptocurrencies and CBDCs. The experimental evaluation of the proposed service model could be done as future work.

This paper identifies potential security threats to the proposed service model and describes security requirements to prevent the identified security threats. The proposed service model should be implemented to meet the security requirements.

The interoperable architecture enables the exchange of transaction ledger data of cryptocurrency and CBDC without intermediaries between heterogeneous blockchains. This enables cryptocurrency and CBDC to be transferred by decentralized transfer agents, even if the originator's blockchain and the beneficiary's blockchain are different.

The service scenario in Figure 6 demonstrates that the transfer between an originator and a beneficiary with heterogeneous cryptocurrency and CBDC can be processed very conveniently and usefully. This is because the originator does not have to consider what the beneficiary's wallet type is. Thus, the proposed service model based on the proposed interoperable architecture solves the transfer problem between heterogeneous blockchainbased cryptocurrencies and CBDCs.

There are several advantages of the proposed service model: (1) The proposed interoperable architecture allows the sharing of ledger data between heterogeneous blockchains without intermediaries. (2) BIMS provides the common operations for sharing ledger data between the blockchains, rather than storing and maintaining the ledger data retrieved from the blockchains. (3) The proposed service model allows the transfer between cryptocurrencies, between cryptocurrency and CBDC, and between CBDCs without cryptocurrency exchanges and banks.

There are several reasons why BIMS service provider and transfer users would be interested in accepting the proposed service model: (1) The originator can directly transfer cryptocurrencies and CBDCs regardless of the beneficiary's wallet type. (2) The originator does not need to exchange the cryptocurrency and CBDC to be transferred for the same cryptocurrency and CBDC as the beneficiary's wallet type. (3) Transfer fees to be paid by the originators and beneficiaries are lower than the centralized organization, such as cryptocurrency exchanges, banks, transfer service providers and so on. (4) BIMS service providers are not burdened with storing and maintaining the ledger data retrieved from other blockchains for interoperability.

The proposed interoperable architecture will be developed as an international standard by ITU-T (International Telecommunication Unit) SG17, and the proposed service model will be developed as Korean ICT standard by TTA (Telecommunications Technology Association) PG1006. Private companies will be able to implement the proposed service model based on the interoperable architecture as a decentralized P2P transfer system by technology transfer in the future.

**Author Contributions:** Conceptualization, K.P.; methodology, K.P.; validation, K.P. and H.-Y.Y.; formal analysis, K.P.; investigation, K.P.; writing—original draft preparation, K.P.; writing—review and editing, K.P. and H.-Y.Y.; supervision, H.-Y.Y.; project administration, H.-Y.Y. All authors have read and agreed to the published version of the manuscript.

**Funding:** This research received no external funding.

**Institutional Review Board Statement:** Not applicable.

**Informed Consent Statement:** Not applicable.

**Data Availability Statement:** Not applicable.

**Acknowledgments:** This research was implemented as part of the project "Standardization Lab. for Next-generation Cybersecurity" (Project Number: 2021-0-00112) supported by MSIT (the Ministry of Science and ICT) and IITP (Institute of Information & Communications Technology Planning & Evaluation).

#### **Conflicts of Interest:** The authors declare no conflict of interest.
