Ontological Representation of Healthcare Application Security Using Blockchain Technology

1.1Motivation

EHRs are one of the most valuable assets in healthcare applications. The current healthcare applications follow the traditional technology infrastructure where a centralized individual is responsible for maintaining the EHRs (Dagher et al., 2018). Therefore, the traditional healthcare applications (THAs) suffer from diverse security threats (Xu et al., 2019) that could negate the confidentiality, integrity, and availability of EHRs. Consequently, the tampered medical data can cause major issues during the patient’s treatment. Besides that, there are risks of unauthorized access, information disclosure, and various internal and external threats. Mansfield-Devine (2016), Dagher et al. (2018) investigated the security of THAs, and findings show that organizations do not adhere to best practices when designing and developing healthcare applications. Moreover, the technology infrastructure is incompatible and does not provide security measures by design.

Security is critical in the acceptability of healthcare applications. The first motivation of our research is to identify the security threats of THAs and present blockchain as a countermeasure solution to mitigate them. The second motivation is to uncover potential security threats in BBHAs. Moreover, we aim to reveal what countermeasures are available to mitigate these threats to secure BBHAs. The advent of blockchain technology has opened several research areas to preserve medical data, ensure data integrity, patient ownership of their data, easy exchange of medical data, and seamless medical insurance claims. However, there is conceptual ambiguity and semantic gaps because of varied interchangeable security concepts. Such a gap brings confusion about how to treat security threats effectively (Saha et al., 2019; Linn and Koo, 2016) in healthcare applications. This constraint inspired us to build an ontological representation of healthcare information security. The ontological representation can be a helpful tool for assessing and communicating the security aspects of healthcare applications, allowing for timely decisions to fix them.

1.2Contributions

This work builds on the work presented in Iqbal and Matulevičius (2021b), in which we present blockchain-based healthcare security ontology (HealthOnt). HealthOnt demonstrates blockchain as a countermeasure solution to alleviate security threats of THAs. However, BBHAs do not become a silver bullet, and various security threats can appear (Iqbal and Matulevičius, 2019). Thus, we extended the HealthOnt with knowledge of BBHAs security threats. This work makes the following contributions:

Similar to our previous work, the above contributions rely on the security risk management (SRM) domain model (Dubois et al., 2010; Matulevičius, 2017). The domain model assists us in developing a framework for the security threats of BBHAs that contributed to the extension of HealthOnt. The HealthOnt can support the selection of blockchain when designing healthcare applications. There exist some comparable security models that address securing blockchain-based solutions (Arunkumar and Muppidi, 2019). However, such security models are either platform-specific or can not be updated upon appearing of new security threats. In contrast, HealthOnt encodes THAs’ and BBHAs’ information security into a dynamic ontology-based knowledge that can be extended, reused, and integrated with other security ontology representations.

1.3Paper Roadmap

The remainder of the paper is structured as follows: Section 2 overviews the blockchain, discusses the research method, related work, and back-pain patients’ healthcare application case. Section 3 presents the security threats that are mitigated in THAs through blockchain, and Section 4 discusses the security threats that can appear in BBHAs. Section 5 gives an overview of ontology development. Section 6 validates ontology, and Section 7 describes the emerging challenges in BBHAs. Section 8 concludes the paper.

2.1Blockchain

Blockchain is a decentralized, distributed, and immutable ledger technology (Ali et al., 2020). Blockchain creates a chain of blocks where a unique cryptographic hash links each block to the previous block. Blockchain eliminates trusted intermediaries from the transaction process, allowing for the development of transparent, yet secure applications (Rahmadika and Rhee, 2018) where network participants are managing the ledger blocks by themselves collaboratively. Blockchain networks can be classified as permissionless (e.g. Ethereum) or permissioned (e.g. Hyperledger Fabric (HLF)). A permissionless blockchain is fully decentralized and accessible to anyone who can join the network and participate in the consensus process (Junejo et al., 2020). Contrarily, a permissioned blockchain is partially decentralized with restrictions on who can join and access the operations. The designated authority establishes the structure of the blockchain network, as well as keeps control of various operations and processes (Jin et al., 2019).

Blockchain relies on the consensus mechanisms (e.g. Proof of Work (PoW), Proof of Stake (PoS), Practical Byzantine Fault Tolerance (PBFT)) to maintain the ledger state (Zhang and Lin, 2018). For example, Ethereum employs PoW, and HLF uses PBFT consensus. A smart contract in the blockchain is a piece of code that executes autonomously when certain conditions are met (Griggs et al., 2018). Smart contract eliminates trusted intermediaries, requires less human intervention, and reduces enforcement costs. Additionally, a smart contract prevents malicious or unintentional security threats (Jin et al., 2019) and enables decentralized distributed access control for resource authorization. Blockchain also provides provenance (Singh et al., 2021) to verify the record’s authenticity, while the ledger’s characteristic of tamper-evidence (Chukwu and Garg, 2020) allows to detect any interference or tampering with the content. Finally, blockchain provides pseudonymous characteristics (Iqbal and Matulevičius, 2021b). Such blockchain characteristics make blockchain an enticing technology in various application domains. These features support transparency, trust, and tamper resistance, which are key components in making business and transactional operations more secure, efficient, and effective.

2.2Research Method

