IEEE JOURNAL OF BIOMEDICAL AND HEALTH INFORMATICS, VOL. 26, NO.
5, MAY 2022 1937
CP-BDHCA: Blockchain-Based
Confidentiality-Privacy Preserving Big Data
Scheme for Healthcare Clouds and Applications
Hemant Ghayvat, Sharnil Pandya , Pronaya Bhattacharya, Mohd Zuhair , Mamoon Rashid
Saqib Hakak , and Kapal Dev , Member, IEEE
Abstract—Healthcare big data (HBD) allows medical
stakeholders to analyze, access, retrieve personal and elec-
tronic health records (EHR) of patients. Mostly, the records
are stored on healthcare cloud and application (HCA)
servers, and thus, are subjected to end-user latency, exten-
sive computations, single-point failures, and security and
privacy risks. A joint solution is required to address the is-
sues of responsive analytics, coupled with high data inges-
tion in HBD and secure EHR access. Motivated from the re-
search gaps, the paper proposes a scheme, that integrates
blockchain (BC)-based confidentiality-privacy (CP) preserv-
ing scheme, CP-BDHCA, that operates in two phases. In
the first phase, elliptic curve cryptographic (ECC)-based
digital signature framework, HCA-ECC is proposed to es-
tablish a session key for secure communication among
different healthcare entities. Then, in the second phase,
a two-step authentication framework is proposed that
integrates Rivest-Shamir-Adleman (RSA) and advanced en-
cryption standard (AES), named as HCA-RSAE that safe-
guards the ecosystem against possible attack vectors. CP-
BDAHCA is compared against existing HCA cloud applica-
tions in terms of parameters like response time, average
delay, transaction and signing costs, signing and verifying
of mined blocks, and resistance to DoS and DDoS attacks.
Manuscript received February 24, 2021; revised May 4, 2021 and
June 10, 2021; accepted July 10, 2021. Date of publication July 14,
2021; date of current version May 5, 2022. (Corresponding author:
Mamoon Rashid.)
Hemant Ghayvat is with the Department of Computer Science and
Media Technology, 35234, Sweden, with the eHealth Institute, Lin-
naeus University, Vaxjo, Sweden Innovation Division, Denmark Fac-
ulty of Technology, Technical University of Denmark, 101A, 2800 Kon-
gens Lyngby, Denmark and also with the Building Realization, and
Robotics, Technical University of Munich, 80333 Munich, Germany (e-
mail: hemant.ghayvat@lnu.se).
Sharnil Pandya is with the Symbiosis Institute of Technology, Sym-
biosis International (Deemed) University, Pune 412115, India (e-mail:
sharnil.pandya84@gmail.com).
Pronaya Bhattacharya and Mohd Zuhair are with the De-
partment of Computer Science and Engineering, Institute of
Technology, Nirma University, Ahmedabad 382481, India (e-mail:
pronoya.Bhattacharya@nirmauni.ac.in; mohd.zuhair@nirmauni.ac.in).
Mamoon Rashid is with the Department of Computer Engineer-
ing, Faculty of Science and Technology, Vishwakarma University, Pune
411048, India (e-mail: mamoon873@gmail.com).
Saqib Hakak is with the Canadian Institute for Cybersecurity,
University of New Brunswick, Fredericton 4400, Canada (e-mail:
saqib.hakak@unb.ca).
Kapal Dev is with the University of Johannesburg, Johannesburg
524, South Africa (e-mail: kapal.dev@ieee.org).
Digital Object Identifier 10.1109/JBHI.2021.3097237
2168-2194 © 2021 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See https://www.ieee.org/publications/rights/index.html for more information.
Authorized licensed use limited to: ANNA UNIVERSITY. Downloaded on January 10,2023 at 09:18:00 UTC from IEEE Xplore. Restrictions apply.
,
We consider 10 BC nodes and create a real-world cus-
tomized dataset to be used with SEER dataset. The dataset
has 30,000 patient profiles, with 1000 clinical accounts.
Based on the combined dataset the proposed scheme out-
performs traditional schemes like AI4SAFE, TEE, Secret,
and IIoTEED, with a lower response time. For example, the
scheme has a very less response time of 300 ms in DDoS.
The average signing cost of mined BC transactions is 3,34
seconds, and for 205 transactions, has a signing delay of
1405 ms, with improved accuracy of ≈12% than conven-
tional state-of-the-art approaches.
Index Terms—Blockchain, secure session key
management, ECC signatures, pairing-based cryptography,
DoS and DDoS attacks, Healthcare Cloud and Applications,
Big Data.
I. INTRODUCTION
N SMART healthcare ecosystems, embedded internet-of-
I things (IoT) based body wearables generate enormous
healthcare big-data (HBD). The generated data is heterogeneous,
fragmented, and diverse, and is stored at multiple locations [1],
[2]. The HBD data is used for effective decision management
systems in the healthcare ecosystem. Moreover, it is essen-
tial for telehealthcare, as we witness rapid growth in remote
telemedicine post-COVID-19 era.
The personalized health records (PHR) and electronic health
records (EHR) are communicated are stored in healthcare clouds
and are accessed through wireless open channels that are sub-
jected to limitations of centralized access, high end-user latency,
and security and privacy attacks from malicious entities [3], [4].
Owing to the aforementioned limitations of responsive health-
care services, and the security and privacy of HBD, researchers
globally have proposed smart fog and edge-based solutions
for HBD. However, the trust among the distributed fog and
edge nodes is a prime concern among multiple heterogeneous
healthcare stakeholders.
In fog-based healthcare, patient EHR data is seamlessly
migrated over multiple applications. Moreover, the interplay
among the edge and fog nodes improves the end-user latency
and orchestrates smart business logistics. However, the level of
access to patient EHR depends on the underlying transparency
of applications [5], [6]. Thus, to address the limitations of trust
and transparency of EHR and PHR access, BC is found a suitable
1938
choice [7]. Through BC, a distributed, chronological, auditable,
and timestamped ledger is created among all stakeholders. Fake
or incorrect transactional updates can be held accountable and
can be traced back to the owner node that induces the change [8].
Thus, BC addresses the HCA limitations about agreements,
accountability, rights management, and data integrity in HBD.
Fog nodes can address the issues of high latency and network
congestion, and provide a middleware interface layer to HCA
and IoT collection layers. Fog nodes extend the computational
capabilities of HCA at the edge and serve the purpose of resource
satisfaction to users. With BC, the fog nodes are interfaced as
gateway units, where the collected sensor data at HCA is sent
to the fog layer, where they are analyzed through distributed
analytics and results are stored as transactional entities in BC,
which can be accessed by HCA stakeholders. However, BC
suffers from inherent limitations of scalability of mined nodes,
computational access, and effective key sharing ecosystems in
resource-constrained IoT-based HBD ecosystems. The inherent
limitation of BC scalability is addressed through the storage of
data in interplanetary file systems (IPFS), which is off-chain
storage. The EHR information is stored in IPFS and is hashed to
generate an external inference key. The EHR records are stored
as index-key pair structures, where any authorized stakeholder
can reference the IPFS ledger through private key [9]. The hash
information is externally linked to the on-chain main structure
as transaction information. As the meta-information is of small
size, with a fixed hash value, more transactions can be added per
block, which is useful for high ingested data in HBD ecosystems.
Moreover, storage of data as IPFS ledgers maintains the scalabil-
ity and transactional throughput of BC-ecosystems in HBD [10].
However, in an EHR, if the issues of secure key establishment
and signature mechanisms are not properly addressed, then the
confidence in collected EHR records, data fulfillment, and denial
of clarity is reduced [11].
In BC leveraged HBD, the malicious attackers mainly target
node alterations in the chain structure, and security flaws in
wallet addresses. This leads to alterations in data input, instruc-
tion set, mined knowledge, mutual agreements, and physical
storage elements of node structure [12]. Thus, to augment the
confidentiality-privacy (CP) of EHR, secure session keys, and
combined cryptographic primitives are required in shared EHR
records [13].
Motivated from the aforementioned discussions, the paper
presents a scheme, CP-BDHCA, that proposes a BC-based
secure key management and encryption scheme to handle
the CP and authentication of healthcare stakeholder identities.
The scheme proposed two novel frameworks as two phases. In
the first phase, a framework HCA-ECC is formulated that shares
the secured management of session keys through elliptic curve
cryptography (ECC). Through ECC, signature generation and
verification are processed for accessing and retrieving EHR.
EHR updates are recorded and stored as transactional entries
in BC. Then, based on ledger updates in BC, an extra layer of
security is induced through the proposed HCA-RSAE framework
that combines rivest-Shamir-Adleman (RSA) and advanced en-
cryption standard (AES) to protect the identity authentication
and prevent the HCA servers against DDoS attacks. The reason
Authorized licensed use limited to: ANNA UNIVERSITY. Downloaded on January 10,2023 at 09:18:00 UTC from IEEE Xplore. Restrictions apply.
IEEE JOURNAL OF BIOMEDICAL AND HEALTH INFORMATICS, VOL. 26, NO. 5, MAY 2022
behind using symmetric encryption to create ciphertext of large
data files is performance. The size of keys used to encrypt in
asymmetric cryptography (prime numbers in RSA) is much
larger than symmetric key cryptography. Symmetric keys are
proven to be much less a burden on computational resources
as compared to asymmetric cryptography. We have followed a
well-established OpenPGP approach by encrypting secret keys
used by symmetric cryptography with the receiver’s public key.
Thus, the proposed scheme CP-BDHCA combines the dual
benefits of security mechanisms and trust of BC to ensure safe
healthcare ecosystems. The proposed system CP-BDHCA is
for the healthcare data where the system users would-be doc-
tors, patients, pharmacists, laboratory technicians, caregivers,
insurance companies, nurses, and other relevant healthcare ser-
vice providers. So each stakeholder in the system has unique
characteristics to contribute as well as access the healthcare
system’s data. Based on their role in the system the authorization
level or priority has been set. Such as Doctor has the highest
level of authorization after the patient, whereas the laboratory
technician just needs to access to check the doctor’s prescription
of the respective patient online and upload the final report
there.
A. Novelty
The novelty of the work against existing schemes are as
follows-
1) A patient profile is secured via BC framework to leverage
security and trust to the HCA servers.
2) Along with the benchmark SEER dataset, we have cre-
ated a customized dataset of more than 30000 patient
profiles, and 1000 clinician accounts for the conduction
of the experiments. For the same, we have considered
130 attributes such as patient ID, credentials, and contact
information. We have installed BC adapters with required
touchpoints at various healthcare facility locations to form
patient profiling records.
3) A concept of patient personalized segmentation is applied
that provides only the required information for the patient
to the authorized stakeholders.
4) Large-scale simulations are presented for the proposed
scheme that evaluates the feasibility, stability, and robust-
ness of the presented scheme against existing state-of-the-
art approaches.
B. Contributions
The following are the research contributions of the paper
r A secure key exchange framework, HCA-ECC is proposed
that integrates ECC small key size, with secure session
management. In HCA-ECC, data collected through IoT
sensors are disseminated to web gateways, and fog-based
light-weight signatures are designed for bulk transactions.
r Based on secure session keys, wallet identifiers are gen-
erated, and stakeholders communicate through wallets. A
signed-key request is then generated for the user to access
EHR, based on RSA key generation.
GHAYVAT et al.: CP-BDHCA: BLOCKCHAIN-BASED CONFIDENTIALITY-PRIVACY PRESERVING BIG DATA SCHEME
Fig. 1. Benefits of BC in EHR management.
r Post the RSA key generation, a two-step authentication
process is designed as an additional layer of secured and
confidential access to records, through the AES scheme.
C. Article Structure
The structure of the article is as follows. Section II presents
the background and analysis of the previous schemes. Section III
presents the proposed scheme CP-BDHCA that operates in
two phases, namely, the ECC based digital signature phase,
and the proposed HCA-RSAE phase. Section IV presents the
performance evaluation of the proposed scheme. Section V
presents a discussion of open issues of possible integration of BC
in fog-assisted healthcare environments, and emerging future
directions from the research, and finally section VI concludes
the article.
II. BACKGROUND AND STATE-OF-THE-ART
The section outlines the existing background and the state-
of-the-art schemes related to cloud, fog, and BC-based solu-
tions in e-health applications about secure data collection and
management.
In HBD, sensor readings through body wearables are ag-
gregated through edge and fog gateway nodes through open
channels. Through fog nodes, responsive orchestration of critical
cases can be reported to the telemedicine servers, and doctors,
hospitals, and medics are called instantaneously [14]. For nodes,
responsive analytics are proposed to handle high-dimensional
data [15]. To reduce the possibility of privacy-based attacks,
mirrors and replicas of original EHR records are maintained at
heterogeneous locations [16]. This allows high data availability
and reduces the attack probability. However, mirror databases
have inherent limitations of data fragmentation, asynchronous
updates, and data consistency. BC can address these shortcom-
ings through distributed ledgers that are local copies of the
original chain structure. Through consensus, the nodes agree
on a global and consistent chain state, and thus effective data
management is possible [17]. Every node has a local ledger copy
of the global chain structure, and thus forged blocks cannot be
added. Thus, BC can leverage effective and transparent sharing
of EHR records, improve drug traceability, ensure clinical trials,
and can execute smart contracts based on specified logistics
among healthcare stakeholders [18], [19]. Fig. 1 presents the
benefits of incorporating BC in healthcare applications.
Authorized licensed use limited to: ANNA UNIVERSITY. Downloaded on January 10,2023 at 09:18:00 UTC from IEEE Xplore. Restrictions apply.
1939
A. Analysis of Existing Schemes
The section presents the analysis of existing healthcare man-
agement schemes related to cloud, edge and fog, and BC in
HBD ecosystems. Recently, researchers globally have proposed
the integration of cloud management in healthcare applications.
Liu et al. [20] proposed a cloud-based framework based on
digital twin healthcare management, termed as CloudDTH. The
scheme is designed to facilitate interaction and convergence
of digital twin in healthcare, based on different application
scenarios. Fan et al. [21] proposed a light-weight cloud-based
radio frequency identification (RFID) authentication scheme.
The scheme is designed to operate at low computational power
and is suitable for IoT-based ecosystems. In practical use-cases,
Microsoft developed personal health management scheme called
HealthVault [22].
In fog-based e-health architectures, Patel et al. [23] proposed a
reliable and key-exchange protocol scheme using ECC for body
area networks. For formal security analysis, the authors used the
random oracle ROR model and Dolev-Yev for informal analysis.
Authors in [24] presented a healthcare IoT-driven body area
networks scheme based on a real-or-random (ROR) model, and
simulation analysis is carried out using the OPNET framework.
For BC-based healthcare applications. Authors in [25] proposed
a BC-based EHR management scheme, that combines attribute-
based signatures based on master and sub-keys. The scheme
illustrates the usage of KUNodes algorithm and proposes an
unforgeable signature for the master server, which is collusion-
resistant.
As discussed in the above sections, researchers across the
globe have proposed optimized solutions for healthcare data
through the emerging cloud and edge solutions, and a diverse
set of security solutions, and BC integration with sensor based
applications [26]. However, most of the proposed schemes have
not focused on secured and trusted data communication between
the cloud medical resource management layer, and the web-
based applications for massive big data. The proposed scheme
addresses the gaps in earlier research by addressing the inherent
challenges of secure HBD dissemination, and secure informa-
tion retrieval. In HBD, cloud-based platforms like google fire-
base provide rule-based access schemes and acts as an interface
for cloud and web/mobile applications. Cloud computing layer
(Cloud-based Medical Resource Management layer) and the
Web and Mobile-based e-Health applications (Smart Medical
Services layer). Through BC, role-based access, and context-
aware control is provided to healthcare users. Table I presents
the list of notations and their interpretations in the proposed
CP-BDHCA scheme. EHR data security risks Privacy - depends
on architecture as blockchain alone can not provide privacy. Ac-
cessibility and authorization - Smart contracts are used to check
if an individual has the right to access the data. This covers the
confidentiality portion a bit as the only intended user can access
the data. Auditability - one of the major threats to such sensitive
data is non-repudiation. An individual can deny action and refuse
responsibility. By introducing blockchain, we are auditing every
transaction along with action performed on data. Authentication-
1940
TABLE I
NOTATIONS AND THEIR INTERPRETATION IN THE PROPOSED
CP-BDHCA SCHEME
Most of the blockchain platforms use public key infrastructure
(typically ECC) to authenticate users, which is well-established
and securer than traditional username-password approaches.
III. CP-BDHCA: THE PROPOSED SCHEME
The section discusses the system flow of the proposed scheme,
CP-BDHCA, which consists of two important phases. In the
first phase, the session key establishment is done through the
proposed HCA-ECC scheme, and once keys are established,
the asymmetric key pairs are generated through HCA-RSAE
scheme to secure EHR access. We present the system flow of
Authorized licensed use limited to: ANNA UNIVERSITY. Downloaded on January 10,2023 at 09:18:00 UTC from IEEE Xplore. Restrictions apply.
IEEE JOURNAL OF BIOMEDICAL AND HEALTH INFORMATICS, VOL. 26, NO. 5, MAY 2022
Fig. 2. CP-BDHCA: The system model.
the proposed scheme, and then provide the discussion of the
two schemes, namely, the HCA-ECC scheme, and HCA-RSAE
scheme respectively. The details are now presented as follows.
A. CP-BDHCA: The System Model
The section presents the system flow of the BC-envisioned
CP scheme for HBD environments. Fig. 2 presents the flow
of the entire scheme. In the proposed scheme, we consider
there are q IoT sensors mounted on the patient body, denotes
as {S1 , S2 , . . . , Sq }. The server generates real-time health data
DSq , and sends them to a healthcare cloud server HCS, over
the public network. HCS digitally timestamps the received data,
through its ID, and creates a signature for the data as HCSsig .
Now, DSq is transmitted to k fog sensor nodes {F1 , F2 , . . . , Fk },
through the connected mobile and web gateways, denoted as Gm
and Gw respectively. Through {Gm , Gw }, DSq is encrypted
through the symmetric key Ks . Based on the authorized node
with Ks , the receiving gateway node decrypts the data through
Ks , and obtains DSq . The forwarding fog node Fk , and the gate-
way Gm identity is verified during decryption phase through sig-
nature verification. At HCS, the verification of identity of Gm ,
and Gw is done, and the received and forwarded timestamp Trec ,
and Tf or are recorded. The time difference, δ(T ) = Trec − Tf or
is stored at HCS. The stored δ(T ) helps in prevention of replay
attacks by malicious attackers.
Once the data is forwarded at HCS, the key establishment
phase HCA-ECC is initiated with the setup of master parameters.
For the key establishment, a unique session key Ks is generated
to leverage efficient healthcare data exchange among HCS and
GHAYVAT et al.: CP-BDHCA: BLOCKCHAIN-BASED CONFIDENTIALITY-PRIVACY PRESERVING BIG DATA SCHEME 1941

