1. Introduction
Recent trends in technology are exploited for diverse real-world applications to provide definite solutions for end users. Assimilating technological aspects in user-related application provides diverse advantages, from the quality of service (QoS) to security [
1]. The healthcare platform is visualized using electronic health records (EHRs) in its digital and technical format, providing unrestricted access to the end users. Diagnosis centers and healthcare infrastructures provide different access and data sharing processes for their users through EHRs [
2,
3,
4]. EHR is an organized set of patient-/user-related information that is digitally shared through a secure platform for ubiquitous access [
5]. User applications and graphical user interfaces designed for EHR access provide access to the healthcare data through simple authorization and authentication procedures. Since sensitive information, end-to-end security, and privacy are the prime concerns in sharing EHR’s between users [
6], this is vital as the technology requires additional infrastructures such as cloud, Internet of things, mobile devices, etc. for sharing EHR’s [
7].
Blockchain is another technology that is commonly used in different applications for providing distributed access to resources and unalterable information [
8]. The blockchain paradigm is used for administering security in different communicating and processing systems. Healthcare application does not require trusted third-parties for administering security [
9]. The electronic ledger is distributed across different communicating and processing systems to improve the swiftness in security administration and privacy preservation [
10]. Besides, blockchain eases EHR sharing between end-user applications and healthcare infrastructures without interrupting the communication process [
11,
12]. Such facilities are provided through line-of-trust and authentication with interoperability using the distributed electronic ledger technology. Modern healthcare applications concentrate on the privacy of the users and security of the information shared to prevent anonymous and unauthorized access to illegitimate users [
13,
14].
Trust, authentication, and privacy are the major requirements in sharing EHRs between different users. Administering the blockchain paradigm as a decentralized ledger for monitoring shared information is becoming a familiar practice in recent years [
15,
16]. Blockchain-assisted authentication and trust-based security are assimilated with the medical systems for improving the quality of information sharing and preventing unauthorized interruptions [
17,
18]. Knowing the significance of the data, biomedical systems rely on robust authentication and trust schemes for confronting diverse attacks, data leakage, tampering, and loss. EHR access control, defining security levels, verifying users, and sharing sessions are collaboratively performed using the security systems [
15,
17,
19]. Modified and sophisticated access control, encryption/decryption schemes, and auditing features are required to handle different attacks and illegitimacy in storing and sharing EHRs. In trust-based schemes, user-centric factors are assessed to differentiate the users to provide access controls, whereas authentication schemes focus on providing data/EHR security through hashing and encryption/decryption process [
20,
21].
However, blockchain refers to the distributed ledger technology, which constitutes an innovation in the information recording and sharing without a trusted third party. In this paper, Blockchain and Distributed Ledger based Improved Biomedical Security system (BDL-IBS) has been proposed to enhance the privacy and data security across healthcare applications.
2. Related Works
Tang et al. [
22] proposed privacy-preserving healthcare in the trusted network to enhance the trustiness among the patient and caregivers. The Sybil attack is used to find the fake patient and terminate it from the network. The proposed method is used to make the authenticated person access the healthcare center.
Computer-aid design is implemented for security, and privacy of the trusted systems is introduced by Salnitri et al. [
23]. It also gives the specification of experts to use the system from various characteristics. They are also using the higher goal for the business, and external threats are maintained for the trustworthiness in the network.
S-Alex convolution neural network and dynamic game theory (SCNN-DGT) designed by Kong et al. [
24] are used in the IoT-cloud computing environment for health data management. The initial step is obtaining the information of the healthcare and classifying them in Alex’s net convolutional network. This method is designed to evaluate security in the healthcare system. It validates the index screening to verify the user.
Data integrity is used for sharing the records of healthcare in a verifiable way and is introduced by Wang et al. [
25]. The author developed a blockchain for privacy usage through symmetric encryption and attribute-based encryption. It attains the fine-grained access control.
Zhao et al. [
26], developed key management for healthcare blockchain. The efficient key management method is used as a privacy and security mechanism in the healthcare system. It is observed by embedding the sensor to analyze the blockchain. The proposed method is used to enhance the effectiveness and high security.
Guo et al. [
27] modeled a multi-authority for the Tele-medical system to improve the efficient blockchain based on the ABE scheme. In this paper, both the dynamic authentication and authorization are used for MoD service under telemedicine. ABE is mainly used to manage the system in real-time scenarios for private healthcare data. This is done in a cloud-based environment.
A blockchain is proposed for the medical records to access and permits the MedChain process, which is addressed by Daraghmi et al. [
28]. Medchain is used for interoperating, secure, and effective access for patients’ privacy. The security is time-based access that gives the degree of health providers.
A blockchain is used for the Electronic Health Record system (EHRs) and is proposed by Guo et al. [
29]. The authors implemented a secure attribute based on signature with multi authorities. The patients send the text according to the health as the attribute evidence to the healthcare center. The trust is given to the authorities to access the message, and both use the public and private keys to avoid the escrow problem.
The medical service framework is designed to store the secure records of the patient by using the blockchain method and is introduced by Chen et al. [
30]. The storage is done on the cloud for large data access. The records are shared by its aspect based on its service related to the authorized user.
Tian et al. [
31], observed medical data management with private access. The blockchain is used to protect the data in two aspects such as storing the data in the local database, encrypting the data, and sharing the key to the patient for further viewing. The shared key for security and integrity is established using sibling intractable function families (SIFF) aided by blockchain. The proposed method uses integrity, availability, and privacy of medical data for better efficiency.
Wang et al. [
32] presented an e-healthcare system by using Wireless Body Area Networks WBAN. The blockchain is used to generate security and resolve the low power healthcare system. The WBAN is placed in the patient’s body and transmits the data by using the blockchain process.
A blockchain -based healthcare system using formal methods is developed by Brunese et al. [
33]. This paper aims to exchange information from the patients to the hospital network by using magnetic resonance images. The data are transmitted by the formal equivalent for validation. They are modeled by radiomic features for automata.
Uddin et al. [
34] proposed blockchain leveraged decentralized eHealth architecture (BDeHA). This architecture consists of three layers, including a sensing layer for obtaining the data through the sensor. The second is NEAR processing for sensing the IoT devices and the third one is FAR processing, which is comprised of cloud computing servers.
Griggs et al. [
35] observed a healthcare blockchain using smart contracts for patient monitoring. The smart contracts are used for secure analysis management for communication with the sensor. They are also used to monitor the patients and professionals to give notification regarding the health.
Brodersen et al. [
36], globally and across several industries, present an innovation model that will allow business to business-and-consumer transactions to be faster, more efficient, and highly secure. Many healthcare participants hope the same distributive database technologies allowing this new model can lead to similar outcomes within the industry and recognize that confusion, like many other major innovations.
3. Blockchain and Distributed Ledger Based Improved Bio-Medical Security System
The proposed BDL-IBS is designed to improve the trust- and privacy-related specifications of the electronic shareable health records. The system focused on maximizing the sharing rate of the secured records along with less adversary impact. In this system, blockchain technology is exploited by the medical server that tracks the trust privacy factors between the users and records. In
Figure 1, an illustration of a biomedical security system with blockchain technology is presented.
The components of the bio-medical system include storage and a medical server. The storage contains the health records of the end-users in a digital format. The medical server is responsible for processing user requests and responding to them with appropriate records. A common sharing platform such as cloud and associated infrastructures are responsible for sharing EHRs. The blockchain and distributed ledger are used in both the medical server and end-user applications. In the blockchain associated with the medical server, the trust and privacy factors are analyzed, whereas the privacy factors are alone assessed in the end-user blockchain. The trust factors include successful access and response to request ration, and privacy relies on convergence and complexity. The trust process is analyzed and explained in detail in the following subsections.
Adversary Model: In this bio-medical security system, malicious access due to man-in-middle and data tempering adversary models are considered. In a man-in-middle attack, the adversary overlaps the end user to gain access to the HER. This results in sharing health information to an adversary and thus degrading the design of a secure biomedical system. In the case of a data tempering attack, the adversary breaches HER from any node communicating with the biomedical system. It either modifies the actual data/tracks the communication through the HER information.
Figure 2a,b portrays the representation of the man-in-middle and data tampering attacks over the EHR.
For thwarting the above attack, the trust model and concentric authentication are introduced using the blockchain paradigm. As referred to earlier, the blockchain process is differentiated in both the medical server and end-user functions.
Apart from the regular two-layer network, the man-in-middle attack can be overcome by the server-client based blockchain technology as shown in
Figure 2c. Since it is a server–client network, it is well suited for the medical user and end-user functions. To reduce the man-in-middle issue, a pure application-oriented implementation is followed in the objective of the proposed idea. A proper set of protocols should be determined in the server domain, and the appropriate application receives the data from the client side.
The process of trust-based validation is performed using linear decision-making, and authentication is augmented through classification-based learning.
Trust model based on Linear Decision Making: In the trust model, the factors are successful access and end-user application to fetch HER. Through conventional communication standards, the end-user application generates a query for accessing HER. The initial authorization for the end-user is provided using login ID/name and password information. This information is validated by the medical server to ensure the reputation of the user. The medical server is associated with the blockchain with the following entries, as in
Table 1.
For each
generated and received in the medical server, the state of
(i.e., sharing EHR), the factors
and
are updated. This information remains unchanged in the blockchain paradigm. It is to be noted that
is valid for
, within which the sharing of EHR is completed. For any case of
, the
and the user is marked as illegitimate. For validating the above conditions,
is computed as a linear combination of
and successful access probability
. In a given
, the
is computed as
The factor
is the ratio of response to the query request received by the medical server. The linearity in identifying the trust for a period of
relies on
and
, where both the factors are proportional to each other. The above linear relationship between
and
is
is recurrently analyzed using the
instance, i.e., the
in all
instances is verified from its previous shared count that is given as
From the above sequence, the varying
or
in
is estimated for all the
shared to the end-user. In this sequence, the varying point
initiating the change in proportionality between
and
is identified. Such identification helps to reduce the computations and security mechanisms (authentication) to prevent losses in sharing EHR. This point from the sequence
is computed using Equation (3) as
This validating point helps to hold the verification process and trust update in the blockchain, where the actual
is updated until
sequence. The decision for pursuing/halting EHR sharing is determined using the conditions formulated in
Table 2.
The last three conditions in
Table 2 represent the unfeasible conditions as
results in a negative
that is not possible in case
. Similarly, the sequence and instant trust are the same in case of sharing only 1 record, after which
. This provides continuous chances for EHR sharing, whereas, in practical EHR based biomedical systems, the condition does not hold. For
condition, the point is detected after all the counts are shared. Therefore, the previous state of name/ID for which it is
with the new
or
period. The blockchain is updated for the above and hence for further sharing of EHRs. The case of the first two conditions is different, where
follows
and
as in Equations (3) and (2), respectively. The different case of condition 1 is to be differentiated from the other conditions as a trial to the user is given if the current trust is less than the previous sequence of trust. This impacts either
or
and hence Equation (1) is modified as
If both the
and
factors are not constant, then the sharing process is halted. Based on the different instances for
(or)
, the decision is made such that the sharing is not halted, whereas it is paused until the next update if
is observed. In this pausing instance, the sharing session of the end-user application is expired. Therefore, the user has to login again to re-initiate the EHR sharing session. The time of validity based on different instances of
is determined using Equations (5) and (6), respectively.
For the above Equation of computing
for fluctuating
, tn
Figure 3a,b, respectively.
The process of trust-based update in the blockchain is performed using
using
and
factors independently. The process is consecutive if
and
is updated based on
and concurrent if the update is based on
. The process of differentiation relies on the
that is identified for both the conditions where
. Finally, the user with
or
is identified in all the instances for providing better authentication. The linear representation in Equation (2) is either fluctuate between
based on
and
independently. The fluctuation is based on the varying
and
instances as differentiated by
. This trust-based decision-making helps to improve the ratio of successful sharing under controlled response time. In
Table 3, the observed records that are classified under different conditions of
Table 1 is presented for the different sharing times.
There is only one ending transmission in the sharing time of 70, where condition 4 is satisfied by sharing count of . The records classified under conditions 3/5 are not sent to the end user, and hence their sessions are logged out.
4. Classification-Based Concentric Authentication
In the classification-based concentric authentication, EHR is shared. In a concentric authentication, the common classification on point
serves as the decision-making for generating authentic records. The classification-based learning allocates two types of non-sequential session keys for authenticating the sharing session. This classification is based on the fluctuating
as in Equation (4). The impact of either of the fluctuation varies the administration of session keys to prevent the data tampering attacks. Initially, the session is set up between the medical server, and the end-user application follows a linear mapping map:
. Here,
is the group of response until a count
, and
is the random function of the end-user
. The group consists of a random generator
along with a differential prime number
. For the different
, the variable
relies on computing hashes
and
for the medical server and end-user, respectively. The general format of an initial authentication is denoted as
. The shared record count is obtained from the blockchain, where the trust of user access coupled with the records is stored. The distributed access to blockchain stored information is assessed in both end-user and medical server levels. For this authentication process, the classification occurrences of
and
in
is performed. As stated previously, the sequential and concurrent update of the medical server blockchain process requires different session keys and authentication procedures. Therefore, the occurrence of
for condition 1 from
Table 2 is the determining factor. Let
and
represent the fluctuating and sequential probabilities in a given time
; then,
, the above classification of probability,
over
is computed for all
instead of
to linearize the solutions as in Equation (1). Based on the relationship between
and
, the classification of
is performed as
where
For condition 1, the classification rule is framed as in Equation (9) for identifying
over
as in Equation (8)
where
. Here in Equation (9), the probability of
is computed based on the likelihood of
instances and its normalization as
The above likelihood normalization of helps to classify condition or condition. This helps to decide between sequential and concurrent authentication procedure through the same concentric point from the fluctuating sequence of . The normalization identifies precise in the series of such that follows sequential authentication, whereas the previous occurrence relies on random concurrent security measures. Here, the priority of authentication is initiated from the first occurrence of of as determined by . For all the first occurrences of and , the sequence follows or and (as in Equation (6)). Using this sequence and concurrency, the authentication is presented as follows. In two cases, the occurrence of the sequence and concurrency observed is discussed below.
Case 1: The sequence initiates with
Analysis 1: The hash sequence for both
and
is formulated as
This hash is composed of
and
and is subject to verification using the user ID and session key as follows,
where
and
are the secret and verification keys generated for the hashes, and therefore in the sharing process,
is contributed to the end-user. At the receiver end, the
is used for verification. If the process of sharing the records is sequential, then
is sequential until
or the likelihood
occurs. This is followed for all
until the
is reached, and then the coherency of
until
is observed. The verification of the process is also sequential by mapping
where
is observed from the range of hashes from
to
. The first sharing verification is performed as
where,
denotes the blockchain record for the grouped storage of
after the hashing process. In the verification at the user end, the relevance is first validated, followed by the verification process as in Equations (14) and (15) respectively.
In the above, the range of is valid until , i.e., the is the halting factor for sequential authentication. In the verification process, sequence as mapped in is the balancing factors where the sending and receiving sequence until is obtained. In this case, the converging interval of the proposed method is extended until the , i.e., the restricted time from 1 to is extended from to in a concentric manner. The next sequence for to authentication is discussed in Case 2.
Case 2: The sharing sequence experiences .
Analysis 2: This case is unique as both sequential and concurrent authentication is performed with interfering with other processes. It is to be noted that the convergence time from the sequential process is experienced to
from the
. This helps to identify more
, and thus the concentricity of the authentication process is expanded, reducing the chances of convergence. In this authentication process, both
and
are used for performing secure sharing between the medical server and the end user. The blockchain is updated with
and
along with the previous sequence for the appropriate user ID. Therefore, the session is initiated by verifying the following
There are two verification steps followed for authenticating the sharing due to the fluctuating instances in
. The first authentication follows Equation (14), whereas the range from
to
follows
The above process of authentication in sharing and receiving
is performed in both the medical server and the end user. Finally, the received
is verified using
to
sequence as in Equation (15), whereas the
to
received
is verified as follows.
This verification is processed for all the fluctuating shared
through the classification process. This prevents unnecessary convergence and overload complexity in handling medical records at different time instances. In
Table 4, the
and
for the varying
in different sharing time along with the complexity is tabulated.
In
Table 4, the complexity is computed as the number of additional hashes generated due to
to the actual existing hashes. The complexity is measured in terms of count of additional steps required for verification and authentication as observed in the keying process. If the impact of attacks is high, then the
factor increases to prevent unnecessary data tampering or modification. Hence, in this case, the number of
fluctuates as the classification is grouped under both the sharing instances.