We utilize the systematic literature review (SLR) since it allows the systematic analysis to identify relevant literature and synthesize the results. We follow the SLR guidelines of Kitchenham and Charters (2007) and define five research questions, each covering a different aspect of the SRM domain model.

RQ1: What are the assets to protect in healthcare applications?

RQ2: What are the security threats of THAs?

RQ3: What are blockchain-based countermeasures to mitigate security threats of THAs?

RQ4: What are the security threats that can appear in BBHAs?

RQ5: What are the countermeasures to mitigate security threats of BBHAs?

In this SLR, we use the primary search, backward and forward tracing techniques (Okoli, 2015; Fink, 2019) to collect the relevant studies. First, we performed a primary search based on search strings to identify an initial set of papers. Second, a secondary search was performed employing backward and forward tracing. We defined the search strings to gather literature studies that discuss the BBHAs and their security aspects.

Search string: ((“blockchain” OR “blockchain-based” OR “decentralized”) AND (“healthcare application” OR “eHealth” OR “healthcare services”)) AND (“security” OR “security threats” OR “security risks” OR “security risk assessment”))

We run these search strings on ACM Digital Library, IEEE Xplore, SpringerLink, ScienceDirect, Scopus, and Web of Science. We also included other non-academic research (e.g. gray literature). We applied exclusion (EC) and inclusion (IC) criteria to identify only the relevant papers (Table 1). For example, the papers that were duplicates, not in English, shorter than five pages, inaccessible (via university subscriptions or internet search), or published before 2008, were excluded (EC1 & EC2). We included the papers within the domain of blockchain and covering the security aspects of healthcare applications with blockchain (IC1), and providing blockchain-based countermeasures (IC2). To identify the security threats of BBHAs, we search for papers that discuss security threats of BBHAs (IC3) and countermeasures to mitigate them (IC4). The search resulted in approximately 1900 research papers from all the sources. First, we removed the duplicates and then performed several filtering iterations by considering the exclusion and inclusion criteria. A total of 90 papers remained that were subjected to full-text examination. After the full-text examination, a total of 39 studies remained that we used to conduct our research.

We utilize the SRM domain model (Dubois et al., 2010; Matulevičius, 2017) that helps to structure the security risk analysis of healthcare applications (Tables 3 and 4) that contributed in HealthOnt. Among other SRM approaches (Ganji et al., 2019), the SRM domain model fulfills the criteria of ISO/IEC 27001 standard and explores three aspects (e.g. assets-, risk-, and risk treatment-related) during the early phases of information system development. Based on the SRM domain model, the asset can be categorized as a system or business asset. The business asset has value, and the system asset supports it. Security criteria (confidentiality – C, integrity – I, and availability – A) distinguish business assets’ security needs and constraints. The risk constitutes the threat and one or more vulnerabilities. The threat targets the system asset and exploits the vulnerability. The vulnerability is connected to the system assets and depicts their weaknesses. Impact harms the business asset and negates the security criteria. The risk treatment implements the security requirements as countermeasures to improve the system security. Furthermore, we evaluate the ontology by performing the SRM of a back-pain patient’s healthcare application case.

2.3Related Work

While healthcare applications are getting ubiquitous, researchers are working to improve the security and privacy of these applications to an acceptable level. However, a number of surveys and literature studies have only focused on the technical perspective of security threats in healthcare applications (Table 2). The studies neglected the business context and the impact of security threats on business assets, also not following the SRM domain model to describe the relationships of security threats with the system. Moreover, the THAs are not fully leveraging the benefits of emerging technology (e.g. blockchain).

Table 2

Comparison of traditional healthcare applications.

For instance, Fatima and Colomo-Palacios (2018), Aljedaani and Babar (2021) review the common security threats and corresponding countermeasures considering only the technical side of the healthcare systems components. Similarly, Wani et al. (2020) investigated a few notable vulnerabilities in the hospitals connected to bring-your-own-device usage, the study reviewed the countermeasures to mitigate them. Still, they do not explicitly pinpoint the assets in the healthcare system targeted by the security threat and what business assets to protect. Sardi et al. (2020) explore the variety of existing security threats in healthcare facilities solely and briefly mention key assets. Still, they highlight the lack of risk assessment based on the specific needs of healthcare facilities and processes.

Some studies focus on controls to secure complex mobile, ubiquitous, and connected IoT healthcare systems. For example, Ahmadi et al. (2019), Iwaya et al. (2020) classified various countermeasures. However, they do not consider the context of such measures and do not describe how they can contribute to EHRs protection. At the same time, Yeng et al. (2021) present relatively complex security and privacy analysis of healthcare systems by investigating what assets to protect in healthcare, their vulnerabilities, and countermeasures. Table 2 illustrates that most of the literature reviews similar to our previous work (Iqbal and Matulevičius, 2021b) present a rather limited scope of analysis. Also, it is noteworthy that only a few studies mention blockchain technology as a countermeasure to THAs’ security threats. However, various organizations started working on BBHAs, for example, IBM-Blockchain (2022) is integrating blockchain in healthcare for better data sharing between healthcare providers without compromising data security, to overcome the drug counterfeiting (Martino et al., 2019), and so on.