Gm , and Gw respectively. Through Ks , like key capture, and

Algorithm 1 The proposed HCA-ECC framework
DDoS attacks are mitigated at networking interfaces. Then, for
access control, the HCA-RSAE scheme is instantiated that calls Input: DSq , ID(HLS), symmetric key Ks , ∂, x, Gm , Gw .
the public wallet blockchain Ws of users, and secret biometric Output: Generation of (HCSpri , HCSpub ) pairs.
value Bios is fed to the AES generator in CBC mode. The AES- 1: Fk ← Connect (Gm , Gw )
CBC output is collected and added to transactions Tx , which 2: Enc(DSq ) ← Ks (Gm , Gw)
are mined by miners and added to the blockchain, through an 3: Tf or ← Timestamp.append (Enc(DSq )
energy-efficient consensus scheme. 4: Dec(DSq ) ← Ks (Fk , Gm )
Once data DSq is timestamped, and forwarded through k fog 5: Trec ← Timestamp.append Dec(DSq )
nodes, the basic encryption part of DSq is performed at Gm and 6: Δ(T ) ← Trec − Tf or
Gw respectively, thereby alleviating the burden on fog nodes for 7: HCS ← Timestamp.append(Δ(T ))
encryption overheads. The fog nodes are placed strategically to 8: Select E(Fx ) under GF(x)
address resource and compute requirements to miner entities. 9: K ← randrange (1, (x − 1))
In case resources are not available at fog nodes, then only the 10: Store K in CA
request is forwarded to cloud servers. Thus, the scheme assures 11: ACB = nCA mod(x)
fog-as-a-service paradigm to support the high-end computa- 12: HCApub ← {x, n, ACB}
tional requirements of BC. 13: ω ← SHA-256 (DSq )
The proposed scheme presents two frameworks. In the first 14: Send ω to {F1 , F2 , . . . , Fk }
framework, named as HCA-ECC, the HCA authentication and 15: Fk ← randrange(1, (ρ − 1)), store in z
authorization is handled via a secure session establishment 16: if (gcd(z, (x − 1)) == 1) then
through ECC between the cloud and the application layer. Once 17: HCSpri ← nz modx
keys are established, secure EHR access and sharing are handled 18: HCSpub ← nz (D) − CA(HCApri mod(x − 1))
through BC. Then, in the second framework, named as HCA- 19: Send HCSpub as digital signature to {Gm , Gw }
RSAE, we use RSA and ECC to generate secure key pairs for 20: end if
communication among authorized entities that allow a two-step 21: Gm ← nz modx
authentication. The details of the frameworks are presented as 22: HCApub ← ACB(HCApri )mod(x)
follows. 23: if (HCApri == HCApub ) then
24: F ← 1,
25: output Valid Signature
B. HCA-ECC: the Session Establishment
26: else
The section presents the schematics of the session key es- 27: F ←0
tablishment through the proposed HCA-ECC scheme. Table I 28: output Invalid Signature
presents the key terminologies used in the proposed HCA-ECC 29: end if
framework. To propose the generation of a session key, we
present the ECC digital signature framework. The reason for
adopting ECC digital signature scheme over Diffie-hellman HCA-ECC digital signature framework consists of three phases:
(DH) and RSA key exchange is due to its lightweight and (i) private and public key generation for HCS (ii) HCS digital
smaller key size, with similar security as DH and RSA schemes. signature generation (iii) HCS digital signature verification.
Moreover, DH and RSA are found vulnerable against security The details are now presented as follows.
attacks like node capture attacks, man-in-the-middle attacks, 1) Private and Public Key Generation: Let ω be a hash func-
eavesdropping, DoS, and DDoS. In ECC based digital signature, tion, x is a prime number, ∂ is the multiplicative group of modulo
we consider HCSpri for encryption, and HCSpub for decryp- prime number x. During the process of key generation, HCS
tion. The schematics are as follows. user U selects a private-public key pair as follows.
In ECC, we consider a prime x, under the Galois-prime field i Generate a random integer CA, and a private key k is se-
GF (x), then the ECC curve equation can be depicted as follows. lected such that 1  CA  x − 1, where CA represents
the cloud server node.
q 2 (mod x) = p3 + zp + c, (mod x), where
ii Compute ACB = nCA modx
4p3 + 27q 2 (mod x) = 0 and , p, q, x, z ∈ [0, x − 1]. (1) iii The cloud user’s private key can be represented by
CA, and the public key can be represented by a pair
The ECC curve coordinates can be denoted by 2, {x, n, ACB}.
E(Fx ) = (p, q), p, q ∈ Fx to satisf y the condition iv To sign the sending data (S) by HCS node, a hash
function (ω) is computed which is given as follows.
q 2 = p3 + zp + c (constant) ∪ 0 (2)
ω = ω(D), where 0  D  x − 1. (3)
The primary benefit of using the ECC digital signature scheme
is it can compute prime numbers in exponential times. Whereas where D represents the data.
factoring and discrete logarithmic methodologies do not possess 2) HCA Digital Signature Generation: The fog nodes
the capability to do such computations [1], [27]. The proposed {F1 , F2 , . . . , Fk } generates the digital signature as follows.

