## 4 Proposed HF-Based Security Architecture
### Overview of the Proposed HF-Based Security Architecture  
The proposed HF-based security architecture for IoMT-based health monitoring systems is presented in Figure 3, and aims to: (i) achieve entity authentication (i.e., device authentication) as the HF platform allows the deployment of permissioned blockchain networks, (ii) enable IoMT devices to transmit data to each other in a secure manner (i.e., confidentiality of the exchanged data) due to the functionality of the HF platform to permit secure communication, via channels, between specific participants, (iii) eliminate single point of failure issues (e.g., no risk of DoS attacks), and (iv) achieve more secure (i.e., tamper-proof) data storage given its decentralized, autonomous, and cryptographically secure nature. The HF platform can enable a more energy-efficient blockchain-based security architecture for IoMT-based health monitoring systems, compared to other popular blockchain platforms such as Ethereum, as HF does not apply the consensus protocol of Proof of Work (PoW) that cannot be afforded by IoMT devices (e.g., medical sensors) due to their limited processing power, storage capacity, and battery life.  
The proposed architecture can include multiple HF organizations (i.e., \(N\) HF organizations) that are interconnected through peers or orderers running on devices, such as gateways and servers, and operating under the HF platform on an HF-based network. In the context of HF, each organization is a member (e.g., healthcare provider, patient) that is eligible or invited to join the HF blockchain network. In addition, each organization can include multiple peers or orderers of different perception or cloud domains (e.g., \(K\) Perception domains in Organization 1 and \(M\) Cloud domains in Organization \(N\)). Owing to the functionalities of HF, an organization can contain Certificate Authorities (CAs), responsible for the entity authentication, orderers, or peers, and each of these entities can be interconnected with others through private channels inside the HF network.  
Each organization in the proposed HF-based security architecture consists of the following key HF components as also shown in Figure 3:  
_Peer_ is the main component of the HF network that permits the hosting of (i) the blockchain ledger, (ii) the chaincode, and (iii) the endorsement policies, while permitting the communication of the user with the HF network through the SDK. A peer can be hosted on a gateway of a Perception Domain or on a server of a Cloud Domain of the proposed HF-based security architecture.  
_Orderer_ is a component responsible for managing and ordering the transactions that are added to the blockchain. An orderer is responsible to ensure the timely and accurate ordering of patient data and other transactions on the blockchain. The orderer could be responsible for receiving transactions, such as patient data and other healthcare-related information, from the gateways in the network and then validating the transactions to ensure that they meet the network's consensus rules. The validated transactions would then be added to the blockchain to maintain the integrity and consistency of the ledger. Similar to a peer, an orderer can be hosted on a gateway of a Perception Domain or on a server of a Cloud Domain of the proposed HF-based security architecture.  
_Certificate Authority (CA)_ generates certificates for the entities of the network, such as admins, users, peers, orderers, or applications, that can be used to authenticate them. Thus, the generated certificates are used to ensure the legitimacy of the entities of the network so that they can communicate with each other and transmit data in a secure manner.