In recent years, blockchain technology has gained interest in the healthcare domain and researchers presented blockchain as a countermeasure solution to mitigate security threats of THAs. For example, Saha et al. (2019) present a comparative analysis of healthcare applications that use blockchain-based healthcare solutions to protect against data tampering and data leakage. The survey of Hathaliya and Tanwar (2020) addresses the security and privacy concerns in healthcare. The authors explore the timeline of security attacks on medical data and various traditional security algorithms to defend against them. The traditional security algorithms are shown to be ineffective, and blockchain is used as an advanced architecture for the safe and secure execution of medical transactions and to maintain the security and privacy of digital medical records.

Linn and Koo (2016) describe the fundamental principles of blockchain to address the security and privacy issues of THAs. The study also discusses the technical advantages of blockchain in healthcare (e.g. faster and easier interoperability). Randall et al. (2017) present the different use cases to address the security and interoperability challenges of THAs. Chukwu and Garg (2020) perform the SLR to explore the trust, security, and privacy constraints of traditional EHRs and how blockchain plays a role in overcoming them. The SLR of Agbo et al. (2019) investigates the security challenges, including how blockchain can protect medical data from potential data loss, corruption, or intentional security attacks. Jin et al. (2019) present blockchain in healthcare for secure and privacy-preserving medical data sharing. The study argues that blockchain’s tamper-evidence and decentralization features could help build a secure medical data-sharing network.

The related works explore various security aspects without addressing vulnerabilities, what assets to protect, blockchain characteristics, and not adhering to any SRM domain model. Furthermore, the related works do not address the security threats and vulnerabilities that may arise in BBHAs. In contrast, we use the SRM domain model to analyse and compile the security threats of THAs and BBHAs. We also investigated the countermeasures to minimize them. To ease the SRM of healthcare applications, we provide an SRM domain model-based ontological framework (HealthOnt) that offers a dynamic knowledge base of security threats of THAs and BBHAs, vulnerabilities, assets to protect, and countermeasures to mitigate the security threats of both THAs and BBHAs.

2.4Back-Pain Patients’ Healthcare Application Case

In this section, we discuss a case of the back-pain patients’ healthcare application that we used to evaluate the ontology. This application is operating at Farhat Hached University Hospital in Sousse, Tunisia to illustrate our proposal. The case scenario is shown in Fig. 1, where the main stakeholders are the medical advisor, patient, and expert doctor. The scenario starts when the patient contacts the medical advisor for consultation. After the appointment, the medical advisor prepares the CNAM letter11 (including questions to the expert doctor) and attaches the necessary medical reports. The patient is then in charge of delivering the CNAM letter and the medical reports to the expert doctor. The expert doctor registers the patient’s data and collects additional information during the interview in order to define illness type (e.g. work accident or long-duration illness). For example, during the interview, the expert doctor collects whether the patient suffers from low back-pain, the type of sciatica, whether the patient is diabetic, and also asks for the personal information (e.g. marital status, number of children, and the last job type). Thereafter, the expert doctor identifies the illness and studies the necessary documents related to either the work accident or the long-term illness.

Fig. 1

Case of back-pain patients’ healthcare application.

Next, the expert doctor performs the patient’s physical examination and records results (e.g. weight, height, build, limp, and gait). During the physical examination, the expert doctor can check and verify the consistency of the claim. Then, the expert doctor writes a conclusion based on the gathered data (e.g. on the patient’s details, interview, and the physical examination outcomes). The expert doctor writes a medical report and sends it to the medical advisor. This report includes the conclusion about the patient’s medical status and guides the medical advisor regarding the decision (e.g. whether the medical leave is needed, what is the duration of the medical leave, and when the patient could return to work). We will consider this back-pain patients’ healthcare application case to illustrate the security threats and how they can be mitigated using blockchain technology.

3.1Data Tampering

THAs lack control over patients’ data security (Xu et al., 2019), which is a major concern for healthcare organizations. Blockchain provides various controls by design that can mitigate this threat. For example, smart contract-based distributed access control (Maesa et al., 2017) regulates the users’ access to stored medical data. Strong cryptographic primitives (Esposito et al., 2018) help to build fine-grained access control. In a blockchain, the records are difficult to modify and delete due to the ledger redundancy and append-only structure (Dagher et al., 2018). PoW consensus verifies transaction and data validation without a third party (Hussein et al., 2018). Also, using the SHA-256 hashing, blockchain computes a unique hash id of original data to verify the authenticity of data (Han et al., 2018). HLF uses trusted authorized nodes to verify and validate the authenticity of data (Chen et al., 2018). Blockchain is tamper-evident (Han et al., 2018) and thus detects any unauthorized modifications. Blockchain builds robust audit trails in an immutable ledger by keeping a record of each performed action (Bhuiyan et al., 2018).

3.2Data Theft

EHRs include confidential information that is attractive to cybercriminals that exploit various vulnerabilities in THAs to steal EHRs. In contrast, BBHAs are resistant to data theft. Blockchain works over a P2P network where nodes behave both as a server and client to send and receive data directly. This mechanism helps to protect the data leakage to unauthorized users (Chen et al., 2018). Dagher et al. (2018) used the voting process (e.g. QuorumChain algorithm) to determine which nodes are allowed to access certain types of data. The permissioned blockchains define permission settings to restrict unauthorized data access (Han et al., 2018). The strong cryptographic primitives (Esposito et al., 2018) and smart contract-based distributed access control (Hussein et al., 2018) allow only authorized users to access medical data. The ancile framework (Dagher et al., 2018) uses the proxy re-encryption to store hashes of data on-chain and off-chain. In addition, Esposito et al. (2018) suggests data obfuscation to protect data on-chain and off-chain.