Authorized licensed use limited to: ANNA UNIVERSITY. Downloaded on January 10,2023 at 09:18:00 UTC from IEEE Xplore. Restrictions apply.
1942
i Select a random integer z such that 1  z  p − 1, and
gcd(z, x − 1) = 1, where z is a relative prime value to
x − 1.
ii Compute HCS signature based on ECC signature
scheme as follows.
HCApri = nz modx
This denotes the ECC-encryption process.
iii Next, we compute the inverse z (−1) (modx), that is
interpreted as z modulo x − 1. The HCS cloud signature
HCApub is denoted as follows.
HCSpub = nz (D) − CA HCApri mod(x − 1). (5)
3) HCA Digital Signature Verification: The cloud and
application signature (HCS) consists of a key pair
(HCApri , HCApub ). The receiving application node Gm
and Gw verify the signature as follows:
i Compute HCVpri = nz modx and HCVpub =
ACB 1(HCApri )modx.
ii If HCApri matches with HCApub , HCSsig is valid, and
output is TRUE, else HCSsig is invalid and the output is
FALSE.
Table I represents a list of used terminologies in the proposed
HCA-ECC authorization and authentication process. The details
of the proposed HCA-ECC is presented in Algorithm 1. Lines
1-9 depicts the encryption of shared session data DSq , collected
through gateway nodes Gm , and Gw , and timestamps are ap-
pended. Lines 11-20 denotes the signature generation through
ECC, and lines 22-28 depicts the verification of the signature at
HCA servers.
C. HCA-RSAE: Generation of Key-Pairs
The section proposes the generation of key-pairs through a
proposed framework, named as HCA-RSAE, that secures EHR
access, and the sharing of EHR among authorized stakeholders
through BC. In the HCA-RSAE framework, we propose an
integration of the AES symmetric scheme with the RSA public
encryption standard. The details of the proposed framework are
presented as follows.
1) Generation of Wallet Addresses in BC for HCA-RSA Key-
Pairs: In the proposed BC network, we consider an entity set
E = {EU , EM n , EHCS }. We consider that there are n user
nodes in EU , denoted as {U1 , U2 , . . . , Un }. Every user Un in
the BC network has a wallet Wn represented through a mapping
M1 : Un → Wn . The wallet is used to access the EHR records
and consists of the following attributes.
Wn = {ID(Un ), P ub(Un ), P ri(Un ), C(Un ), T, merkle_root}
(6)
where ID(Un ) denotes the user identity, P ub(Un ), and
P ri(Un ) denotes respectively the public and private key pairs,
C(Un ) denotes the available cryptocurrency for transactions, of the proposed HCA-RSAE key-pair generation utilized in the
T is the current wallet timestamp, and merkle_root represents BC network. Each Un , or a group of BC nodes, creates two
the merkle root information. Fig. 3 presents the wallet design keys as public and private pairs. We consider a sender node
Wn for storage of EHR records [28]. Now, based on Wn . encrypts message D through an open public key, denoted as
each user Un stores data captured through k fog sensor nodes HCRSAEpub of the recipient node. Once the recipient node
Authorized licensed use limited to: ANNA UNIVERSITY. Downloaded on January 10,2023 at 09:18:00 UTC from IEEE Xplore. Restrictions apply.
IEEE JOURNAL OF BIOMEDICAL AND HEALTH INFORMATICS, VOL. 26, NO. 5, MAY 2022
(4)
Fig. 3. The EHR wallet design [28].
{F1 , F2 , . . . , Fk }. The collected data is mapped to HCS, and is
timestamped through {Gm , Gw }. The gateway nodes act as ag-
gregators and store HCA-ECC signatures as key-value mapping
pairs. Through the mapping, any nth user in the BC-based HCS
framework can access patient records based on the obtained
wallet address Wn . The EHR record structure can be identified
through the patient public information P ub(P ), and the private
credentials P r(P ). Any nth user can access the patient EHR
through a signed key SK request, which can be depicted as
follows.
SK = PEHR (P ub(P ), P r(Un ), (7)
The authentication request now consists of the following steps.
1) At the HCS server node, the authentication parameters
AH are invoked as follows.
AH {H256 (EHRP , δ, ξ} (8)
where H256 represents the hash of the EHR data of patient,
δ is a random seed generated through any random number
algorithm, and ξ represents the initial parameter for the
ECC curve under GF (x).
2) Based on AH , master keys M K1 , and M K2 are gener-
ated that obtains HCA-ECC signature for Gm and Gw
respectively. A secret biometric value BK(U ) is added
for the transaction request in BC.
3) A notary N ot(AH ) is generated that servers as presenting
certificate for Un to access EHR records. If at the receiver
side, the notary sign Sig(N ot) matches, the EHR data is
considered to be valid, otherwise it is invalid.
4) In case Sig(N ot) is valid, any user Un access the valid
EHR and digitally timestamps it through the proposed
signature scheme. The steps are iterated for every EHR in
the BC network. Once the signature is added, a transaction
T (n) at timestamp T is created in BC. The miner entities
EM n validates the sign through a consensus protocol CP
in BC and adds a new block Bnew to the existing chain
structure BChain . At any time instant, the longest valid
chain is considered for the addition of Bnew .
Based on mined block Bnew , we now consider the schematic
GHAYVAT et al.: CP-BDHCA: BLOCKCHAIN-BASED CONFIDENTIALITY-PRIVACY PRESERVING BIG DATA SCHEME 1943

