## 5 Simulation Set-Up of the Proposed HF-Based Security Architecture  
In this section, we present the simulation set-up of the proposed architecture. In this simulation, we deployed an instance of the proposed HF architecture presented in Section 4 on a Linux virtual environment on a Virtual Machine (VM) where the HF platform and the necessary perquisite software (e.g., Docker, golang) were installed. The parameters of the VM are shown below in Table 2:  
The deployed HF network that represents the instance of the proposed architecture consists of the following components, as shown in Figure 4: \begin{table}
\begin{tabular}{c c} \hline
**Feature** & **Specifications** \\ \hline Operating System & Ubuntu 22.04.2 AMD 64 \\ RAM & 4096 MB \\ Hyperledger Fabric & 2.2 \\ Docker & 20.10.21 \\ Node.js & v.12.22.9 \\ \hline \end{tabular}
\end{table} 
Table 2: Virtual Environment Parameters. Figure 3: Overview of the HF-based security architecture for IoMT-based health monitoring systems. * _Organization 1_, _peer0.org1_, representing the gateway of the patient in its respective perception domain;
* _Organization 2_, _peer0.org2_, representing the gateway of a healthcare provider that is part of the network;
* _Organization 3_, _orederer.org3_, representing the ordering service;
* A _CA_ is included in each Organization (e.g., _ca_org1_, _ca_org2_, _ca_orderer_). * We have also deployed the following necessary components:
* a _cli_ that allows us to interact with the peer in order to connect it to a channel and initiate transactions;
* a _CouchDB_, which is the state database used in HF to store the current world state of the blockchain network; and
* the containers that include the chaincodes (i.e., _create_asset_, _read_asset_) that will run during the simulation base on which the evaluation results in terms of latency (i.e., min (s), max (s), and average (s)), send rate (i.e., transactions per second), throughput (i.e., transactions per second), and memory usage (MB) are collected. The process for the simulation-set of the proposed network includes the following steps:  
1. As a first step, we create the Fabric CA servers by initiating the corresponding Docker containers, with the use of the HF binaries, in order to generate all the necessary certificates for the orderers and peers, as shown in Figure 5.
2. After setting up the Fabric CA servers, we proceed to generate the cryptographic material for the network (i.e., TLS, MSP certificates). According to the HF documentation [41], we initially enroll the CA server by generating an admin certificate  
Figure 4: The deployed HF network. which subsequently will be used to issue certificates and enroll the peers and the orderer in each organization, as well as to create a channel configuration that will define the initial state of the network. In Figures 6 and 7, we present an example of the enrolment of the CA admin and the org1 admin, respectively. * After generating the certificates, as a next step we define the initial configuration of the network. This step contains the configuration of the orderer and the peers that is achieved through the creation of the _docker-compose.yaml_ file that contains the necessary configuration parameters. * Once the initial network configuration is defined, we proceed with the creation of a genesis block that contains information about the network, including the cryptographic materials, the policies, and other configuration settings defined and created in previous steps. The genesis block is created with the use of the _configtxgen_ binary provided by the HF platform. Additionally, in this step we create also the _CouchDB_ containers used as ledger state databases. Figure 8 presents the creation of the genesis block. * This step involves the definition of the channel configuration, including the participating organizations and their respective peers as well as the orderer.