3.3Medical Record Mishandling

Healthcare institutions must guarantee that medical records are kept confidential and secure. In THAs, the medical institutions control and manage the patient’s medical data where the non-relevant individuals can access it. BBHAs enable permission settings and distributed access control to handle patients’ medical data (Yaqoob et al., 2021). Also, blockchain performs data validation before saving on the ledger during the consensus process. For example, blockchain defines data validation rules which are agreed upon by other network nodes (Dexter, 2018). Thus, all the nodes follow those rules to validate the data and discard all the unauthorized changes (Shi et al., 2020).

3.4Counterfeit Drugs (Fake Medicine)

The creation and distribution of counterfeit pharmaceuticals is a global problem with significant health and economic consequences, primarily for consumers (Martino et al., 2019). According to Yaqoob et al. (2021), 10–30% (worth $200 billion) of drugs sold worldwide each year are counterfeit, posing significant health risks. Blockchain offers a solution to enable pharmaceutical traceability, real-time access to data, and supply chain validation by creating a log to track each step (Narikimilli et al., 2020; Yaqoob et al., 2021; Martino et al., 2019). For example, IBM Research uses blockchain to reduce or eliminate the drug counterfeiting problems in Kenya (Martino et al., 2019) by using immutable and traceable logs at each stage of the pharmaceutical supply chain.

3.5Man in the Middle (MitM) Attack

According to SpecOpsSoft (2020), MitM attacks are rising in healthcare applications to gain or manipulate sensitive information. Xu et al. (2019) introduce the blockchain-based distributed interplanetary file system (IPFS) for storage to establish a secure communication channel. Blockchain works on a P2P network that makes it hard for an attacker to intercept the communication, data analysis, or sniffing (Chen et al., 2018). Blockchain maintains pseudo-anonymity, for example, the patients and their medical data are linked with a cryptographic hash. Also, the data processing in a blockchain is anonymous (Yaqoob et al., 2021) that hides the actual identity from patients’ medical data (Ali et al., 2020).

3.6Single Point Failure

Like any other system, the attacker can find faults in the system’s design, implementation, or centralized dependency components to disrupt the healthcare services.

Vulnerabilities: Currently, the healthcare system uses a centralized server model (Xu et al., 2019) that can pose a threat of single-point failure and performance bottleneck. The weak mechanism to handle large numbers of requests (Shi et al., 2020) allows the attacker to target the server and services of the system to halt them for legit users.

Countermeasures: Blockchain is resilient to this threat with the advantage of a decentralized distributed P2P network (Narikimilli et al., 2020). Moreover, blockchains do not rely on a single or central point server (Xu et al., 2019; Shi et al., 2020).

3.7Repudiation

The patient’s medical data is sensitive and life-critical. The healthcare system should trace all actions performed (intentionally or unintentionally) by the authorized users on a patient’s medical data and easily identify how it was performed.

Vulnerabilities: In THAs, there are weak controls to prove illegal data changes by authorized users (Kleinaki et al., 2018). For example, almost every stakeholder within a medical institution has access to the patient’s medical data that can be viewed, modified, or deleted. Moreover, unintentional data changes can happen that later are not traceable during data processing. The THAs manage centralized and mutable logs (Griggs et al., 2018) that are handled (or have access) by a system administrator or other IT staff. Also, if the system is compromised, the attacker can easily remove the actions he performed from logs. Therefore, the authenticity of logs can not be proved on centralized systems.

Countermeasures: Blockchain keeps immutable logs (Griggs et al., 2018) to track who and when the particular operation was performed. Also, Kleinaki et al. (2018) use the blockchain-based versioning scheme to track each performed operation over time.

3.8Insurance Fraud

Healthcare insurance frauds are increasing, which involves the filing of dishonest healthcare claims. For example, the value of challenged healthcare claims surged from $11 billion to $54 billion annually (Narikimilli et al., 2020).

Vulnerabilities: In THAs, there is a lack of proper authenticity (Martino et al., 2019) to verify the insurance claim because of complex information systems, administrative burdens, expensive & manual validation and verification of provider directories, and record-keeping mistakes that attracts the attackers.

Countermeasures: The blockchain enables the decentralized verification of insurers based on the predefined set of rules (Martino et al., 2019) before registering on the ledger. Once the insurer is verified and registered, the records are distributed among other nodes to keep track of valid and invalid insurers in the system.

3.9Clinical Trial Fraud

Reproducible data is the lifeblood of advanced research across the globe. Currently, the healthcare institutions and research groups suffering from clinical trial frauds (George and Buyse, 2015) and medical decisions made by researchers on the premise of fraudulent data could leave patients at risk.

Vulnerabilities: The data frauds in clinical trials include deliberate fabrication, falsification, or plagiarism in proposing, performing, or reviewing research and research results (George and Buyse, 2015). The inadequate clinical trial data (Martino et al., 2019) emerge due to a lack of data integrity and provenance. Also, the current infrastructure has inefficiencies in patient recruitment and access to medical data (Narikimilli et al., 2020).