receives D completely, it decrypts D using a recipient’s private

Algorithm 2 The proposed HCA-RSAE framework
key HCRSAEpri . The details of key-pair generation are now
presented as follows. Table I represents a list of used terminolo- Input: Entities EU , EMn , EHCS , k fog sensor nodes,
gies in the proposed HCA-RSAE methodology. {F1 , F2 , . . . , Fk }
2) Generation of HCA-RSA Modulus n: To generate a HCA-
Output: Generation of key-pairs.
RSA modulus, two huge random prime numbers are selected 1: for i ← 1 to n do
to calculate n in such a way that n = x × y, n is a very large 2: Wi ←
number of the minimum size 512 bits. The details of the com- {ID(Ui , P ub(Ui ), P ri(Ui ), C(Ui ), T, merkle_root}
putational steps are as follows. 3: Ui ← Capture(Di , Fk )
1) Computation of the derived number ρ: A derived number 4: M ← Map(Ui , HCS)
ρ is computed, with constraint ρ > 1, and is equivalent 5: Gm ← Timestamp.append (M, T1 )
to (x − 1)(y − 1). The generated derived number ρ and 6: Gw ← Timestamp.append (M, T2 )
factors (x − 1)(y − 1) are co-prime in nature. 7: SK ← PEHR (P ub(P ), P r(Ui ))
2) Formulation of a public key HCRSAEpub : Consider 8: Send SK at HCS
two large prime numbers (x, y), n, and a public key 9: end for
HCRSAEpub . Here, n is considered as a part of the a 10: AH ← SHA-256(EHRP , δ, ξ)
public key HCRSAEpub . 11: M K1 ← P ub( AH )(BK(U ), Gm , ξ)
3) Formulation of a private key HCRSAEpri : The for- 12: M K1 ← P ub( AH )(BK(U ), Gw , ξ)
mulation of a private-key is done using a pair of large 13: Add M K1 and M K2 to BC
prime numbers (x, y), n, and a public key HCRSAEpub , 14: Sig(N ot) ← Verify_Sign(Cert(Un , E(AH ), M K1 , T )
and a special number z, such that z = (x − 1)(y − 15: if Sig(N ot) == N ot(AH ) then
1)reverse(modρ). The public key is computed with 16: Set STATE of EHR as VALID
prime numbers (x, y), n, and a public key HCRSAEpub . 17: Bnew ← EMn (EHR, BC)
Note, that here n is a part of the a public key 18: Chain.length ← Chain,length+1
HCRSAEpub . The relationship between a special num- 19: BChain ← Chain.Length.
ber z and a derived number ρ can be computed as zρ, 20: for i ← 1 to N do
zρ = 1 mod(x − 1)(y − 1). 21: BROADCAST BChain to all N odes(i) in BC
3) HCA-RSAE Through AES-Based Encryption for Two-Step
22: end for
Authentication: To provide additional security to HCS, we have
23: else
designed a two-step authentication process. After the completion 24: Set STATE of EHR as INVALID
of HCA-RS based encryption, the decoded D is again encrypted 25: end if
through an AES based encryption stage. Collectively, the two- 26: for i ← 1 to n do
step authentication scheme is denoted as HCA-RSAE. After the 27: Ui ← Dec(HCRSAEpri )
completion of two-step authentication process, the cloud health 28: Select x and y as inputs to RSA
node HCS sends health data to the application node via a secure 29: n ← PROD(x, y)
session establishment process, as earlier depicted in section 30: if gcd(ρ, {(x − 1)(y − 1)} == 1) then
III-B. Algorithm 2 presents the proposed HCA-RSAE scheme. 31: ρ ← (x − 1) × (y − 1)
Lines 1-7 depicts the n users that access the medical data through 32: HCRSAEpub ← (x − 1)(y − 1) reverse mod(ρ)
k fog nodes, and the data is collected and passed through Gm and 33: end if
Gw . The process generates secret-key SK. Lines 10-21 presents 34: Initialize parameters for AES scheme
the generation of master-key from secret-key and signature and 35: AES Session(KS ) (HCS, Ui )
certificate verification. Once the entities are verified, transac- 36: end for
tions are added in chain through EMn . Lines 26-32 presents
the generates of public identifier HCARSAEpub , and shared
session key pair Ks is generated through the AES rounds.
A. Experimental and Dataset Setup
IV. PERFORMANCE EVALUATION OF CP-BDHCA
A BC node is installed with Ubuntu LTS v20.04, and a Xampp
The section presents the performance evaluation of the pro- server. The proposed BC setup connects 10 to other BC nodes,
posed scheme CP-BDHCA against conventional approaches. and a customized dataset of 30000 patient profile and 1000
In experimentation, the simulations are carried out with the clinician accounts are set up. Furthermore, we have also used a
underlying assumptions- (i) At least one BC node is available benchmark SEER dataset for the conducted simulations, which
at every healthcare facility (ii) Patient is provided with a unique contains almost 100000 patient profiles with more than 130
patient profiling id to access the EHR, and (iii) An expert has attributes such as unique patient profile id, healthcare system
been placed at the healthcare facilities to control the operations credentials, DoB, contact details such as email address, phone
of the proposed scheme. no, etc.

