| Literature DB >> 35408064 |
Filippos Pelekoudas-Oikonomou1,2, Georgios Zachos1,2, Maria Papaioannou1,2, Marcus de Ree1, José C Ribeiro1, Georgios Mantas1,2, Jonathan Rodriguez1,3.
Abstract
Despite the significant benefits that the rise of Internet of Medical Things (IoMT) can bring into citizens' quality of life by enabling IoMT-based healthcare monitoring systems, there is an urgent need for novel security mechanisms to address the pressing security challenges of IoMT edge networks in an effective and efficient manner before they gain the trust of all involved stakeholders and reach their full potential in the market of next generation IoMT-based healthcare monitoring systems. In this context, blockchain technology has been foreseen by the industry and research community as a disruptive technology that can be integrated into novel security solutions for IoMT edge networks, as it can play a significant role in securing IoMT devices and resisting unauthorized access during data transmission (i.e., tamper-proof transmission of medical data). However, despite the fact that several blockchain-based security mechanisms have already been proposed in the literature for different types of IoT edge networks, there is a lack of blockchain-based security mechanisms for IoMT edge networks, and thus more effort is required to be put on the design and development of security mechanisms relying on blockchain technology for such networks. Towards this direction, the first step is the comprehensive understanding of the following two types of blockchain-based security mechanisms: (a) the very few existing ones specifically designed for IoMT edge networks, and (b) those designed for other types of IoT networks but could be possibly adopted in IoMT edge networks due to similar capabilities and technical characteristics. Therefore, in this paper, we review the state-of-the-art of the above two types of blockchain-based security mechanisms in order to provide a foundation for organizing research efforts towards the design and development of reliable blockchain-based countermeasures, addressing the pressing security challenges of IoMT edge networks in an effective and efficient manner.Entities:
Keywords: IoMT; anomaly-based IDS; authentication; authorization; blockchain; healthcare
Mesh:
Year: 2022 PMID: 35408064 PMCID: PMC9003194 DOI: 10.3390/s22072449
Source DB: PubMed Journal: Sensors (Basel) ISSN: 1424-8220 Impact factor: 3.576
Figure 1IoMT edge network architecture and key components.
Comparison of consensus protocols.
| Consensus | Type of Blockchain Used | Advantages | Limitations |
|---|---|---|---|
| PoW | public, permissionless | high security, malicious node tolerant | not efficient, high energy consumption, high computation cost |
| PoS | public, permissionless | power efficient, high security | concept of “stake” is not applicable in IoT |
| PBFT | permissioned | high throughput, | susceptible to Sybil attacks, poor scalability |
Figure 2PBFT diagram.
Figure 3Sequence diagram summarizing the workflow of the proposed scheme in [36].
Figure 4Sequence diagram of the proposed scheme in [38].
Figure 5Sequence diagram of the proposed scheme in [39].
Figure 6Sequence diagram of bubbles of trust [40].
Comparison of various blockchain-based authentication mechanisms.
| Reference | Type of | Advantages | Limitations | Implementation | Future Work |
|---|---|---|---|---|---|
| [ | Permissioned, Hyperledger Fabric | decentralization, simplicity, general application | - | Raspberry Pi, Hyperledger Fabric | Management of IoT sensors data |
| [ | Public, Ethereum Blockchain | decentralization, reduces latency, compliant to security requirements | transaction time delay and high energy consumption due to Ethereum properties | Ganache-cli, Ethereum emulator | Development of a lightweight consensus protocol for better results in terms of energy consumption |
| [ | Ethereum Blockchain | decentralization, device credibility, | needs credible users | Geth client, Ethereum, Ubuntu VM | Investigate zero-knowledge proof encryption, real implementation |
| [ | Public, Ethereum Blockchain | decentralization, scalability, resistant to attacks | not adapted to real time applications, no initialization phase, limited cryptocurrency rate | HP laptop- Ubuntu 14.04, Raspberry Pi–Rasbian 4.9.41, Ethereum | Controlled communication between bubbles, implementation of mechanism, design of a protocol for miner optimization |
| [ | Private, Hyperledger fabric 1.4 | suitable for password-based, certificate-based | high time complexity | virtual box 5.2.8, Ubuntu 16.4 server | - |
| [ | private, JUICE blockchain platform | decentralization, anonymity | - | Ubuntu | Consider the attribute-based cryptographic approach in order to achieve better access control |
| [ | - | authentication and confidentiality of data sharing | - | Anonymous authentication of IoT | |
| [ | Private Blockchain | decentralization, scalability | evaluation results are theoretical | Ethernet workshop | - |
| [ | Private, Hyperledger Fabric | decentralization, data privacy, data integrity, SSI | - | - | Implementation of the designed mechanism in real life applications |
Figure 7Centralized Approach [48].
Figure 8Distributed Approach [48].
Figure 9BlendCAC Block Diagram.
Figure 10BlendCAC System Architecture.
Figure 11(a) Delegation tree, and (b) Delegation graph.
Figure 12Architecture for the incorporation of blockchain into a CIDS.
Blockchain-based Authorization Mechanisms in IoT networks.
| Reference | Guarantees | Drawbacks |
|---|---|---|
| [ | Decentralization | Limited in Protected Health Information Storage systems |
| Availability | ||
| Confidentiality | ||
| Integrity | ||
| Immutability | ||
| [ | Lightweight, scalable, decentralized, and fine-grained access control solution for large-scale IoT systems. | Every domain involves a domain owner, which is a centralized entity; this might cause issues such as single point of failure, bottleneck, performance degradation, etc. |
| A token is stored on the Blockchain which is visible in every participant; this will raise privacy issues. | ||
| [ | More fine-grained access control and more flexible token management compared with existing capability-based AC schemes. | No results on the feasibility of the proposed scheme under a IoT healthcare system model, which involves several subjects such as users, doctors, nurses, etc. |
| Experiments based on a local Ethereum blockchain demonstrated the feasibility of the scheme in large-scale IoT systems. | ||
| Promising to achieve dynamic and fine-grained access control as ABAC introduces context information and the attributes of subjects and objects into its access control policies. More accurate access control in sensitive applications such as Healthcare by including sufficient attributes. Reduces the burden of maintenance, as access policies can be changed by simply changing the attribute values without the need to change the underlying subject–object relationships. | Although the prototype demonstrates the feasibility of the proposed framework, it can hardly reflect the performance of the framework in large-scale IoT applications such as Healthcare applications. The authors consider as future work the implementation of the proposed framework in environments with larger scales. |
Requirements for the design of an effective and trustworthy CIDS mentioned in [54].
| Requirement | Description |
|---|---|
| Accountability | Participating nodes must be held responsible for their actions. |
| Integrity | The integrity of the alert data should be guaranteed, since the accuracy of the detection depends on the alert data. |
| Resilience | The existence of single-points-of-failure (SPoFs) and the dependence of the system’s normal operations on a small group of nodes should be avoided. |
| Consensus | The proposed system needs to be able to reach a consensus regarding both the quality of individual alert data and the trustworthiness of each participating node. |
| Scalability | The proposed system needs to be scalable to a large number of participating nodes. |
| Minimum Overhead | The proposed system should incur minimum communication and computation overhead. |
| Privacy | The proposed system should provide the participating nodes with the ability to keep their alert data private and to selectively disclose alert data as they wish. Simultaneously, the requirements related to accountability and data integrity should still hold. |
Summary of implementation options for each design consideration mentioned in [54].
| Design Consideration | Implementation Options |
|---|---|
| Governance of the distributed ledger | 1. Public (permissionless) blockchain |
| 2. Consortium (permissioned) blockchain | |
| Consensus algorithm | 1. Proof-of-Work/Proof-of-Stake designs |
| 2. Practical Byzantine Fault Tolerance (PBFT) designs | |
| Peers participating in the consensus algorithm | 1. All nodes of CIDS participate. |
| 2. Only a subset of nodes of CIDS participate. | |
| Detail of alert data during the dissemination process | 1. Exchange of raw alert data |
| 2. Exchange of compact representations of the alert data (e.g., bloom filters [ | |
| 3. Hybrid (proposed by the authors): exchange of compact representations in the Consensus layer, and exchange of raw alert data in the Alert Exchange layer. | |
| Data encryption in the Consensus layer | 1. Symmetric key cryptography and distributing keys to specific participants. |
| 2. Exchange of compact representations of the alert data (e.g., bloom filters) |
Figure 13Federated learning in a network of devices.
Figure 14Architecture of the proposed system in [59].
Requirements of the two approaches described in [54,57,58,59] for blockchain-based IDS in IoT networks.
| Approach | Requirements |
|---|---|
| Record the alert data produced by IDSs | (1) The IoT devices participating in the blockchain network should possess enough computational resources to run the consensus protocol of the blockchain network. |
| (2) The IoT devices participating in the blockchain network should possess enough communication bandwidth to run the consensus protocol of the blockchain network. | |
| (3) The delay related to the inclusion of newly produced alert data to the blockchain ledger should be kept to a minimum. For this purpose, instead of raw alert data, hashes of the alert data can be stored in the distributed ledger. | |
| Support and enhance the federated learning IDS | (1) The IoT devices participating in the blockchain network should possess enough computational resources to run the consensus protocol of the blockchain network. |
| (3) The IoT devices participating in the blockchain network should possess enough communication bandwidth to run the consensus protocol of the blockchain network. | |
| (4) The delay related to the creation of the global trained model should be kept to a minimum. For this purpose, the separately trained ML model could be stored in the distributed ledger in a compressed form. |