Countermeasures: The distributed nature and use of cryptography ensure data is authentic (Martino et al., 2019). Also, blockchain provides data ownership to patients (Dagher et al., 2018) to control the access of their data and once data is saved on the blockchain, it cannot be altered. Thus, eliminating the threat of clinical trial fraud.

3.10Tampering Device Settings

Medical devices connected to the internet and the internet of things (IoT) enable healthcare professionals to be more watchful and connected with the patients. Progressively, IoTs are becoming the heart of digital healthcare, but new security challenges are appearing.

Vulnerabilities: In healthcare, the medical devices are subject to heedless settings (McGhin et al., 2019) (e.g. lack of network segmentation, insufficient access control, and reliance on legacy systems). The intentional changes in device settings (e.g. from the attacker) or unintentional changes (e.g. from the authorized user) can lead to false readings that put the patient’s life in danger.

Countermeasures: Blockchain follows the append-only structure to save data. Thus, device settings stored in blockchain are distributed and immutable (McGhin et al., 2019).

3.11Social Engineering

According to HelpNetSecurity (2019), only 1% of cyber-attacks in the year 2019 were exploited due to hardware or software vulnerabilities, and 99% of cyber-attacks utilized some form of human intervention (e.g. phishing, fake identity, honey trap, etc).

Vulnerabilities: In healthcare, the healthcare staff is one of the weakest points and the attackers use social engineering techniques (Ali et al., 2020) to target them to get patients’ medical data. Healthcare staff is vulnerable to social engineers because they naturally trust others, do not want to be rude, have a desire to be helpful, and find it difficult to remember everyone in a large healthcare environment (SecurityMetrics, 2015).

Countermeasures: Maesa et al. (2017); Dagher et al. (2018) implement smart contract-based distributed access control that ensures only relevant users have access to particular information or part of the information. Thus, protecting medical data against unauthorized user access. However, the threat of social engineering can not be eliminated through new technology or a more secure password, but it can be restricted to an acceptable level by proper training of employees (SecurityMetrics, 2015).

The security risk analysis of traditional healthcare applications shows that blockchain can help the healthcare sector to overcome the security threats of traditional technology infrastructure for preserving the medical data, data integrity, and patient ownership of their data. We use the constructs of the SRM domain model that fulfills the criteria of ISO/IEC 27001 standard (Ganji et al., 2019) for defining the scope of our work and to assist in building a framework for structuring the security risk analysis of traditional and blockchain-based healthcare applications. This framework (Table 3) presents blockchain as a countermeasure solution for mitigating the security threats of THAs. Blockchain provides technology infrastructure with unique characteristics for building healthcare applications. For example, blockchain operates over a P2P network, uses consensus mechanism and cryptography, is immutable, decentralized, tamper-evident, and provides permission settings, provenance, and pseudo-anonymity. However, we cannot deny the security aspects of BBHAs because in recent years various security threats have appeared in blockchain-based solutions. Hence, we discuss such security threats in the next section.

4.1Sybil Attack

Sybil attack is a P2P network attack (Douceur, 2002) where the attacker creates numerous fake identities and connects with victim nodes to isolate them from other honest nodes.

Vulnerabilities: Blockchain systems run over the P2P network, and therefore they are susceptible to Sybil attack. The attacker can control several nodes on BBHAs by creating fake identities (Iqbal and Matulevičius, 2021a; Rahmadika and Rhee, 2018) to gain disproportionately large influence. Once Sybil nodes gain recognition, the attacker forces victim nodes to process blocks under his control, out-votes (or blocks) the honest nodes, interrupts the flow of information, distorts the block generation process, and refuses to receive or transmit information (Zhang and Lee, 2019). Also, if the blockchain system has insufficient computing-power (Sayeed and Marco-Gisbert, 2019), the attacker with higher computing power exploits this limitation by using Sybil nodes and disrupting the healthcare operations. Moreover, the poor implementation of node authentication (Swathi et al., 2019) (e.g. no network joining fee, not validating IP address, or source of node connection) negates the integrity of the transaction verification process.

Countermeasures: To overcome Sybil attacks in BBHAs, incorporate network joining fee (Swathi et al., 2019) and stake requirements in PoS consensus (Banchhor et al., 2021) to make identity creation more expensive. Monitor node behaviour (Swathi et al., 2019) to spot any unusual activity of nodes and disconnect them from the network. If the system uses PoW consensus, the network should have enough computational power (Sayeed and Marco-Gisbert, 2019) based on the network’s available nodes. Regularly monitor the computing power to ensure no one is misusing it. In addition, before joining the blockchain network, perform node authentication. For instance, requesting a network joining fee, validating node connections, and monitoring node activities (Swathi et al., 2019).

4.2Double-spending

The double-spending is categorized under data consistency attack (Nicolas et al., 2021) to spend the same transaction twice (Pérez-Solà et al., 2019). Similarly, in BBHAs, the attacker can change the transaction state and spend the same transaction twice.