Authorized licensed use limited to: ANNA UNIVERSITY. Downloaded on January 10,2023 at 09:18:00 UTC from IEEE Xplore. Restrictions apply.
1944 IEEE JOURNAL OF BIOMEDICAL AND HEALTH INFORMATICS, VOL. 26, NO. 5, MAY 2022

TABLE II
A PATIENT PROFILING RECORD FORMAT

Fig. 4. Comparison of the HCA-ECC scheme in DoS attack.

TABLE III
TRANSACTIONS OF BC-PROFILING FORMAT FOR CHOSEN
10 PATIENT PROFILES

Fig. 5. Comparison of the HCA-ECC scheme in DDoS attack.

TABLE IV
SIMULATION RESULTS FROM SEER AND PATIENT PROFILING DATASETS
B. Real-Time Data Generation: BC-Based
Patient Profiling
The attributes collected from the SEER dataset are stored in
the 10 BC nodes. Next, we present the patient-based person-
alized segmentation to present the contextual information. We
have also loaded the required touch-points with 10 blockchain
adapters as per the healthcare facility locations. We have selected
10 random patients, and provided them EHR access, along
with decryption keys. The touchpoints allow the selection of
healthcare records that are related to the patient visit without
an explicit linear search of the entire EHR. Based on the above
underlying assumptions, we present the patient profiling record
format in Table II. Based on the profiling information, the
patient information is stored in 10 BC nodes, with the details
of transaction history presented in Table III. attack a HCA-ECC based healthcare framework. Fig. 5 depicts
a comparison analysis of response time for DDoS scenarios.
C. A Comparison Analysis of HCA-ECC Security HCA-ECC algorithm outperforms all the existing methodologies
Framework Against DoS and DDoS Security Attacks and achieves very less response time around 300 milliseconds.
Thus, in DDoS scenarios, it is a complex task for attacker to gain
This section analyzes the comparative analysis of the
access. A comparative analysis of obtained results from SEER
proposed HCA-ECC security scheme with existing security
and profiling dataset is listed in Table IV.
methodologies concerning their response times in DoS and
DDoS attack scenarios [29]–[31].
As shown in Fig. 4, HCS-ECC security scheme outperforms D. A Comparison Analysis of HCA-RSAE
Security Framework
all the existing schemes such as AI4SAFE, TEE, Secret, and
IIoTEED in terms of response time in the case of DoS attack This section analyzes the comparative analysis of the pro-
scenarios. The response time achieved is around 310 millisec- posed HCA-RSAE security framework with existing security
onds as compared to all the existing methodologies. Due to less methodologies concerning their response times. Furthermore,
response time, it would be very challenging for an attacker to we have also demonstrated the simulation results of the signing