Vulnerabilities: The attacker uses 51% or more computing-power to control the network (Ratta et al., 2021) to weaken the P2P network to perform double-spending (e.g. insurance frauds) (Iqbal and Matulevičius, 2021a). This vulnerability can also affect the availability of network resources, the attacker can trigger selfish-mining, prevent new transactions from gaining confirmations, and blockchain forks (El-Gazzar and Stendal, 2020). However, this vulnerability is practically impossible on high computing power blockchains (e.g. Bitcoin and Ethereum) (Iqbal and Matulevičius, 2021a). Moreover, accepting unconfirmed transactions (Pérez-Solà et al., 2019) enables the attacker to indulge in a race to make his double-spend transaction valid by exploiting the intermediate time between two conflicting transactions and using a higher transaction fee. If it is successful, it negates the integrity and availability of fast transaction mechanisms and the loss of digital assets (such as insurance claims) and the ledger’s integrity.

Countermeasures: Implement a power monitoring tool to monitor the computing power of nodes continuously and restrict when reaching a certain amount of computing-power (Alcarria et al., 2018). Also, incorporate transaction fee (Jonathan and Sari, 2019) as an incentive to keep nodes honest in a blockchain system. Use a pluggable consensus mechanism (Dinh et al., 2017) to facilitate consensus diversity based on the blockchain system’s requirements. Furthermore, Rosenfeld (2014) states that increasing the number of confirmed blocks would decrease the double-spending threat. Grunspan and Perez-Maro (2018) present a closed-form formula to calculate the likelihood of double-spending in a race attack. In addition, enhance network policy (Nicolas et al., 2021) to guide about how to set a block confirmation number considering the value of the transaction.

4.3Eclipse Attack

In an eclipse attack, the attacker takes control of all the neighbuoring peers of the victim node and hides the correct ledger from the victim node (Rahmadika and Rhee, 2018).

Vulnerabilities: Eclipse attack targets particular node (Zhang and Lee, 2019) by flooding with his IP addresses. The attacker poisons victim node’s routing table (Rahmadika and Rhee, 2018) by filling it with his IP addresses. Once the node restarts, it loses its current outgoing and incoming connections and makes the new connections with the attacker’s IP addresses. If the attack is successful, the attacker inhibits the victim node from learning about the rest of the blockchain network by preventing it from communicating with other peer nodes, disrupting the transaction verification process, and gaining access to the medical data. Moreover, this attack allows the attacker to alter transactions to perform double-spending and selfish mining (Rahmadika and Rhee, 2018).

Countermeasures: The first countermeasure is to stop direct incoming connections (Henningsen et al., 2019; Heilman et al., 2015) and make incoming and outgoing connections via white-listed nodes (Heilman et al., 2015), such as well-connected peers/miners, to prevent the eclipse attack. Also, include a random outgoing connections method (Henningsen et al., 2019) to prohibit all connections with the attacker’s IP addresses. Use deterministic random eviction (Heilman et al., 2015) to keep track of new and tried connections. It minimizes the number of attack addresses used by the attacker when making connections. Moreover, the feeler connections (Heilman et al., 2015) to make short-lived test connections with randomly-selected addresses. If the connection is successful, the address includes in white-listed nodes. The anchor table method (Heilman et al., 2015) allows to keep track of current outgoing connections, and when the node restarts, it selects and makes a connection with the old addresses from the anchor table.

4.4Smart Contracts Attacks

The security of smart contracts has become a major concern in recent years (Singh et al., 2021) as a result of different security issues originating in blockchain-based applications from the execution of smart contracts.

Vulnerabilities: The security issues in smart contracts are associated with the bugs in the source code (e.g. transaction-ordering dependency, timestamp dependency, mishandled exceptions, reentrancy, unpredictable state, transaction overflow, and underflow, etc.) (Singh et al., 2021; Sayeed et al., 2020). According to Li et al. (2020), in Ethereum around 45% smart contracts are vulnerable and the attacker can exploit faulty and error-prone smart contracts (Sayeed et al., 2020) to harm the valuable assets in BBHAs. For example, Ethereum smart contract reentrancy attack on the decentralized autonomous organization (DAO) when the attacker stole $60 million Ethers (Singh et al., 2021). Many blockchain platforms are introducing smart contracts to construct decentralized applications, but their security has yet to be fully studied (Sayeed et al., 2020). In BBHAs, the attacker can exploit these vulnerabilities and target the digital assets, steal or modify the medical data, and interrupt the medical operations (Musamih et al., 2021).

Countermeasures: The developers should employ smart contract code analysers to discover flaws, race situations, and sanitize the smart contract code before deploying it on a blockchain. For example, the SmartCheck (Musamih et al., 2021) to detect vulnerabilities in the smart contract at different severity levels, Oyente tool (Musamih et al., 2021) to detect callstack depth and re-entrancy attacks. On top of these, use penetration testing tool (Bhardwaj et al., 2021) to test blockchain-based applications before deployment.

4.5Block Withholding Delay

In PoW-based blockchains, a block withholding delay is common. The attacker miner joins a victim mining pool and refuses to submit blocks on time (Liu et al., 2019).

Vulnerabilities: The attacker miners deliberately delay the submission of valid blocks (Liu et al., 2019) that results in the discarding of the blocks that can distort the operations of BBHAs. Also, the strategy leads the attacker to gain higher rewards than honest mining nodes (Tosh et al., 2017). In BBHAs, this attack can hinder medical operations and delay block confirmations needed for the transaction finality.

Countermeasures: To mitigate this attack, the system should enforce an immediate block submission (Guru et al., 2021) to submit the block as soon as it is found. Moreover, implement an incentive payoff scheme (Liu et al., 2019) to increase the risk of earning fewer incentives to demotivate those who deliberately delay block submissions.

4.6Sybil-Based DoS

Blockchain-based applications operate over a P2P network. Despite being operated on a P2P network, they are still vulnerable to DoS attacks (Guru et al., 2021).

Vulnerabilities: By design, permissionless blockchains let anybody participate in the consensus process. The attacker takes advantage of this situation by participating in the consensus with his Sybil nodes (Quintyne-Collins, 2019) to postpone medical operations and interrupt the mining process. Also, the attacker creates numerous dust transactions (Wang et al., 2018) between his Sybil nodes, and blockchains process a limited number of transactions per block in a given time. The Sybil nodes participating in the consensus do not share their verified transactions or blocks. Thus, the large number of transactions with small values congest the blockchain network (Iqbal and Matulevičius, 2021a), delay the medical operations, exhaust the network resources, and halt the mining process.

Countermeasures: The Sybil-based DoS attacks cannot be mitigated entirely but it is possible to restrict them. For example, incorporate computational constraint-based Sybil resistance techniques like Bitcoin uses PoW (Quintyne-Collins, 2019). Moreover, utilize the anti-dust model (Wang et al., 2018) that checks different parameters in the transaction (e.g. transaction volume and fees) to identify and prevent dust attacks (Wang et al., 2018).

4.7Deanonymization Attack

Anonymization is a characteristic of blockchains that refers to hiding an identity, but still possible to link a user or company behind each transaction (Quintyne-Collins, 2019).

Vulnerabilities: Patients’ privacy is the utmost requirement in healthcare. However, in BBHAs, it is possible to identify the patient by performing network analysis and listening (Junejo et al., 2020; Biryukov and Tikhomirov, 2019). For example, analysing the transaction contents, transaction relationship with other transactions, and the way the transaction is broadcasted. Moreover, the attacker can perform graph analysis (Junejo et al., 2020) on publicly available transactions to deanonymize the identities of patients.

Countermeasures: Narayanan et al. (2016) use the mixers as a service to enhance the privacy and anonymity of transactions by obfuscating the transaction flow. Biryukov and Tikhomirov (2019) suggests using anonymity overlay networks such as Tor. Moreover, incorporate ring signatures and zero-knowledge proofs (Junejo et al., 2020) to achieve the required level of privacy on medical data, and users get only relevant information.

4.8Quantum Computing Threats

Quantum computing research is advancing, and many cryptographic protocols in use currently are vulnerable to quantum computing (Shankland, 2021). Blockchain platforms rely on cryptographic protocols that are also vulnerable to quantum computing.

Vulnerabilities: The quantum computing threat is real, and blockchain platforms are not using quantum-resistant cryptography (Yaqoob et al., 2021; Velissarios et al., 2019) to tackle it. Thus, the BBHAs are vulnerable to quantum computing (Gao et al., 2018) in a post-quantum era. For example, blockchain platforms are using an elliptic curve digital algorithm (ECDSA) that is not a quantum-resistant cryptography scheme, and it could be solved by quantum computers (Gao et al., 2018).

Countermeasures: The blockchains should implement quantum computing resistant cryptography schemes (e.g. lattice-based, multivariate, hash-based, code-based cryptography) (Yin et al., 2018). For example, Yin et al. (2018) implemented the anti-quantum transaction authentication scheme using lattice-based cryptography. Gao et al. (2018) present the post-quantum blockchain using a lattice-based delegation algorithm.

4.9Endpoint Vulnerability

The easy way of attacking technology solutions is through endpoint vulnerabilities, which occur where humans and technology interact (Velissarios et al., 2019). Hence, the protection of endpoints is paramount in BBHAs (Velissarios et al., 2019).

Vulnerabilities: The attacker coerces the victim through social engineering or phishing into using numerous strategies that are under his control (Radhakrishnan et al., 2019). For example, the flawed key generations and signatures tool exposes users’ private keys. Moreover, the lack of awareness and knowledge about security could trigger the endpoint vulnerability (Velissarios et al., 2019). For example, if the attacker learns about the private key, he can utilize it to acquire access and ownership of data. Anyway, endpoint vulnerabilities remain susceptible through social engineering, real-world theft, or physical access to user wallets, phones, or computers (Velissarios et al., 2019).

Countermeasures: To minimize endpoint vulnerabilities, implement a multi-level authentication method (Radhakrishnan et al., 2019) when accessing wallets or generating wallet keys, use multi-signature wallets, cold wallets, and do not share private keys of wallets with anyone. Users should be aware of social engineering, always use authentic and legitimate sources to protect against phishing, and utilize hardware security modules (Radhakrishnan et al., 2019; Velissarios et al., 2019).

4.10Other Security Threats

In this section, we outline numerous possible security threats of blockchain systems (Table 5) that have yet to be studied in BBHAs but may appear. Therefore, blockchain developers and practitioners should be aware of these security threats.