Authorized licensed use limited to: ANNA UNIVERSITY. Downloaded on January 10,2023 at 09:18:00 UTC from IEEE Xplore. Restrictions apply.
GHAYVAT et al.: CP-BDHCA: BLOCKCHAIN-BASED CONFIDENTIALITY-PRIVACY PRESERVING BIG DATA SCHEME
Fig. 6. Comparison of HCA-RSAE with average delay and response
time using RSA security algorithm (in ns).
Fig. 7. Comparison of HCA-RSAE with average delay and response
time using AES security algorithm (in ns).
and verifying costs in BC, and compared the schemes with
conventional approaches.
1) Security Evaluation: Fig. 6 and Fig. 7 represents a com-
parative analysis of the proposed HCA-RSAE security scheme
with average delay and response time using RSA and AES
security algorithm (in ns).
2) HCA-RSAE Analysis Against DoS and DDoS Attack Vec-
tors: We evaluate the performance comparison of HCA-RSAE
based on different parameters like the number of exchanged mes-
sages, time of evaluation of records, MQTT subscriber time, and
MQTT publisher time. In total, we consider 26 time-instances
for evaluation and plot the DoS attack densities on the above
parameters on the MQTT cloud broker. Similarly, the perfor-
mance comparison is replicated with the same set of parameters
in DDoS attacks. The proposed HCA-RSAE framework has high
resistance against both DoS and DDoS-based attacks, with low
success probability by the malicious intruder to gain access to
working keys in the healthcare ecosystem.
3) Evaluation of Signing Delay and Transaction Costs in BC:
We next present the computational analysis of the proposed
HCA-RSAE framework in terms signature generation and verifi-
cation costs. For this, we compute the delay analysis of mining
transactions through EMn in BC. Fig. 8(a) depicts the signing
and verifying costs of mined transactions in BC through HCS.
The average signing cost is 3343.24 ms, and the verifying cost
is 7023.15 ms. As the user wallets Wn are mapped to HCS,
Authorized licensed use limited to: ANNA UNIVERSITY. Downloaded on January 10,2023 at 09:18:00 UTC from IEEE Xplore. Restrictions apply.
1945
Fig. 8. Comparative analysis of mined transaction signing costs at
HCS, and overall signing delay costs against conventional schemes
(Dorri et al. [32], Zhang et al. [33]). (a) Transaction and Signing costs by
EM n at HCS (b) HCA − RSAE overall signing delay
Fig. 9. Average Delay and Response Time of RSA and AES.
the cost decreases and thus more users can access the patient
EHR through the signed SK key. Next, we present the efficacy
of the generated signature schemes. We have compared the
signing delay of HCA-RSAE against existing schemes by Dorri
et al. [32], and Zhang et al. [33]. The results are shown in
Fig. 8(b). At n = 205 transactions, the proposed framework has
a signing delay of 1405 ms, compared to 1489 ms in [33], and
1612 ms in [32]. As the signature operations are the proposed
scheme has a signing delay of 1397 ms, compared to proposed
schemes, Zhang et al. [33] with a signing delay of 1489 ms,
and Dorri et al. [32] with a delay of 1612 ms. As signature
operations are validated through sig(N ot), based on master key
M K, run-time hash computations are reduced, and thus signing
latency decreases.
4) Comparison of HCA-RSAE With Existing Schemes:
Fig. 9 represents a comparative analysis of the proposed HCA-
RSAE security scheme with average delay and response time
using both RSA and AES security algorithms (in ns). Fig. 10 de-
picts a comparison analysis of response time for DDoS scenarios
with an MQTT cloud broker architecture. HCA-RSAE algorithm
outperforms all the existing methodologies such as AI4SAFE,
TEE, Secret, and IIoTEED, and achieves a very less response
time of around 520 milliseconds. In DDoS scenarios, it would be
a complex task for any attackers to access an HCA-RSAE-based
healthcare ecosystems.
1946
Fig. 10. Response time of HCA-RSAE against DDoS attacks.
E. Theoretical Security Analysis
In this subsection, the security evaluation of the proposed
scheme is evaluated. For the same, we have considered the anal-
ysis of computation and communication costs for the different
security identifiers as presented in Srinivas et al. [34].
1) Computation Cost: To evaluate the computation cost,
we consider the presented algorithms, namely, the HCA-ECC
framework, and the BC-based HCA-RSAE framework. In the
HCA-ECC framework, or algorithm 1, we have Enc(DSq ) that
involves a symmetric encryption of cost 0.0056 seconds (s).
Then, there are 2 timestamp appends Trec and Tf or to prevent
the replay-attacks, which is cost 0.00032 s each. Next, HCS
is of 0.00032 s, and ACB involves modular exponentiation
operation, and thus cost is 0.0192 s. For computation of ω,
SHA-256 hash operation is applied, and is thus 0.00032 s. Next,
we compute HCSpri that involves a modular exponentiation
operation of 0.0192 s, and Gm involves a modular exponenti-
ation operation of 0.0192 s. Thus, the total cost of algorithm
1 is 0.0056 + 2 × 0.00032 + 0.00032 + 0.0192 + 0.00032 +
0.0192 + 0.0192, which is ≈0.06448 s.
Similarly, for HCA-RSAE framework, first step involves the
wallet wi generation, that involves a cost of 0.0171 s. Next,
we have 2 timestamps for gateways Gm , and Gw , with a total
cost of 0.00032 + 0.00032 = 0.00064 s. Next, AH involves a
SHA-256 hash output of cost 0.00032 s. For master keys M K1 ,
and M K2 , a symmetric encryption operation is required of cost
0.0056 for each key. For sign verification, the cost is 0.03892 s,
and Bnew appends the transaction hash, which is 0.00032 s.
A modular inverse operation is computed for HCARSAEpub
exponent of cost 0.00264 s, and session key Ks is of cost
0.0056 s. Thus, the total cost is 0.0171 + 0.00064 + 0.00032 +
2 × 0.0056 + 0.03892 + 0.00032 + 0.00264 + 0.0056, which
is ≈ 0.07674 s. Thus, the computation cost of CP-BDHCA
scheme is 0.06448 + 0.07674 s, or 0.14122 s, which is 141.22
milliseconds (ms).
2) Communication Cost: Next, similar to computation cost,
we evaluate the communication cost of the proposed frame-
works, HCA-ECC, and HCA-RSAE, respectively. For HCA-ECC
framework, we assume the session DSq meta-information is
shared which is 32 bits. A symmetric key Ks is computed of
cost 128 bits. Enc(DSq ) involves 192 bits, and two times-
tamps Trec , and Tf or , involves an exchange of 32 bits each.
Next, HCS timestamp, random number K in range 1, (x − 1)
Authorized licensed use limited to: ANNA UNIVERSITY. Downloaded on January 10,2023 at 09:18:00 UTC from IEEE Xplore. Restrictions apply.
IEEE JOURNAL OF BIOMEDICAL AND HEALTH INFORMATICS, VOL. 26, NO. 5, MAY 2022
involves 32 bits exchange each. K is then stored in CA. For
ω, hash exchange involves 256 bits, Fk random nonce is 32
bits, similar to K, and signature check involves a boolean
operation of 1 b exchange. Thus, the total cost for algorithm 1
is 32 + 128 + 192 + 2 × 32 + 2 × 32 + 256 + 32 + 1, which
is ≈609 bits.
Next, we evaluate the HCa-RSAE framework. For wallet Wi ,
identity information is 32 bits, public/private key pairs exchange
is 128 + 128 = 256 bits. Thus, for Wi , a total exchange is
288 bits. For Gm and Gw , timestamp involves 32 bits each.
Next, the Map exponent performs the mapping request with
exchange information of 1 b. To send SK, a public expo-
nent is sent, which is 192 bits at HCS. At HCS, operations
M K1 , and M k2 involves a symmetric key exchange of 128
bits each. Sig(N ot) computes the signature verification step
for 256 bits. Finally, to add the node to BC, we compute the
block timestamp, random nonce, difficulty hash fetch, previous
hash storage, and identity information of merkle_root. The total
exchange involved in these operations is computed as 32 +
32 + 32 + 256 + 32 = 384 bits. Thus, the total involved cost is
288 + 2 × 32 + 1 + 192 + 2 × 128 + 256 + 384, or 1441 bits.
Thus, the total communication cost of the CP-BDHCA scheme
is 609 + 1441 bits, or 2050 bits, which is ≈257 bytes.
3) Number of Message Exchanges: Next, we formulate the
number of message exchanges in the overall scheme. In HCA-
ECC framework, there are 3 message exchanges, namely, Store
K in CA, to send ω to k for sensor nodes {F1 , F2 , . . . , Fk , and
send HCSpub to gateways Gm and Gw .
For HCA-RSAE framework, there are 3 message exchanges.
First, we send SK to HCS server. Next, we BROADCAST
Bchain to all nodes in BC, and we initialize the parameters of
AES scheme to be sent to HCS. Thus, the overall message
exchanges in CP-BDHCA scheme is 3 + 3 = 6 messages.
4) Comparative Analysis With Existing Schemes: We now
formally present the comparative analysis in terms of compu-
tation and communication costs against existing state-of-the-art
schemes. For the same, we have compared our proposed scheme
CP-BDHCA against similar security schemes. As indicated, in
our scheme, we have a higher number of message exchange cost,
but computation and communication costs are lower. However,
our proposed scheme has higher communication cost than Odelu
et al. [35], and Kabra et al. [36], since there is a trade-off
among computation latency and bit exchanges. With lower com-
putation latency, the communication cost increases, at similar
security levels. Table V presents the comparative analysis that
indicates the viability of the scheme in the context of security
evaluations.
V. OPEN ISSUES AND EMERGING FUTURE ASPECTS
In this section, we present the open issues and challenges,
alongwith emerging future aspects of the proposed scheme
that integrates BC for trust in cloud and fog based healthcare
applications. The details are present as follows.
a) Heterogeneous data sources: The EHR data is highly
complex, owing to the 5Vs of big data ingestion to health-
care nodes [39]. Due to the high volume and variety in data
GHAYVAT et al.: CP-BDHCA: BLOCKCHAIN-BASED CONFIDENTIALITY-PRIVACY PRESERVING BIG DATA SCHEME
TABLE V
COMPARATIVE ANALYSIS OF SECURITY SCHEMES IN TERMS OF
COMPUTATION AND COMMUNICATION COSTS AGAINST SIMILAR
STATE-OF-THE-ART SCHEMES
Esym : Symmetric encryption cost; Tappend : Transaction append cost; Eexp : Modular
exponentiation cost; Easym : Asymmetric encryption cost; Hm : Hash output cost; Wsig :
Wallet signature cost; Sgen : Signature generation cost; Sver : Signature verification cost;
Einv : Modular inverse cost; Tpair : Bilinear pairing cost; Tecm : ECC multiplication cost;
Tf : Modular function cost; Teca : ECC addition cost;
sources, the cloud and fog nodes often face bottlenecks.
The aggregated data at fog and cloud gateways have to
deploy uniform standards and communication protocols
to address varied data storage formats. Moreover, the
gateways have to ensure that responsive and robust rout-
ing protocols are set up at aggregator nodes to meet the
application service latency.
b) Privilege-based attacks: The data exchanges are recorded
through BC in the proposed scheme, but an adversary
can form privilege escalation attacks prior to transaction
record in BC [40]. For this, the adversary would require
high computational resources, and once available, the
attack is highly possible. Hence, a proper user access
control matrix is required to be designed to ensure CP
of the stored data at remote servers.
c) Unified interfaces and programming platforms: As fog
nodes are near to client device, they deploy different inter-
face standards, and to program these interfaces, a unified
application framework is required. However, to date, for
fog computing, proprietary solutions are only available,
and the lack of common programming standards restricts
a common development framework. Fog nodes are fur-
ther challenged through dynamic links, where the nodes
are free to join and leave the network frequently, and
thus big-data streaming and data-processing engines are
challenged through operational flexibility and scalabil-
ity issues, mainly due to static orchestration of wireless
links. Thus, the design of standard and unified application
frameworks, with lightweight exchange formats is an
emerging scope.
d) Cloud-fog interplay: In healthcare applications, design
of proper data movement, and shift of resources be-
tween cloud-to-fog, and subsequently, from fog-to-cloud
raises network and compute orchestration challenges at
the networked nodes. This also requires multi-level data
Authorized licensed use limited to: ANNA UNIVERSITY. Downloaded on January 10,2023 at 09:18:00 UTC from IEEE Xplore. Restrictions apply.
1947
access management and proper authorization schemes.
Researchers have exploited techniques that handle or-
chestration at single levels, either at the network or
at resource nodes. However, a dynamic interplay and
scheduling mechanism are required, with multi-level user
access control locks to address the complex cloud-fog
interplay of data movement among nodes.
VI. CONCLUSION
In HBD applications, medical records are shared among dif-
ferent stakeholders through public open channels. Thus, privacy
and secure access to shared medical records are prime concerns.
The paper proposes a scheme, CP-BDHCA, that addresses the
security, and trust-based concerns of shared EHR and PHR
through the integration of BC at HCA nodes, that maintains
a trusted and chronological ledger among different stakehold-
ers. Through BC, a combined CP scheme is proposed, and
two frameworks are proposed as part of the overall scheme.
Firstly, HCA-ECC framework is proposed that forms a secured
ecosystem for key exchange among HCA servers, gateways,
and client nodes. Then, through the HCA-RSAE framework,
the dual benefits of RSA and AES are combined to ensure au-
thorization and identity management. The scheme is compared
against conventional schemes like AI4SAFE, TEE, IIoTEED,
and Secret, and the efficacy of the scheme is proposed for
diverse set of parameters. The proposed system has limitations in
healthcare information exchange, related to access management
and auditing of EHR files. In the future, the authors would
propose a generalized security algorithm that can be fine-tuned
to support access management, EHR audits, and also propose
secure physical channel access and inter-networking, secured
radio communication, and homogeneous fog-edge interplay in
resource-constrained ecosystems.
REFERENCES
[1] Y. L. Kanth, B. R. Singh, S. Sunanda, and M. Sangeetha, “A secure frame-
work for mollifying attacks in cloud,” Int. J. Comput. Trends Technol.,
vol. 16, no. 5, pp. 204–207, 2014.
[2] M. A. Jan et al., “A lightweight mutual authentication and privacy-
preservation scheme for intelligent wearable devices in industrial-CPS,”
IEEE Trans. Ind. Informat., vol. 17, no. 8, pp. 5829–5839, Aug. 2021.
[3] N. Sharma, I. Kaushik, V. K. Agarwal, B. Bhushan, and A. Khamparia,
Attacks and Security Measures in Wireless Sensor Network, Hoboken, NJ,
USA: Wiley, 2021, pp. 237–268.
[4] B. Bhushan and G. Sahoo, “Recent advances in attacks, technical chal-
lenges, vulnerabilities and their countermeasures in wireless sensor net-
works,” Wireless Pers. Commun., vol. 98, no. 2, pp. 2037–2077, 2018.
[5] D. Sangita, C. Ankita, and P. Reshamlal, “A review on issues and chal-
lenges of cloud computing,” Int. J. Innovations Advance. Comput. Sci.,
vol. 4, no. 1, pp. 81–88, 2015.
[6] X. Liu, P. Zhou, T. Qiu, and D. O. Wu, “Blockchain-enabled contextual
online learning under local differential privacy for coronary heart disease
diagnosis in mobile edge computing,” IEEE J. Biomed. Health Informat.,
vol. 24, no. 8, pp. 2177–2188, Aug. 2020.
[7] A. P. Singh et al., “A novel patient-centric architectural framework for
blockchain-enabled healthcare applications,” IEEE Trans. Ind. Informat.,
vol. 17, no. 8, pp. 5779–5789, Aug. 2021.
[8] B. Bhushan, C. Sahoo, P. Sinha, and A. Khamparia, “Unification of
blockchain and internet of things (BioT): Requirements, working model,
challenges and future directions,” Wireless Netw., vol. 27, no. 1, pp. 55–90,
2021.
1948 IEEE JOURNAL OF BIOMEDICAL AND HEALTH INFORMATICS, VOL. 26, NO. 5, MAY 2022
[9] J. Tang, T. Jia, H. Chen, and C. Wei, “Research on big data storage method
based on ipfs and blockchain,” in Proc. 2nd Int. Conf. Video, Signal Image
Process., Jakarta, Indonesia, 2020, pp. 55–60.
[10] S. Saxena, B. Bhushan, and M. A. Ahad, “Blockchain based solutions to
secure iot: Background, integration trends and a way forward,” J. Netw.
Comput. Appl., vol. 181, no. 1, pp. 103050–103092, 2021.
[11] G. Tripathi, M. A. Ahad, and S. Paiva, “S2HS- a blockchain based
approach for smart healthcare system,” Healthcare, vol. 8, no. 1, pp.
100391–100402, 2020.
[12] J. Fu, N. Wang, and Y. Cai, “Privacy-preserving in healthcare blockchain
systems based on lightweight message sharing,” Sensors, vol. 20, no. 7,
pp. 1898–1913, 2020.
[13] V. Suneetha, S. Suresh, and V. Jhananie, “A novel framework using apache
spark for privacy preservation of healthcare big data,” in Proc. IEEE 2nd
Int. Conf. Innov. Mechanisms Ind. Appl., Bangalore, India, 2020, pp. 743–
749.
[14] C. Guo, P. Tian, and K.-K. R. Choo, “Enabling privacy-assured fog-based
data aggregation in e-healthcare systems,” IEEE Trans. Ind. Informat.,
vol. 17, no. 3, pp. 1948–1957, Mar. 2021.
[15] R. Qiao, X.-Y. Luo, S.-F. Zhu, A.-D. Liu, X.-Q. Yan, and Q.-X. Wang, “Dy-
namic autonomous cross consortium chain mechanism in e-healthcare,”
IEEE J. Biomed. Health Informat., vol. 24, no. 8, pp. 2157–2168,
Aug. 2020.
[16] M. U. Farooq, M. Waseem, A. Khairi, and S. Mazhar, “A critical analysis
on the security concerns of Internet of Things (IoT),” Int. J. Comput. Appl.,
vol. 111, no. 7, pp. 1–6, 2015.
[17] S. Goyal, N. Sharma, I. Kaushik, and B. Bhushan, “Chapter 10 - blockchain
as a solution for security attacks in named data networking of things,” in
Proc. Secur. Privacy Issues IoT Devices Sensor Netw. S. K. Sharma, B.
Bhushan, and N. C. Debnath, Eds, Adv. Ubiquitous Sens. Appl. Healthcare,
Academic Press, 2021, pp. 211–243.
[18] S. Tuli et al., “Next generation technologies for smart healthcare: Chal-
lenges, vision, model, trends and future directions,” Internet Technol. Lett.,
vol. 3, no. 2, pp. 145–151, 2020.
[19] A. Sharma, Sarishma, R. Tomar, N. Chilamkurti, and B.-G. Kim,
“Blockchain based smart contracts for internet of medical things in e-
healthcare,” Electron., vol. 9, no. 10, pp. 1609–1622, 2020.
[20] Y. Liu et al., “A novel cloud-based framework for the elderly healthcare
services using digital twin,” IEEE Access, vol. 7, no. 1, pp. 49088–49101,
2019.
[21] K. Fan, S. Zhu, K. Zhang, H. Li, and Y. Yang, “A lightweight authentication
scheme for cloud-based RFID healthcare systems,” IEEE Netw., vol. 33,
no. 2, pp. 44–49, Mar./Apr. 2019.
[22] A. Sunyaev, D. Chornyi, C. Mauro, and H. Krcmar, “Evaluation framework
for personal health records: Microsoft HealthVault vs. Google Health,” in
Proc. IEEE 43rd Hawaii Int. Conf. Syst. Sci., Honolulu, HI, USA, 2010,
pp. 1–10.
[23] C. Patel and N. p. Doshi, “Secure lightweight key exchange using ECC
for user-gateway paradigm,” IEEE Trans. Comput., pp. 1–1, 2020, doi:
10.1109/TC.2020.3026027.
[24] M. Fotouhi, M. Bayat, A. K. Das, H. A. N. Far, S. M. Pournaghi, and
M. Doostari, “A lightweight and secure two-factor authentication scheme
for wireless body area networks in health-care IoT,” Comput. Netw.,
vol. 177, no. 4, pp. 107333–107345, 2020.
Authorized licensed use limited to: ANNA UNIVERSITY. Downloaded on January 10,2023 at 09:18:00 UTC from IEEE Xplore. Restrictions apply.
[25] Q. Su, R. Zhang, R. Xue, and P. Li, “Revocable attribute-based signature
for blockchain-based healthcare system,” IEEE Access, vol. 8, no. 1,
pp. 127884–127896, 2020.
[26] W. Yánez, R. Mahmud, R. Bahsoon, Y. Zhang, and R. Buyya, “Data
allocation mechanism for Internet-of-Things systems with blockchain,”
IEEE Internet Things J., vol. 7, no. 4, pp. 3509–3522, Apr. 2020.
[27] M. Chen, Y. Ma, Y. Li, D. Wu, Y. Zhang, and C.-H. Youn, “Wearable 2.0:
Enabling human-cloud integration in next generation healthcare systems,”
IEEE Commun. Mag., vol. 55, no. 1, pp. 54–61, Jan. 2017.
[28] P. Bhattacharya, S. Tanwar, U. Bodke, S. Tyagi, and N. Kumar,
“Bindaas: Blockchain-based deep-learning as-a-service in healthcare 4.0
applications,” IEEE Trans. Netw. Sci. Eng., vol. 8, no. 2, pp. 1242–1255,
Apr.–Jun. 2021.
[29] S. Pinto, T. Gomes, J. Pereira, J. Cabral, and A. Tavares, “IIoTEED: An
enhanced, trusted execution environment for industrial IoT edge devices,”
IEEE Internet Comput., vol. 21, no. 1, pp. 40–47, Jan./Feb. 2017.
[30] J. S. Jang, S. Kong, M. Kim, D. Kim, and B. B. Kang, “SeCReT: Se-
cure channel between rich execution environment and trusted execution
environment,” in Proc. Netw. Distrib. Syst. Secur. Symp., 2015.
[31] W. Dai et al., “TEE: A virtual DRTM based execution environment for
secure cloud-end computing,” Future Gener. Comput. Syst., vol. 49, no. 2,
pp. 47–57, 2015.
[32] A. Dorri, S. S. Kanhere, R. Jurdak, and P. Gauravaram, “LSB: A
lightweight scalable blockchain for IoT security and anonymity,” J. Par-
allel Distrib. Comput., vol. 134, no. 1, pp. 180–197, 2019.
[33] W. Zhang, Z. Wu, G. Han, Y. Feng, and L. Shu, “LDC: A lightweight dada
consensus algorithm based on the blockchain for the industrial internet of
things for smart city applications,” Future Gener. Comput. Syst., vol. 108,
no. 2, pp- 574–582, 2020.
[34] J. Srinivas, A. K. Das, N. Kumar, and J. J. P. C. Rodrigues, “Cloud centric
authentication for wearable healthcare monitoring system,” IEEE Trans.
Dependable Secure Comput., vol. 17, no. 5, pp. 942–956, Sep./Oct. 2020.
[35] V. Odelu, A. K. Das, M. Wazid, and M. Conti, “Provably secure authen-
ticated key agreement scheme for smart grid,” IEEE Trans. Smart Grid,
vol. 9, no. 3, pp. 1900–1910, May 2018.
[36] N. Kabra, P. Bhattacharya, S. Tanwar, and S. Tyagi, “MudraChain:
Blockchain-based framework for automated cheque clearance in financial
institutions,” Future Gener. Comput. Syst., vol. 102, no. 1, pp. 574–587,
2020.
[37] Y. Chen, J.-F. Martínez, P. Castillejo, and L. López, “A bilinear map pairing
based authentication scheme for smart grid communications: Pauth,” IEEE
Access, vol. 7, no. 3, pp. 22633–22643, 2019.
[38] S. Banerjee, V. Odelu, A. K. Das, S. Chattopadhyay, and D. Giri, “Anony-
mous fine-grained user access control scheme for Internet of Things
architecture,” in Proc. 15th Int. Conf. Math. Comput. D. Giri, A. T. S.
Ho, S. Ponnusamy, and N.-W. Lo, Eds., Singapore: Springer, 2021, pp.
47–66.
[39] A. Kumari, S. Tanwar, S. Tyagi, and N. Kumar, “Fog computing for
healthcare 4.0 environment: Opportunities and challenges,” Comput. Elect.
Eng., vol. 72, no. 2, pp. 1–13, 2018.
[40] D. Prashar, N. Jha, M. Shafiq, N. Ahmad, M. Rashid, S. A. Banday, H. U.
Khan, “Blockchain-based automated system for identification and storage
of networks,” Security and Communication Networks, vol. 2021, pp. 1–7,
Article ID 6694281, 2021, doi: 10.1155/2021/6694281.