We build this framework (Table 4) aiming to provide the details about the security threats that may appear in BBHAs, and the controls to mitigate them. Both frameworks (Tables 3 and 4) complement one another in the context of the SRM constructs we used. However, the aforementioned frameworks represent the knowledge base in a static manner and are difficult to update when new security threats, vulnerabilities, or countermeasures appear. To overcome these issues, we build a blockchain-based healthcare security ontology, HealthOnt, where these frameworks serve as a foundation.

6.1Analysis of the Back-Pain Patients’ Healthcare Application Case

We use HealthOnt to map the healthcare applications’ security knowledge on a back-pain patients’ healthcare application (BPPHA), described in Section 2.4. HealthOnt helps to identify the security threats of it that are highlighted as threat points in Fig. 2.

Threat Point 1: Due to the weak access control mechanism to share CNAM letter, the unauthorized user can get access and tamper it. Also, the patient can intentionally or unintentionally tamper the CNAM letter. In both cases, the system does not have a proper mechanism to verify and validate the legitimacy of the CNAM letter.

Fig. 2

Mapping of security threats that can appear in traditional BPPHA using HealthOnt.

Threat Point 2: The data tampering can happen on medical reports due to weak centralized access control. Thus, an unauthorized user can access the patient’s medical reports and tamper them. In the current system, the medical reports are stored in human-readable formats (e.g. PDF, docs, Xrays), and no proper cryptographic controls (e.g. encryption) are implemented. The attacker can access them to pursue various activities (e.g. insurance frauds, wrong drug prescriptions). The data theft undermines the confidentiality of medical reports and patient privacy, eventually jeopardizing the integrity and trust of the system. Furthermore, the patients have weak control over their medical reports. For example, medical institutions control and manage the patient’s medical data where non-relevant individuals can access and manipulate it. Thus, the current BPPHA does not guarantee the authenticity of electronic medical reports.

Threat Point 3: The attacker can exploit the weak controls of secure communication to get medical records, medical reports, and CNAM letter. Moreover, due to the lack of anonymization of patient medical records, the medical data is associated directly with patient identity. With the MitM, the attacker can sniff the data to pursue various activities (e.g. publishing the data online or ransomware attack). The MitM attack can affect the data exchange, medical records, medical reports, CNAM letter, and communication assets.

Threat Point 4: The patient’s medical data is life-critical, and the healthcare system should trace all actions performed (either intentionally or unintentionally). The BPPHA does not use immutable logs to maintain track of all actions taken on a patient’s medical data over time. As a result, the existing system lacks a means for proving intentional or unintentional modifications to a decision of a patient’s medical status.

Threat Point 5: Weak centralized access control refers to a situation in which the system fails to prevent unauthorized access to the database. The attacker breaches security and performs unauthorized actions that negate the integrity of medical records and healthcare database. Currently, the BPPHA does not have any security or cryptography controls to protect the database from data theft attacks. Overall, this threat negates the confidentiality of medical records, healthcare database, and patient privacy. Also, the BPPHA has a centralized database server and network services. The attacker can locate the flaw in the design or implementation of the systems and cause database overhead or disables the medical services, essentially shutting down the whole system.

Threat Point 6: BPPHA is also vulnerable to social engineering, where patients and hospital personnel are the weakest links. The attacker can target them using social engineering tactics (e.g. phishing, false identity, honey trap) to get the CNAM letter.

6.2Blockchain as a Countermeasure Solution

We present blockchain as a countermeasure solution (Fig. 3) to illustrate the blockchain-based BPPHA that implements various security controls by design and mitigates security threats of traditional BPPHA. For example, the blockchain-based role-based access control (RBAC) can restrict access to the CNAM letter. Blockchain provides a consensus mechanism to verify and validate the CNAM letter transaction without requiring a third party, a unique hash id of the original CNAM letter stored in the blockchain to verify its authenticity, and an immutable ledger to keep track of each performed action. Similarly, medical reports can be protected against data tampering using RBAC and blockchain-based controls to verify and validate the authenticity of medical reports. The use of RBAC and cryptography (e.g. to store only encrypted medical reports on-chain and off-chain) overcome data theft. Also, the permission settings and access control enable patients to control their medical reports, and the tamper-resistant environment of blockchain guarantees the authenticity of medical reports.

Fig. 3

Blockchain as a countermeasure solution to mitigate security threats of traditional BPPHA.

Blockchain-based BPPHA works on a P2P-based distributed network to exchange data (e.g. CNAM letter, medical reports, medical records). It makes it hard for an attacker to intercept the communication, data analysis, or sniffing. Blockchain enables pseudo-anonymity because the patients and their medical data are linked with an anonymous public address. Blockchain-based BPPHA has an immutable ledger that keeps immutable logs to track who and when the particular operation (intentional or unintentional) was performed. Thus, overcoming the repudiation threat. Medical records and healthcare database can be protected against data tampering by using decentralized access control and blockchain controls to verify and validate the authenticity of medical records and healthcare databases. Decentralized access control and cryptography overcome the threat of data theft. Moreover, blockchain is decentralized, operates over a P2P network, and does not rely on a single or central point server and service. Thus, it is resilient to a single-point failure. Blockchain-based BPPHA employs RBAC to guarantee that only relevant people have access to specific information, and unauthorized users cannot access it.