Design of Secure Authenticated Key Management Protocol For Cloud Computing Environments

This article has been accepted for publication in a future issue of this journal, but has not been
fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2020.2995917, IEEE Access
Date of publication xxxx 00, 0000, date of current version xxxx 00, 0000.
Digital Object Identifier 10.1109/ACCESS.2020.XXXXXXX
BAKMP-IoMT: Design of Blockchain

Enabled Authenticated Key Management
Protocol for Internet of Medical Things
Deployment
NEHA GARG1 , MOHAMMAD WAZID2 , (Senior Member, IEEE),
ASHOK KUMAR DAS3 , (Senior Member, IEEE), DEVESH PRATAP SINGH4 ,
JOEL J. P. C. RODRIGUES4,5 , (Fellow, IEEE), YOUNGHO PARK6 , (Member, IEEE)
1
Department of Computer Science and Engineering, Graphic Era Deemed to be University, Dehradun 248 002, India (e-mail: nehagarg.february@gmail.com)
2
Department of Computer Science and Engineering, Graphic Era Deemed to be University, Dehradun 248 002, India (e-mail: wazidkec2005@gmail.com)
3
Center for Security, Theory and Algorithmic Research, International Institute of Information Technology, Hyderabad 500 032, India (e-mail:
iitkgp.akdas@gmail.com, ashok.das@iiit.ac.in)
4
Department of Computer Science and Engineering, Graphic Era Deemed to be University, Dehradun 248 002, India (e-mail: devesh.geu@gmail.com)
4
Federal University of Piauí (UFPI), 64049-550 Teresina-Pi, Brazil (e-mail: joeljr@ieee.org)
5
Instituto de Telecomunicações, 1049-001 Lisboa, Portugal
6
School of Electronics Engineering, Kyungpook National University, Daegu 41566, Republic of Korea (e-mail: parkyh@knu.ac.kr)
Corresponding author: Youngho Park (parkyh@knu.ac.kr)
This work was supported by the Basic Science Research Program through the National Research Foundation of Korea funded by the
Ministry of Science, ICT and Future Planning under Grant 2017R1A2B1002147 and in part by the BK21 Plus project funded by the
Ministry of Education, Korea under Grant 21A20131600011. This work was partially supported in part by FCT/MCTES through national
funds and when applicable co-funded EU funds under the project UIDB/EEA/50008/2020; and in part by Brazilian National Council for
Scientific and Technological Development (CNPq) via Grant No. 309335/2017-5. This work was also supported by the Ripple Centre of
Excellence Scheme, CoE in Blockchain (Sanction No. IIIT/R&D Office/Internal Projects/001/2019), IIIT Hyderabad, India.
ABSTRACT The Internet of Medical Things (IoMT) is a kind of connected infrastructure of smart
medical devices along with software applications, health systems and services. These medical devices
and applications are connected to healthcare systems through the Internet. The Wi-Fi enabled devices
facilitate machine-to-machine communication and link to the cloud platforms for data storage. IoMT has
the ability to make accurate diagnoses, with fewer mistakes and lower costs of care. IoMT with smartphone
applications permits the patients to exchange their health related confidential and private information to
the healthcare experts (i.e., doctors) for the better control of diseases, and also for tracking and preventing
chronic illnesses. Due to insecure communication among the entities involved in IoMT, an attacker can
tamper with the confidential and private health related information for example an attacker can not only
intercept the messages, but can also modify, delete or insert malicious messages during communication.
To deal this sensitive issue, we design a novel blockchain enabled authentication key agreement protocol
for IoMT environment, called BAKMP-IoMT. BAKMP-IoMT provides secure key management between
implantable medical devices and personal servers and between personal servers and cloud servers. The
legitimate users can also access the healthcare data from the cloud servers in a secure way. The entire
healthcare data is stored in a blockchain maintained by the cloud servers. A detailed formal security
including the security verification of BAKMP-IoMT using the widely-accepted Automated Validation of
Internet Security Protocols and Applications (AVISPA) tool is performed to demonstrate its resilience
against the different types of possible attack. The comparison of BAKMP-IoMT with relevant existing
schemes is conducted which identifies that the proposed system furnishes better security and functionality,
and also needs low communication and computational costs as compared to other schemes. Finally, the
simulation of BAKMP-IoMT is conducted to demonstrate its impact on the performance parameters.
INDEX TERMS Blockchain, Internet of Medical Things (IoMT), authentication, key management,
security, simulation.
VOLUME 7, 2019 1
This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
I. INTRODUCTION or even on a hybrid blockchain, it will raise privacy issues.

Internet of Medical Things (IoMT) is an assortment of It is then recommended to consider a private blockchain in
health care systems (medical devices, software applications such an environment.
and services etc.) to provide secure transmission of health
related data between smart devices which help the remotely B. CONTRIBUTIONS OF PROPOSED WORK
located doctors, care-providers, medical test centers to store The contributions of this paper are manyfold:
and exchange health data electronically. It further provides
• We propose a novel blockchain-based authentication
real time medical services and assistance through Internet
and key management scheme for IoMT environ-
enabled smart devices like smart phones, smart medical
ment, called BAKMP-IoMT. Moreover, the private
wearable and implanted devices, electronic medical reports
blockchain is considered in the designing of BAKMP-
(EMR) etc. Other benefits of IoMT includes reduced health
IoMT. In BAKMP-IoMT, we only incorporate effi-
care costs, provides timely medical responses, fast deci-
cient one-way cryptographic hash function and bitwise
sion making and improved quality of medical treatment.
XOR operations.
Presently, billions of devices are connected to Internet of
• The formal security verification of BAKMP-IoMT us-
Things (IoT) for various verticals of applications including
ing the widely-accepted AVISPA tool is performed to
the healthcare. With this exponential growth, user’s pri-
demonstrate its resilience against various known pas-
vacy and security becomes most challenging issues in IoT
sive/active attacks, and also through non-mathematical
(especially in IoMT) and requires essential consideration.
(informal) security analysis we show that BAKMP-
Several potentials for security and privacy breaches that
IoMT is robust against other attacks, such as “replay
might occur in the healthcare systems are unauthorised
attack”, “man-in-the-middle attack”, “impersonation
access to enormous patients sensitive data (i.e., personal
attacks”, “Ephemeral Secret Leakage (ESL) attack”,
and medical records) that helps in making life critical
“privileged-insider attack”, “physical medical devices
decisions. Other malicious activities are modification of
capture attack” and “data modification attack”. More-
health data, hijacking of medical devices, gaining access to
over, BAKMP-IoMT also preserves “anonymity” and
hospitals networks and exploitation of exchanged and stored
“untraceability” properties.
information are performed to threat the lives of the patients.
• The comparison of BAKMP-IoMT with relevant ex-
This necessitates to explore optimized solutions to deal with
isting schemes is conducted, which identifies that the
the threats and attacks on IoMT. Among several security
proposed BAKMP-IoMT furnishes better security and
mechanisms blockchain has the potentials to conquer the
functionality features, and low communication and
impediments of conventional ways to deal with the security
computational costs as compared to those schemes.
and user privacy and is considered to be the backbone
• Finally, the simulation of BAKMP-IoMT is conducted
of future IoT (i.e., IoMT) applications with various bene-
to demonstrate its impact on the performance parame-
fits like enhanced security, reduced cost, true traceability,
ters.
improved speed and efficient mechanism etc. Therefore,
integrating Blockchain with IoMT can provide resilience
to several attacks related to “user authentication problem C. PAPER STRUCTURE
& key management” problem such as “replay”, “man-in- The discussion on the associated existing schemes in health-
the-middle”, “impersonation”, “password guessing”, “illegal care applications is given in Section II. The system models
session key computation”, “health data disclosure”, “denial (network and threat) are discussed in Section III. Various
of service (DoS)”, “privileged insiders”, etc., and in turn phases associated with the proposed “blockchain based
provides better healthcare services in a secured and real time authentication and key management scheme for Internet
environment. of Medical Things (BAKMP-IoMT)” have been discussed
in Section IV. The security analysis of BAKMP-IoMT
A. MOTIVATION is carried out in Section V. To make further security
As discussed earlier IoMT communication environment is analysis strong, the detailed formal security verification
vulnerable to various types of attacks. Therefore, we need using AVISPA tool has been provided in Section VI. The
some strong mechanism to secure the communication occur comparative performance analysis of BAKMP-IoMT with
in an IoMT environment. For such purpose, the mechanism relevant existing authentication schemes is also provided
of blockchain will be helpful as it is decentralized and in Section VII. Moreover, the practical demonstration of
temper-proof can resist different types of attacks. Hence, a BAKMP-IoMT using the strategies of blockchain is given
secure, blockchain-enabled authenticated key management in Section VIII. Finally, we conclude the work in Section
protocol for IoMT is proposed. Moreover, in the designing IX.
of the proposed scheme, we consider a private blockchain.
This is primarily because the healthcare data are typically II. RELATED WORK
strictly confidential and private. Therefore, if we put the con- In recent years, several authentication and access control
fidential and private health related information on a public mechanisms have been designed in Internet of Things (IoT),
2 VOLUME 7, 2019
wireless sensor networks, healthcare, and other applications (IoV)” as one of the important application of mobile vehi-
[1]–[23]. cles and wireless technologies, providing the information re-
Monrat et al. [24] surveyed the potential applications garding mobile position, direction, speed and other real time
of blockchain in diverse disciplines like healthcare, vot- information thus avoiding the traffic jams and accidents.
ing, energy trading stock exchange, insurance, education Further, proposed a decentralized authentication mechanism
etc. They also discussed the opportunities, trade off and using consensus algorithm of blockchain for IoV. They used
challenges of blockchain in respective domains. Moreover, blockchain to design new key distribution mechanism for
the taxonomy and architecture of blockchain was provided. joining the new node’s information in the blockchain ledger.
Furthermore, several other approaches to reach a consen- Lin et al. [30] focused on the limitation of the IoT system
sus in the blockchain was surveyed. Some future research due to resource constrained IoT devices and proposed an
directions of the domain were also highlighted. “outsourcing of bilinear pairings (SOBP)” integrated with
Zheng et al. [25] discussed the concepts and characteris- permissioned blockchain to address the shortcoming. Thus
tics of blockchain and identifies it’s benefits in various do- helps in overcoming the limitations of IoT. They utilized the
mains apart from “bitcoin”. Further, the authors discussed a potentials of permission blockchain (i.e., enhancing security,
number of technical challenges like scalability, privacy leak- service availability and system scalability). Finally authors
age, selfish mining associated with consensus algorithms proved and implemented the proposed system to evaluate its
“Proof of Work (PoW)” and “Proof of Stake (PoS)”. Their security, performance and feasibility.
study also focused on state-of-art of blockchain including Chaudhary et al. [31] focused on the emerging and recent
recent growth and future directions. Further, they planned technology “Tactile Internet” in the field of intelligent trans-
to work on smart contract in a detailed manner to overcome portation system and identified the need to create a secure
associated defects and limitations. energy trading ecosystem. Further, proposed a blockchain
Aggarwal et al. [26] discussed the usage of blockchain based secure energy trading scheme in electric vehicle (EVs)
in “smart communities” like “smart cities” and “smart for validating EVs request, selecting minor nodes to validate
nations” where different IoT devices are located in different the request, etc. In order to make it computationally effective
geographical regions. Processes of block creation and block i.e., low latency and provide real time services, SDN was
verification, various consensus mechanisms, cryptographic utilized as an under lying architecture.
primitives are also discussed. Further, classification of the Feng et al. [32] discussed the VANET environment i.e.,
application realm in cyber security is provided in an ex- vehicles were connected through wireless communication
tensive manner. For example, financial systems, intelligent medium. Some of the potential benefits were like intelligent
transportation systems, IoT, smart grid, healthcare networks, routing, weather monitoring emergency call etc. They also
voting systems, data center networks etc. Thereafter they identified the importance of accuracy and reliability of
discussed various process models (behavior model, govern- the communicated message. Further, proposed a frame-
ment sector, business model) where clusters are formed by work named as “blockchain assisted privacy pressuring
grouping the similar process and thus provided data security authentication system (BPAS)” that preserved the vehicle
using blockchain technology. Moreover they provided the privacy and provides automatic authentication in VANET.
information regarding communication infrastructure support Blockchain automatically checked the message credibility,
like wired and wireless networks (5G, Wifi, SDN, Mobile monitor vehicle behavior and also traced immutable com-
computing). munication record. Further security analysis was conducted
Lin et al. [27] discussed the benefit of smart homes to check the proposed framework for security and privacy
and other smart facilities for the society. At the same of VANET.
time they also focused on the risks associated with the Jindal et al. [33] proposed a framework to provide en-
remotely accessed and controlled IoT devices that could ergy trading between electric vehicles (EVs) and charging
be exploited for malicious purpose. Thus they analyzed the stations (CSs). To secure the energy trading transactions
importance of a secure and efficient remote user authenti- in software defined networking (SDN) aided vehicle to
cation and presented a system. For example, “Homechain” grid environment, consensus based blockchain was used. It
which integrates blockchain, group signatures and message reduced the latency and increased the throughout and thus
authentication code. make the proposed system effective and efficient.
Zhang et al. [28] discussed the issues in smart grid like Mingxiao et al. [34] surveyed the effectiveness of
secure communication, reliable mutual authentication and blockchain because of its decentralization, stability, security
privacy credentials, key management etc., and considered and non-modifiability properties. It identified that consen-
key management between smart meters, the most critical sus algorithm played an important role in the success of
aspect of smart grid. They presented a decentralized key- blockchain. Further, they reviewed the principles, charac-
less signature scheme using consortium blockchain which teristics, performance analysis and application scenarios of
is computationally cost effective, time effective, scalable, different consensus algorithm.
robust and efficient. Zhang et al. [35] highlighted the importance of reaching
Wang et al. [29] discussed about the “Internet of Vehicles a consensus in group decision making process (GDM) with
VOLUME 7, 2019 3
minimum cost and maximum return. Further, proposed a classification (compute-intensive based, voting based and
generalized “minimum cost soft consensus models” and capability based) and comparison among different consensus
“maximum return model” under a certain degree of con- protocols were provided.
sensus. The correlation between both the model and their Finally, in Table 1 we summarize discussed existing
economic significance was also presented. In order to prove authentication schemes with their applied cryptographic
its utility the proposed models were applied in loan con- techniques and disadvantages/limitations.
sensus problem in P2P lending utilizing data from Chinese
P2P platform and demonstrated how it helped borrowers and III. SYSTEM MODELS
lenders to attain a certain level of consensus about interest We follow the following two models in the designing of
rate. It efficiently coordinated the supply and demand in P2P BAKMP-IoMT.
lending.
Jang et al. [36] designed a “hybrid security scheme that A. NETWORK MODEL
uses both heterogeneous cryptosystems, such as symmetric BAKMP-IoMT uses network model as shown in Figure 1.
and asymmetric (public) key cryptographic techniques”. In this figure, we have a patient who is implanted with
Unfortunately, their scheme fails to maintain “anonymity medical devices such as neurostimulator, cochlear implant,
property” and also it does not support “dynamic controller cardiac pacemaker and gastric stimulator. There is personal
node addition and medical device addition”. server node (sometimes called as controller node) nearby to
He and Zeadally [37] designed another authentication the patient which collects the data from the IMDs through
protocol by using the “ambient intelligence, specifically for some wireless communication technology such as bluetooth.
an Ambient Assisted Living (AAL) system”. Their protocol Personal server then transmits the collected data to the cloud
helps in monitoring health-related information and also in server through the access point. Cloud servers receive and
providing “tele-health care services”. Their system applies store the data which can be used for the further processing.
the “wearable sensors in the wireless body area networks There are some users who are interested in accessing the
(WBANs) and assistive robotics”. data of the patient (i.e., doctor, nurse and patient’s relative).
Merabet et al. [38] discussed “Machine-to-Machine Various network entities i.e., IMDs, personal server, cloud
(M2M)” and “Machine-to-Cloud (M2C)” modes needed in server and users, in the system is registered by the trusted
the IoT-based healthcare applications. Next, they proposed authority. Patient’s data can be accessed by the user from the
two protocols: 1) Protocol-I: “M2C authentication protocol” cloud server after performing the certain steps of the user
and b) Protocol-II: “M2M authentication protocol”. Unfor- authentication process. In this model cloud servers are the
tunately, their protocols do not support “dynamic controller resource rich devices which have high processing, storage
node addition and medical device addition”. and communication capacity. Cloud server acts the miner
Chase and MacBrough [39] provided a comprehensive node in this blockchain based Internet of Medical of Things
description and carried detailed analysis of XRP ledger con- communication environment. After receiving the data from
sensus protocol (low latency Byzantine agreement protocol the personal server, cloud server (miner node) prepares a
to reach a consensus without universal agreement of network block and add this in the blockchain when it is successfully
participants. Along with providing the detailed description committed by the other miners. This kind of communica-
of the XRP ledger consensus protocol, they validated the tion environment is susceptible to different attacks such as
networks conditions required to guarantee correctness of the “replay”, “man-in-the-middle”,“ impersonation”, “password
algorithm. guessing”, “session key computation” through physical cap-
In order to achieve both anonymity and regulation prop- turing of devices, “health data disclosure” and “denial of
erties, Lin et al. [40] designed a “conditional anonymous service”. Communication between IMDs to personal server,
payment scheme” and applied the designed scheme to personal server to cloud server and cloud server to user,
construct their first “decentralized conditional anonymous must be secured. Hence, session key must be established
payment system”. As compared with the Zerocash, they between the user and the cloud server, and also between
have shown that their proposed system can be deployed for the cloud server and personal server. Since majority of
practical real-world deployment. implantable medical devices have limited resources so we
Ismail and Materwala [41] provided a detailed study select to utilize lightweight cryptographic operations (i.e.,
on the evolution of blockchain frameworks and consensus hash, XOR operations) in the different exchanged messages.
protocols. They identified the need to develop a scalable, The addition of blockchain operations at the cloud servers
cost-efficient and green blockchain frameworks to address give more resilience to this scheme against the possible
the goals for a green collaborative, decentralized and agile attacks. Therefore, we need a secure data access scheme
ecosystems like smart cities, such as health care and gov- in the blockchain based IoMT communication environment.
ernance. An overview of blockchain technology including Using this scheme the communicating entity (i.e., doctor)
blockchain layers i.e., infrastructure layer, platform layer, can securely access the data of a patient without any
distributed computing layer and application layer/business disclosure. Moreover, in our proposed scheme (BAKMP-
logic were also presented. Furthermore, the taxonomy, IoMT), we consider only a private blockchain because the
4 VOLUME 7, 2019
TABLE 1. Summary of various cryptographic techniques used and limitations of existing authentication schemes
Scheme Cryptographic Techniques Drawbacks/Limitations

Jang et al. [36] * Uses a hybrid security scheme that applies both heterogeneous * Does not preserve anonymity property
cryptosystems (symmetric and public key cryptosystems) * Does not support dynamic controller node addition
* Uses “Elliptic Curve Cryptography (ECC)” primitives * Does not support dynamic medical device addition
and one-way cryptographic hash function * Does not support blockchain solution
He and Zeadally [37] * Based on authentication using Ambient Assisted Living (AAL) system * Does not support dynamic controller node addition
* Applies wearable sensors in WBANs and assistive robotics * Does not support dynamic medical device addition
* Uses ECC primitives, symmetric encryption/decryption * Does not support blockchain solution
and one-way cryptographic hash function
Merabet et al. [38] * Based on M2C authentication protocol * Does not support dynamic medical device addition
* Based on M2M authentication protocol * Does not support dynamic medical device addition
* Uses ECC primitives and * Does not provide session key security
one-way cryptographic hash function * Insecure against stolen mobile device/programmer attack
* Does not support blockchain solution
FIGURE 1. Network model of blockchain based IoMT communication environment
healthcare data is fully confidential and private. As a result, model, A can have all the potentialities as in the DY
if these data is somehow put on a public or even on a hybrid model along with that he/she can compromise the secret
blockchain, privacy issues related to healthcare data will credentials and with the session states (session keys) in
arise. the sessions. Apart from that A can physical capture some
IMDs, personal servers or the mobile device of the users
B. THREAT MODEL and extracts the stored information from these devices by
BAKMP-IoMT is designed using the guidelines of widely- utilizing the sophisticated power analysis attack [45]. This
used (DY) threat model [42]. According to DY model any derived information can be used to perform other malicious
two communicating parties communicate over an open inse- activities for example acquiring of secret credentials and
cure channel and also, the end-point entities such as IMDs, session key computations, “device impersonation attack”,
personal server and users are not in general trustworthy. “replay attack”, “privileged-insider attack” and “man-in-the-
An adversary (A) can read (eavesdrop) the communicated middle attack”. At long Last, the trusted authority (T A)
messages and can also modify or delete the transmitted is thought to be full trusted entity in the network and it
messages over insecure channel. We also follow Canetti and won’t be compromised. Moreover, cloud servers acts as the
Krawczyk’s adversary model, known as the CK-adversary miners in the network. Hence, they are also considered as
model [43], [44] which is current de facto standard model the trusted entities.
in the modeling of an “authenticated key-agreement security
protocol”. According to the assumptions of CK-adversary
VOLUME 7, 2019 5
TABLE 2. Notations utilized in BAKMP-IoMT IoMT lightweight as IMDs are resource constraint in nature.
Symbol Explanation
For biometric verification, we utilize the fuzzy extractor
A An adversary at the user side only. In order to provide better security,
Ui , M D i ith user and his/her mobile device, respectively expensive computations are carried on resource-rich devices
IDUi , RIDUi , Ui ’s identity, his/her Pseudo identity,
P WUi , BIOUi password and biometric, respectively i.e., user’s mobile device and cloud server, in the network
T A, IDT A Trusted authority and its identity
IM Dk , IDIM Dk kth implantable medical
[51].
device and its identity It is worth noticing that the trusted authority (T A) only
P Sl , IDP Sl lth Personal server and its identity
CSj , IDCSj j th Cloud server (miner) and its identity involves during the registration phase, which is one-time
N
RIDIM Dk , RIDP Sl
160-bit secret key of T A
Pseudo identities of IM Dk and P Sl , respectively
process. The T A does not have any other role in our pro-
RIDCSj , RIDT A Pseudo identities of CSj and T A, respectively posed system. Moreover, the T A does not take any partici-
BIM Dk Block in a blockchain for
kth implantable medical device data
pation in active role during the communication (for example,
h(dIM Dk ) Hash value of BIM Dk key management phase, user login and authentication & key
dIM Dk Data send by IM Dk
KPIM Dk Private key for IM Dk agreement phases, and blockchain construction and addition
KUIM Dk Public key for IM Dk phase). In addition, even the T A does not know what
EKPIM D (h(dIM D )) Encryption using KPIM Dk on h(dIM Dk )
k
CIM Dk [KUIM Dk ]
k
Certificate contains public key kind of information the entities exchange and what are the
for the encrypted data of IM Dk values of established session keys among various network
h(dIM Dk−1 ) Hash value of previous block for IM Dk−1
nIM D Number of IMDs to be deployed entities. Hence, it will be definitely a risky task to involve
T1 , T2 , T3 Current timestamps
∆T Maximum transmission delay the cloud servers for the registration of different network
Gen(·) Generation process in fuzzy extractor entities, and in that situation, some active attacks, such
Rep(·) Reproduction process in fuzzy extractor
σUi Biometric secret key of Uh for BIOUh as “privileged insider attack”, “illegal credential leakage
τUi Public reproduction parameter of Uh for BIOUh
t Error tolerance threshold required by fuzzy extractor attack” and “unauthorised session key computation attack”
h(·) Cryptographic one-way hash function may be possible. As a result, we utilize only the trusted
SKX−Y (= SKY −X ) Session key between entity X and entity Y
||, ⊕ Concatenation & bitwise XOR operations, respectively authority (T A) for the purpose of registration of various
ECDSA Elliptic curve digital signature algorithm for
signature generation and verification on a block
network entities instead of the cloud servers.
x 160-bit secret number of Ui
Eq (a, b) A non-singular elliptic curve of the form:
“y 2 = x3 + ax + b (mod q) with A. PRE-DEPLOYMENT
4a3 + 27b2 6= 0 (mod q)”
G A base point in Eq (a, b) whose order is In this phase the registration of various network entities is
no as big as q
k.G Elliptic curve point multiplication: done by T A. The pre-deployment phase is explained below.
k.G = G + G + · · · + G (k times)
rCSj Private key of CSj
P ubCSj Public key of CSj , where P ubCSj = rCSj · G 1) IMD registration
The T A selects a unique identity IDIM Dk for implantable
medical device IM Dk and computes corresponding pseudo-
IV. THE PROPOSED SCHEME identity RIDIM Dk = h(IDIM Dk ||N ) where the T A’s se-
In the designing of the proposed blockchain enabaled au- cret key is N . Thereafter, the T A choosePat exclusive “sym-
thentication key agreement protocol for IoMT environment metric bivariate polynomial” χ(x, y) = m,n=0 am,n xm y n
(BAKMP-IoMT), we use following phases. The different ∈ GF (p)[x, y] of degree t over a finite field (Galois field)
notations used in explaining and analyzing BAKMP-IoMT GF (p) (= Zp ), where the co-efficients ai,j ’s are selected
are given in Table 2. BAKMP-IoMT includes following from GF (p) and Zp = {0, 1, 2, · · · , p − 1} with p being an
eight stages: 1) pre-deployment, 2) key management, 3) user adequately large prime and t is sufficiently greater than the
registration, 4) login, 5) authentication & key agreement, total count of IMDs to be deployed. For instance, a bivariate
6) Blockchain construction and addition, 7) password & polynomial χ(x, y) = x4 + 3x3 + 2x2 y 2 + 3y 3 + y 4 over
biometric update and 8) dynamic IMD addition. GF (5) is symmetric as χ(y, x) = y 4 + 3y 3 + 2y 2 x2 + 3x3 +
In order to improve the security of BAKMP-IoMT, fol- x4 = χ(x, y). Furthermore, Pt T A computes a polynomial
lowing three factors are used for authentication purpose : 1) share χ(RIDIM Dk , y) = m,n=0 [am,n (RIDIM Dk )m ]y n ,
mobile device M DUi of a user Ui which stores significant which is certainly a univariate polynomial of the same
credentials required for authentication, 2) password of Ui , degree t. Then T A stores the credentials {RIDIM Dk ,
and 3) personal biometric of Ui . To safeguard against χ(RIDIM Dk , y)} in IM Dk ’s memory before their imple-
replay attack, different random nonces (numbers) and cur- mentation. Note that for safeguarding unconditional security
rent timestamps are utilized. Moreover, all the network and t-collusion resistant property against IMD physical
entities participating in BoMT communication environment capture attack by an adversary A [52], [53], it is necessary to
are assumed to be synchronized with their clocks. This is achieve the property t >> nIM D . This is because if greater
a fair assumption, which is included in the designing of than t IMDs are not trapped by A, the original polynomial
several newly proposed authentication protocols [46], [47], χ(x, y) will not be computed by the compromised polyno-
[48], [49], [50]. We utilize cryptographic one-way hash mial shared from these IMDs’s memory respectively.
function and bitwise XOR operations to form BAKMP-
6 VOLUME 7, 2019
2) Personal server registration = h(ω 0 ||T IP1 ) and M S10 = h(SKIM Dk ,P Sl ||T IP2 ).
The T A first chooses his/her own identity IDT A Then IM Dk checks whether M S10 = M S1 . If the
and computes corresponding pseudo-identity RIDT A condition is fulfilled, the calculated secret pairwise key
= h(IDT A ||N ). T A further selects a unique iden- is correct.
tity IDP Sl for personal server P Sl and computes cor- Later on, both IM Dk and P Sl store SKIM Dk ,P Sl (=
responding pseudo-identity RIDP Sl = h(IDP Sl ||N ) SKP Sl ,IM Dk ) for their future secure communication. This
using the T A’s secret key N and temporal creden- phase is summarized in Figure 2.
tial T CP Sl = h(IDP Sl ||IDT A ||RT SP Sl ||N ) where
the registration timestamp of P Sl is RT SP Sl . T A IM Dk P Sl
then share χ(RIDP Sl , y) = Generate T IP1 .
Pt computes the polynomial m n
< RIDIM Dk , T IP1 >
[a (RID ) ]y for each P Sl , where −−−−−−−−−−−−−−−−→
m,n=0 P m,n P Sl (via open channel)
t
χ(x, y) = m,n=0 am,n xm y n ∈ GF (p)[x, y] is the same Check |T IP1 − T IP1∗ | ≤ ∆T .
If so, generate T IP2 .
symmetric bivariate polynomial of degree t that is pre- Compute ω = χ(RIDP Sl , RIDIM Dk ),
viously chosen in Section IV-A1. Then T A stores the SKP Sl ,IM Dk = h(ω||T IP1 ),
M S1 = h(SKP Sl ,IM Dk ||T IP2 ).
information {RIDP Sl , T CP Sl , RIDT A , χ(RIDP Sl , y))} < RIDP Sl , M S1 , T IP2 >
←−−−−−−−−−−−−−−−−−−−
in P Sl ’s database before its deployment. (via open channel)
Check |T IP2 − T IP2∗ | ≤ ∆T .
If so, compute ω 0 = χ(RIDIM Dk , RIDP Sl ),
3) Cloud server (miners) registration SKIM Dk ,P Sl = h(ω 0 ||T IP1 ),
M S10 = h(SKIM Dk ,P Sl ||T IP2 ).
The T A first chooses a unique identity IDCSj for cloud Check M S10 = M S1 .
server CSj and computes corresponding pseudo-identity If valid, secret key is authentic.
Both IM Dk and P Sl store SKIM Dk ,P Sl (= SKP Sl ,IM Dk )
RIDCSj = h(IDCSj ||N ) using the T A’s secret key N .
After that T A stores the information {RIDCSj , RIDT A } FIGURE 2. Summary of key management between implantable medical
device and personal server
in CSj ’s database before its deployment.
B. KEY MANAGEMENT 2) Key management between personal server and cloud

Key management phase is required to secure the communi- server
cation between IM Dk to P Sl and P Sl to CSj . After the To establish secret pairwise key between a personal server
successful completion of all steps of key management phase P Sl and a cloud server CSj following steps are performed:
IM Dk to P Sl and P Sl to CSj establish secret pairwise • P Sl first produces a random nonce r1 and a current
keys for their secure communication. timestamp T P C1 and calculates M1 = h(r1 ||T CP Sl )
⊕RIDT A and M2 = h(h(r1 ||T CP Sl ) ||RIDT A
1) Key management between implantable medical device ||T P C1 ). P Sl then sends message {M1 , M2 , T P C1 }
and personal server to CSj via open channel.
To establish secret pairwise key between an implantable • After receiving {M1 , M2 , T P C1 }, CSj examines the
medical device IM Dk and a personal server P Sl following timeliness of T P C1 by the expression |T P C1 −
steps are used: T P C1∗ | ≤ ∆T , where T P C1∗ is the receiving times-
• IM Dk first generates current timestamp T IP1 and tamp of the message. If it is valid, CSj com-
sends the message {RIDIM Dk , T IP1 } to P Sl via putes h(r1 ||T CP Sl ) = M1 ⊕ RIDT A and M20 =
open channel. h(h(r1 ||T CP Sl )||RIDT A ||T P C1 ). Then CSj checks
• After receiving {RIDIM Dk , T IP1 }, P Sl exam- whether M20 = M2 , if so P Sl is authenticated with
ines the timeliness of T IP1 by the expression CSj ; Otherwise CSj immediately terminates the ses-
|T IP1 − T IP1∗ | ≤ ∆T , where T IP1∗ denotes the sion with P Sl . Further, CSj produces a random nonce
receiving timestamp of the message. If it is valid, r2 and a current timestamp T P C2 , and computes
P Sl again produce current timestamp T IP2 cal- M3 = h(r2 ||RIDCSj ) ⊕ RIDT A . After that CSj
culates ω = χ(RIDP Sl , RIDIM Dk ), the secret computes secret key SKCSj ,P Sl = h(h(r2 ||RIDCSj )||
key SKP Sl ,IM Dk = h(ω||T IP1 ) and M S1 = RIDT A ||h(r1 ||T CP Sl )|| T P C1 ||T P C2 ) and M4 =
h(SKP Sl ,IM Dk ||T IP2 ). P Sl then transmits the mes- h(SKCSj ,P Sl ||T P C2 ) then transmits the message
sage {RIDP Sl , M S1 , T IP2 } to IM Dk through public {M3 , M4 , T P C2 } to P Sl through public channel.
channel. • After receiving {M3 , M4 , T P C2 } from CSj , P Sl sub-
• After receiving {RIDP Sl , M S1 , T IP2 } from P Sl , stantiates the timeliness of T P C2 by examining if
IM Dk substantiate the timeliness of T IP2 by inves- |T P C2 − T P C2∗ | ≤ ∆T is valid, where T P C2∗ is the
tigating if |T IP2 − T IP2∗ | ≤ ∆T is valid, where receiving time of the message. If T P C2 is success-
T IP2∗ is the receiving time of the message. If fully verified, P Sl computes h(r2 ||RIDCSj ) = M3 ⊕
T IP2 is successfully verified, IM Dk computes ω 0 = RIDT A , secret key SKP Sl ,CSj = h(h(r2 ||RIDCSj )||
χ(RIDIM Dk , RIDP Sl ), the secret key SKIM Dk ,P Sl RIDT A ||h(r1 ||T CP Sl )|| T P C1 ||T P C2 ) and M40 =
VOLUME 7, 2019 7
h(SKP Sl ,CSj ||T P C2 ). Then P Sl checks whether α = h(RIDUi || RIDT A ||RT SUi ), where RT SUi is
M40 = M4 , if so CSj is authenticated with P Sl and the registration timestamp generated for Ui by T A. T A
computed session key is correct. then prepares a registration reply for Ui as hRIDUi ,
• Further P Sl generates a current timestamp T P C3 and α, RIDT A , h(·)i and send that to Ui through a secure
computes M5 = h(SKP Sl ,CSj ||T P C3 ) sends message channel.
{M5 , T P C3 } to CSj through open channel. After • Step REG3. After receiving registration reply
receiving {M5 , T P C3 } from P Sl , CSj verifies the hRIDUi , α, RIDT A , h(·)i from T A, Ui selects a
timeliness of T P C3 by examining if |T P C3 − T P C3∗ | password P WUi according to his/her liking and also
≤ ∆T is valid, where T P C3∗ is the receiving time furnish biometric data BIOUi to the terminal of a
of the message. If it holds CSj computes M50 = specific device. M DUi then determines (σUi , τUi ) =
h(SKCSj ,P Sl ||T P C3 ) and check whether M50 = M5 , Gen(BIOUi ), where σUi and τUi are the biometric
if so CSj confirms that P Sl computed the correct secret key of l bits and public reproduction parameter.
secret key. • Step REG4. Ui selects 160-bit secret number x
At the end, both P Sl and CSj store SKP Sl ,CSj (= and computes pseudo-random password RP WUi =
SKCSj ,P Sl ) for their future secure communication. This h(P WUi ||x), other parameters such as β = x ⊕
0
phase is summarized in Figure 3. h(IDUi || P WUi ||σUi ), RIDU i
= RIDUi ⊕ h(P WUi ||
σUi ), RIDT A = RIDT A ⊕h(IDUi ||x|| σUi ), α0 = α⊕
0
P Sl CSj h(x||P WUi || σUi ), δ = h(α||RP WUi ||σUi ) and EQ =

Generate r1 & T P C1 . h(IDUi || RIDT A ||δ). Finally, M DUi of Ui stores the
Compute M1 = h(r1 ||T CP Sl ) ⊕ RIDT A , 0
M2 = h(h(r1 ||T CP Sl )||RIDT A ||T P C1 ). information {RIDU i
, RIDT0 A , α0 , EQ, β, τUi , h(·),
< M1 , M2 , T P C1 >
−−−−−−−−−−−−−−→
Gen(·), Rep(·), t} in its memory. Ui discards the
(via open channel)
Check |T P C1 − T P C1∗ | ≤ ∆T . If so,
information hRIDUi , RIDT A , α, xi from M DUi ’s
compute h(r1 ||T CP Sl ) = M1 ⊕ RIDT A , memory as a means to safeguard the lost/stolen smart
M20 = h(h(r1 ||T CP Sl )||RIDT A ||T P C1 ).
Check M20 = M2 .
card/mobile device attack by an adversary.
If so, generate r2 & T P C2 , • Step REG5. For the secure communication between
compute M3 = h(r2 ||RIDCSj ) ⊕ RIDT A ,
SKCSj ,P Sl = h(h(r2 ||RIDCSj )||RIDT A || T A and CSj , we assume a master symmetric key
h(r1 ||T CP Sl )||T P C1 ||T P C2 ), M KT A−CSj . After Ui ’s successful registration, T A
M4 = h(SKCSj ,P Sl ||T P C2 ).
< M3 , M4 , T P C2 > transmits the information {RIDUi } encrypted utilizing
←−−−−−−−−−−−−−−
(via open channel) the symmetric key M KT A−CSj , and then the CSj
Check |T P C2 − T P C2∗ | ≤ ∆T . If so,
compute h(r2 ||RIDCSj ) = M3 ⊕ RIDT A ,
decrypts the received information utilizing the same
SKP Sl ,CSj = h(h(r2 ||RIDCSj )||RIDT A || symmetric key M KT A−CSj to store it in its database.
h(r1 ||T CP Sl )||T P C1 ||T P C2 ),
M40 = h(SKP Sl ,CSj ||T P C2 ). Finally, the CSj accumulates information {RIDCSj ,
Check M40 = M4 . RIDT A , RIDUi } in its database.
If so, generate T P C3 and compute
M5 = h(SKP Sl ,CSj ||T P C3 ).
< M5 , T P C3 > This phase is abridged in Figure 4.
−−−−−−−−−−−→
(via open channel)
Check |T P C3 − T P C3∗ | ≤ ∆T .
If so, compute M50 = h(SKCSj ,P Sl ||T P C3 ). User with mobile device (Ui /M DUi ) Trusted authority (T A)
Check M50 = M5 .
If valid, computed secret key is correct. Select identity IDUi .
Both P Sl and CSj store SKP Sl ,CSj (= SKCSj ,P Sl ) hIDUi i
−−−−−−−−− −−−→
(via secure channel)
FIGURE 3. Summary of key management between personal server and cloud
Compute RIDUi = h(IDUi ||N ),
server
α = h(RIDUi || RIDT A ||RT SUi ).
hRIDUi , α, RIDT A , h(·)i
←−−−−− −−−−−−−−−−−−−
(via secure channel)
C. USER REGISTRATION Choose P WUi .
Input BIOUi .
For accessing the data of IM Dk in a “blockchain based Compute (σUi , τUi ) = Gen(BIOUi ).
Internet of Medical Things” communication, user (i.e., doc- Choose x.
Compute RP WUi = h(P WUi ||x),
tor) Ui is registered using User registration method. For β = x ⊕ h(IDUi || P WUi ||σUi ),
this purpose, Ui requires secure registration at the trusted RIDU 0
i
= RIDUi ⊕ h(P WUi || σUi ),
authority T A either in person or through a secure channel RIDT0 A = RIDT A ⊕ h(IDUi ||x|| σUi ),
0
α = α ⊕ h(x||P WUi || σUi ),
using the below mentioned steps: δ = h(α||RP WUi ||σUi ),
EQ = h(IDUi || RIDT A ||δ).
• Step REG1. Ui /M DUi chooses his/her identity IDUi M DUi stores {RIDU 0
, RIDT0 A , α0 , EQ, β,
and sends the request for registration hIDUi i to T A i
τUi , h(·), Gen(·), Rep(·), t}.
securely. FIGURE 4. Summary of user registration phase
• Step REG2. After receiving registration request, T A
computes Ui ’s pseudo identity as RIDUi = h(IDUi
||N ). T A also computes temporal credential of Ui as
8 VOLUME 7, 2019
D. LOGIN PHASE • Step AU3. After receiving authentication reply

In order to login into the system, Ui is required to execute M sg2 = hM3 , M4 , T S2 i from CSj0 , Ui first ex-
the below mentioned steps: amines the timeliness of T S2 by the expression
• Step LOG1. Ui furnishes his/her identity IDUi and
|T S2 − T S2∗ | ≤ ∆T , where the maximum trans-
password P WU0 i and also marks biometrics information mission delay is indicated by ∆T and T S2∗ is
BIOU 0
at the sensor of the specified device. M DUi the reception time of the message hM3 , M4 , T S2 i.
i
computes biometric secret key σU 0
= Rep(BIOU 0
, If it matches, Ui computes h(rCSj0 ||RIDCSj0 ) =
i i
0
τUi ) with the constraint that the hamming distance M3 ⊕ h(RIDUi ||RIDT A ), session key SKUi ,CSj0 =
between the actual biometrics BIOUi furnished at the h(rUi ||RIDUi ||T S1 ||T S2 ||h(rCSj0 ||RIDCSj0 )||RIDT A )
time of user registration process and currently provided and M40 = h(SKUi ,CSj0 ||T S2 ). Further Ui verifies
BIOU 0
is less than or equal to the error tolerance the equality of the equation M40 = M4 . If it holds,
i
threshold value t. CSj0 is authenticated by Ui and calculated session key
• Step LOG2. M DUi next computes other parameters is correct. Else, Ui terminates the session with CSj0
such as x = β ⊕ h(IDUi || P WU0 i ||σU 0
), RP WU0 i = immediately.
i
0 0
h(P WUi ||x), RIDUi = RIDUi ⊕ h(P WUi || σU 0
), • Step AU4. Then Ui generates the current timestamp
i
RIDT A = RIDT A ⊕ h(IDUi ||x|| σUi ), α = α0 ⊕
0 0 T S3 and computes M5 = h(SKUi ,CSj0 ||T S3 ), and then
h(x||P WUi || σU 0
), δ 0 = h(α||RP WU0 i ||σU 0
). After the sends message M sg3 = hM5 , T S3 i to CSj0 via open
i i
computation of these parameters, M DUi also calcu- channel for cross verification of computed session key.
lates EQ0 = h(IDUi || RIDT A ||δ 0 ), and then examines After receiving authentication reply M sg3 = hM5 ,
the equality of EQ0 = EQ. If it results in a match, T S3 i from Ui , CSj0 first examines the timeliness of
M DUi validates the authenticity of Ui locally, else the T S3 by the condition |T S3 − T S3∗ | ≤ ∆T , where the
login phase ends immediately. maximum transmission delay is denoted by ∆T and
• Step LOG3. M DUi generates the current timestamp T S3∗ is the reception time of the message hM5 , T S3 i.
T S1 besides with 128-bit random nonce rUi . M DUi If it matches, Ui computes M50 = h(SKCSj0 ,Ui ||T S3 )
then calculates M1 = rUi ⊕ h(RIDT A ||RIDUi ) and and examines M50 = M5 . If it holds, CSj0 confirms that
M2 = h(rUi ||RIDUi ||RIDT A ||T S1 ). Finally, M DUi computed session key by Ui is correct.
sends the message M sg1 = hM1 , M2 , T S1 i as a login For their secure communication in future , both Ui and
request to the CSj via insecure channel. CSj0 store SKUi ,CSj0 (= SKCSj0 ,Ui ) at the end. Login and
authentication & key agreement phases are summarized in
E. AUTHENTICATION AND KEY AGREEMENT PHASE Figure 5.
After receiving the login request hM1 , M2 , T S1 i from Ui ,
the specified steps are executed between a user Ui and cloud F. BLOCKCHAIN CONSTRUCTION AND ADDITION
server i.e., CSj0 which provides service to Ui . After the PHASE
successful completion of these steps, mutual authentication To serve this purpose, an implantable medical device
is achieved between communicating parties Ui and CSj0 IM Dk , personal server P Sl , cloud server CSj and user
and for their secure communication, session Key is also Ui can perform following steps:
established.
• Step BDA1. When IM Dk has to send some data
0
• Step AU1. CSj first examines the timeliness of to P Sl , it first generates a current timestamp T P1
T S1 by the expression |T S1 − T S1∗ | ≤ ∆T , where and prepares a message by applying the encryption
the maximum transmission delay is denoted by ∆T using the computed and established pairwise secret
and T S1∗ is the reception time of the message key SKIM Dk ,P Sl , say msg1 = ESKIM Dk ,P Sl (dIM Dk ,
hM1 , M2 , T S1 i. If it matches, CSj0 computes rUi = T P1 ) and sends this to P Sl via open chan-
M1 ⊕ h(RIDT A ||RIDUi ) and M20 = h(rUi ||RIDUi || nel. After receiving msg1 = ESKIM Dk ,P Sl (dIM Dk ,
RIDT A ||T S1 ) by using the stored value RIDUi for T P1 ) from IM Dk , P Sl decrypts the message
user Ui . Further CSj0 verifies the equality of the equa- ESKIM Dk ,P Sl (dIM Dk , T P1 ) to get the values of
tion M20 = M2 . If it holds, Ui is authenticated by CSj0 . dIM Dk and T P1 . P Sl then examines the timeliness
Else, CSj0 terminates the session with Ui immediately. of T P1 by the expression |T P1 − T P1∗ | ≤ ∆T ,
0
• Step AU2. Then CSj generates the current timestamp where T P1∗ is the receiving timestamp of the message.
T S2 along with 128-bit random nonce rCSj0 and com- If it holds, P Sl generates a current timestamp T P2
putes M3 = h(rCSj0 ||RIDCSj0 ) ⊕ h(RIDUi ||RIDT A ). and prepares a message by applying the encryption
Further CSj0 computes the session key SKCSj0 ,Ui = using the computed and established pairwise secret key
h(rUi ||RIDUi ||T S1 ||T S2 ||h(rCSj0 ||RIDCSj0 )||RIDT A ) SKP Sl ,CSj as msg2 = ESKP Sl ,CSj (dIM Dk , T P2 ) and
and M4 = h(SKCSj0 ,Ui ||T S2 ). After that CSj0 sends sends this to CSj via open channel.
authentication reply M sg2 = hM3 , M4 , T S2 i to Ui • Step BDA2. In the proposed model, the cloud servers
through open channel. act as the miner nodes. Each cloud server receives the
VOLUME 7, 2019 9
Ui /M DUi CSj0 and T P2 . Next, CSj examines the timeliness of T P2

Input IDUi & P WU0 i .
Imprint biometrics BIOU 0
.
by the expression |T P2 − T P2∗ | ≤ ∆T , where T P2∗ is
i
Compute σU 0
i
= Rep(BIOU 0
i
, τU0 i ), the receiving timestamp of the message. If it holds, the
0 0
x = β ⊕ h(IDUi || P WUi ||σU ),
RP WU0 i = h(P WU0 i ||x),
i message is treated as a valid one.
0
RIDUi = RIDUi ⊕ h(P WUi || σU 0 0
i
), • Step BDA3. Using data dIM Dk , CSj starts the pro-
RIDT A = RIDT0 A ⊕ h(IDUi ||x|| σU 0
i
), cedure of block creation and its addition into the
0 0 0
α = α ⊕ h(x||P WUi || σUi ),
0 0 0
δ = h(α||RP WUi ||σUi ), blockchain. The procedure is explained as follows.
EQ0 = h(IDUi || RIDT A ||δ 0 ). Here, the details of generating a block by the CSj
Check EQ0 = EQ. If so,
generate T S1 & rUi . and verification of the created block by the P2P
Calculate M1 = rUi ⊕ h(RIDT A ||RIDUi ), cloud server (CS) network is provided. The block
M2 = h(rUi ||RIDUi ||RIDT A ||T S1 ).
< M1 , M2 , T S1 > is added in the blockchain when the consensus is
−−−−−−−−−−−−→
(via open channel) successfully committed among all the cloud servers in
Check |T S1 − T S1∗ | ≤ ∆T . If so,
compute rUi = M1
P2P CS network. The structure of block is depicted
⊕h(RIDT A ||RIDUi ), in Figure 6. After successfully collecting the data
M20 = h(rUi ||RIDUi || RIDT A ||T S1 ).
Check M20 = M2 . If so,
dIM Dk , CSj builds the transactions of the collected
generate T S2 & rCSj0 . data. Let T x1 , T x2 , · · · , T xnt be the transactions
Compute M3 = h(rCSj0 ||RIDCSj0 ) generated during a session by the CSj . The creation
⊕h(RIDUi ||RIDT A ),
SKCSj0 ,Ui = h(rUi ||RIDUi ||T S1 ||T S2 || of a block, say BLKi , contains the transactions T x1 ,
h(rCSj0 ||RIDCSj0 )||RIDT A ), T x2 , · · · , T xnt as provided in Figure 6. The concept of
M4 = h(SKCSj0 ,Ui ||T S2 ).
private blockchain is used in the BAKMP-IoMT for the
< M3 , M4 , T S2 >
←−−−−−−−−−−−−− better secrecy and confidentiality of the information.
(via open channel)
Check |T S2 − T S2∗ | ≤ ∆T . If so The block BLKi can be formed as follows.
0 0
compute h(rCS j
||RIDCS j
) = M3 ⊕
h(RIDUi ||RIDT A ), – A public key encryption E(·) is used to en-
SKUi ,CSj0 = h(rUi ||RIDUi ||T S1 || crypt all the transactions utilizing public key
T S2 ||h(rCSj0 ||RIDCSj0 )||RIDT A ),
M40 = h(SKUi ,CSj0 ||T S2 ). P ubCSj (for BAKMP-IoMT, we employ the “ECC
Check M40 = M4 . encryption”). , Next, the encrypted transactions
If so, generate T S3 .
Compute M5 = h(SKUi ,CSj0 ||T S3 ).
EP ubCSj (T xi ), (i = 1, 2, · · · , nt ), are utilized to
< M5 , T S3 > compute the “Merkle tree root” (M R) by building
−−−−−−−−−→
(via open channel) the “ Merkle tree”.
Check |T S3 − T S3∗ | ≤ ∆T . If so,
compute M50 = h(SKCSj0 ,Ui ||T S3 ). – The hash of the information {BV er, P BHash,
Check M50 = M5 . M R, T R, OB, P ubGSS , block payload (en-
If so, session key is authentic.
Both Ui and CSj0 store SKUi ,CSj0 (= SKCSj0 ,Ui )
crypted transactions)} is computed for the current
hash block (CBHash).
FIGURE 5. Summary of login and authentication phases
– Further, the ECDSA signature, say BSign = (rm ,
sm ) on the message msg = CBHash is com-
Block Header
puted using the ECDSA signature generation al-
Block Version BV er
Previous Block Hash P BHash
gorithm [54] on the current hash block CBHash.
Merkle Tree Root MR When the block BLKi is built by CSj , this block is
Timestamp TR forwarded to other miner nodes (cloud servers) in the
Owner of Block OB
Public Key of Owner P ubCSj
P2P CS network. For the verification and addition of
Block Payload (Encrypted Transactions)
the constructed block (i.e., BLKi ) using the consensus
Encrypted Transaction #1 EP ubCSj (T x1 )
algorithm by P2P CS network, the following steps are
Encrypted Transaction #2 EP ubCSj (T x2 ) needed to be executed.
.. .. – When a block BLKi is received by a cloud server,
. .
Encrypted Transaction #nt EP ubCSj (T xnt ) a miner (cloud server CSj ) will be chosen as a
Current Block Hash CBHash leader, say L from the all available cloud servers
Signature on Block using ECDSA BSign in the P2P CS network using the existing leader
FIGURE 6. Formation of a block BLKi on the transactions by CSj selection process described in [55].
– The “Ripple Protocol Consensus Algorithm
(RPCA)” [56] for block verification and addition
data of the patient from the personal server through via voting method is utilized. It is also assumed
the established secret key securely between the cloud that each cloud server CS in the P2P CS net-
server and the personal server. After receiving msg2 = work has an ECC-based private-public key pair
ESKP Sl ,CSj (dIM Dk , T P2 ), CSj decrypts the message (rCS , P ubCS ), where P ubCS = rCS · G.
ESKP Sl ,CSj (dIM Dk , T P2 ) to get the values of dIM Dk – Moreover, the public keys of other cloud servers
10 VOLUME 7, 2019
are accessible to CS. Algorithm 1 Consensus procedure for block verification and
– Algorithms 1 and 2 are used to explain this pro- addition in blockchain
cess, which is similar to the consensus mechanism Input: Given a block BLKi = {BV er, P BHash, M R, T R,
OB,P ubCSj , {EP ubCSj (T xs ) |s = 1, 2, · · · , nt }, CBHash,
applied in [1].
BSign}; private-public keys pairs (rCSj , P ubCSj = rCSj · G)
• Step BDA4. Suppose a user Ui needs to access se- for all other cloud servers in the P2P CS network.
cret information dIM Dk from BIM Dk . For this issue, Output: Verification and addition of BLKi in the
his/her request goes to the corresponding cloud server blockchain.
(miner node, i.e., CSj0 ). Furthermore, note that CSj 1: First, a leader (L) is selected among the peer nodes in the
and CSj0 maintain a common ledger. Therefore, CSj0 P2P CS network using the existing leader selection process
described in [55]. Assume L has a block BLKi = {BV er,
has access BIM Dk . CSj0 extracts dIM Dk from BIM Dk P BHash, M R, T R, OB, P ubCSj , {EP ubCSj (T xs ) |s =
by applying the operations of blockchain. For exam- 1, 2, · · · , nt }, CBHash, BSign}.
ple, CSj0 extracts KUIM Dk from certificate part of 2: L sets V T Count ← 0, where V T Count signifies the vote
BIM Dk . CSj0 further applies the hash function h(·) on counter.
data dIM Dk and gets h(dIM Dk ). CSj0 then decrypts L also sets f lagCSj0 = 0, ∀{j 0 = 1, 2, · · · , ncs , L 6= CSj0 },
EKPIM Dk (h(d0IM Dk )) and again gets h(d0IM Dk ). If where ncs is the number of cloud servers in the P2P CS
both hashes are equal, that is, h(d0IM Dk ) = h(dIM Dk ), network.
3: L creates distinct random nonce rnj and a current timestamp
the block BIM Dk was not modified; otherwise, CSj0 T Sj for each cloud server.
discards the data of BIM Dk . 4: L encrypts rnj with the public key P ubCSj of each CSj as
0
• Step BDA5. Ui and CSj already established the EP ubCSj (rnj , T Sj ).
session key SKCSj ,Ui . Therefore, CSj0 generates a 5: L sends the message SM sgj = {BLKi ,
current timestamp T P3 , and computes a message EP ubCSj (rnj , T Sj ), T Sj } to all other cloud servers
msg3 = ESKCS0 ,U (dIM Dk , T P3 ). Then CSj0 sends CSj0 , (j 0 = 1, 2, · · · , ncs , L 6= CSj0 ).
j i 6: Assume SM sgj receives from L by each CSj0 in the P2P CS
msg3 = ESKCS0 ,U (dIM Dk , T P3 ) to Ui via open network at time T Sj∗ .
j i
channel. After receiving msg3 , Ui decrypts the mes- 7: for each cloud server CSj0 do
sage ESKCS0 ,U (dIM Dk , T P3 ) and gets the values of 8: if (|T Sj − T Sj∗ | < ∆T ) then
j i 9: Compute the Merkle tree root, M R∗ on the encrypted
dIM Dk and T P3 . Ui checks the timeliness of T P3 by transactions {EP ubCSj (T xs ) |s = 1, 2, · · · , nt }.
the condition |T P3 − T P3∗ | ≤ ∆T , where T P3∗ is the 10: if (M R∗ 6= M R) then
receiving timestamp of the message. If it holds, the 11: Terminate the consensus process.
message is treated as valid one. 12: else
13: Calculate block hash CBHash∗ on the received
This phase is summarized in Figure 7.
block Blocki as CBHash∗ = h(BV er|| P BHash||
M R∗ || T R|| OB|| P ubCSj || EP ubCSj (T x1 )||
G. PASSWORD AND BIOMETRIC UPDATE PHASE EP ubCSj (T x2 )|| · · · ||EP ubCSj (T xnt )).
BAKMP-IoMT provides the facility to update password and 14: if (CBHash∗ = CBHash) then
biometric information by any authorized user. Following 15: Verify the signature BSign = (rm , sm ) on BLKi
steps can be used by a legal user to update his/her pass- on the message msg = CBHash∗ with the help
word and biometric information regardless of time without of ECDSA signature verification algorithm.
16: if signature is valid then
involving T A. These steps must be rigorously executed to 17: Decrypt the encrypted random nonce using pre-
maintain the efficiency of the system. The required steps are computed private key rCSj as (rn∗j , T Sj00 ) =
given below: DrCSj [EP ubCSj (rnj , T Sj )] by applying the
• Step PBU1. First of all Ui needs to provide his/her ECC decryption algorithm.
o 18: if (T Sj00 = T Sj ) then
current identity IDU and password P WUoi to the
i 19: Send the block verification message con-
terminal of M DUi . Ui also has to imprint his/her taining verification status (V Status) and
o
current biometrics information BIOU i
at the sensor of decrypted random nonce as RM sgj =
the specified device. Then M DUi computes biometric {EP ubL (rn∗j , V Status)} to the leader L.
secret key σUo
= Rep(BIOU o
, τUi ) with the condition 20: end if
i i
21: end if
that the hamming distance between the actual biomet-
22: end if
rics BIOUi provided at the time of registration and 23: end if
o
currently furnished BIOU i
is less than or equal to the 24: end if
error tolerance threshold value t. 25: end for
• Step PBU2. M DUi again computes the required pa-
rameters such as x = β ⊕ h(IDUi || P WUoi ||σU o
i
),
o o 0
RP WUi = h(P WUi ||x), RIDT A = RIDT A ⊕
h(IDUi ||x|| σU o
i
), α = α0 ⊕ h(x||P WUoi || σU o
i
), δ o = checks the equality of EQo = EQ. If it holds, Ui
o o
h(α||RP WUi ||σUi ). After these computations, M DUi is validated as the genuine user and can proceed for
further computes EQo = h(IDUi || RIDT A ||δ o ), and password and biometric updates.
VOLUME 7, 2019 11
IM Dk P Sl Blockchain CSj , CSj0 Ui

Generate current timestamp T P1
Prepare msg1
= ESKIM Dk ,P Sl (dIM Dk , T P1 ).
msg1
−−−→
(via open channel)
Decrypt ESKIM Dk ,P Sl (dIM Dk , T P1 ).
Get dIM Dk and T P1 .
Check |T P1 − T P1∗ | ≤ ∆T .
If so, generate current timestamp T P2 .
Prepare msg2
= ESKP Sl ,CSj (dIM Dk , T P2 ).
msg2
−−−→
(via open channel)
Decrypt ESKP Sl ,CSj (dIM Dk , T P2 ).
Get dIM Dk and T P2 .
Check |T P2 − T P2∗ | ≤ ∆T . If so,
CSj prepares a block for addition into blockchain.
Block is added into blockchain when other miners
committed successfully (Algorithms 1 and 2).
CSj0 extracts dIM Dk from the concerned block.
CSj0 generate current timestamp T P3 .
Prepare msg3 = ESKCS0 ,U (dIM Dk , T P3 ).
j i
msg3
−−−→
(via open channel)
Decrypt ESKCS0 ,U (dIM Dk , T P3 ).
j i
Obtain dIM Dk and T P3 .

Check |T P3 − T P3∗ | ≤ ∆T .
If so, obtain dIM Dk securely.
FIGURE 7. Summary of blockchain based procedure for secure data exchange
Algorithm 2 Consensus for block verification and addition rics information . In such a scenario, BIOin will
in blockchain (Continued...) be considered as BIOio . Otherwise, M DUi com-
26: for each received RM sgj from the responders CSj0 do putes Gen(BIOin ) = (σin , τin ). M DUi then com-
27: L computes (rn0j , V Status) = DrL [EP ubL (rn∗j , putes RP WUni = h(P WUni ||x), other parameters such
V Status)]. as β n = x ⊕ h(IDUi || P WUni ||σU n
i
), RIDU n
i
=
28: if ((rn0j = rnj ) and (V Status = valid) and n n
RIDUi ⊕ h(P WUi || σUi ), RIDT A = RIDT A ⊕ n
n
(f lagCSj0 = 0)) then h(IDUi ||x|| σU i
), αn = α ⊕ h(x||P WUni || σU n
i
),
L sets V T Count = V T Count+1 and f lagCSj0 = n n n n
29: δ = h(α||RP WUi ||σUi ) and EQ = h(IDUi ||
0
1. RIDT A ||δ n ). M DUi then replaces RIDU i
, RIDT0 A ,
0
30: end if α , EQ, β, and τUi with RIDUi , RIDT A , αn , EQn ,
n n
31: end for β n , and τUni , respectively. Finally, M DUi stores the in-
n
32: if (V T Count is more than 50% of the votes) then formation {RIDU i
, RIDTn A , αn , EQn , β n , τUni , h(·),
33: Transaction enters to the next round. Gen(·), Rep(·), t} in its memory.
34: if (V T Count less than the threshold value, that is,
80% of the votes) then H. DYNAMIC NODES ADDITION PHASE
35: Continue from Step 26. Following steps can be used by the BAKMP-IoMT to add
36: else a new device i.e., IM D in the network any time.
37: Send the commit response to all other followers
peer nodes CSj0 . 1) Dynamic IMD addition
Add block BLKi to the blockchain and adjourn The addition of IM D can be done using the following steps.
the consensus process. • Step DAI1. A unique identity for new IM D,
38: end if IDIM Dν is selected by the T A and it also com-
39: end if putes the corresponding pseudo-identity RIDIM Dν =
h(IDIM Dν ||N ) where the T A’s secret key is N . Next
the T A determinesP a unique symmetric bivariate poly-
t
• Step PBU3. Ui inputs new password P Win and im- nomial χ(x, y) = m,n=0 am,n xm y n ∈ GF (p)[x, y]
prints new biometric information BIOin according of degree t over a finite field (Galois field) GF (p)
to his/her liking at the sensor of the specified de- (= Zp ), where the co-efficients ai,j ’s are chosen from
vice. Old biometrics information BIOio can also be GF (p) and Zp = {0, 1, 2, · · · , p − 1} with p being a
used if Ui does not wish to modify his/her biomet- satisfactorily large prime and t is enough larger than
12 VOLUME 7, 2019
the total count of IMDs to be deployed. For instance, practice it is preferable to use the cloud servers (CSj ) for
a bivariate polynomial χ(x, y) = x4 + 3x3 + 2x2 y 2 + block consensus via voting and blockchain implementation.
3y 3 + y 4 over GF (5) is symmetric as χ(y, x) = y 4 + Though the RPCA mechanism is not that heavy, but still
3y 3 + 2y 2 x2 + 3x3 + x4 = χ(x, y). we preferred to execute block consensus via voting and
• Step DAI2. The T APcomputes a polynomial share blockchain implementation over the peer nodes (CSj ) in the
t m n
χ(RIDIM Dν , y) = m,n=0 [am,n (RIDIM Dν ) ]y , P2P cloud servers network only in order to reduce the com-
which is clearly a univariate polynomial of the same putational burden on IM Dk , P Sl and M Di . As discussed
degree t. Then T A stores the credentials {RIDIM Dν , earlier, we consider a private blockchain in BAKMP-IoMT,
χ(RIDIM Dν , y)} in IM Dν ’s memory before their which provides more security, and at the same time it has
deployment. several restrictions and limited entities. As far as the annual
fee is concerned, in most of the countries the healthcare
2) Dynamic personal server addition facilities (including healthcare infrastructure) are supported
The addition of new personal server can be done using the by the government organisations. Therefore, payment of
specified steps. annual fee will not be an issue for healthcare infrastructure
• Step DAP1. The T A chooses a unique identity IDP Sη users in the proposed scheme.
for new personal server P Sη and determines corre-
sponding pseudo-identity RIDP Sη = h(IDP Sη ||N ) V. SECURITY ANALYSIS OF BAKMP-IOMT
utilizing the T A’s secret key N and temporal creden- This section contains the “security analysis of BAKMP-
tial T CP Sη = h(IDP Sη ||IDT A ||RT SP Sη ||N ) where IoMT” in Propositions 1–8, which prove the resilience of
the registration timestamp of P Sη is RT SP Sη . T A BAKMP-IoMT against the below mentioned attacks.
next computes the polynomial share χ(RIDP Sη , y) =
Pt Proposition 1. BAKMP-IoMT can resist “replay attack”.
m,n=0 [am,n (RIDP Sη )m ]y n for each P Sη , where
Pt m n
χ(x, y) = m,n=0 am,n x y ∈ GF (p)[x, y] is the Proof. In BAKMP-IoMT, we have used different current
same symmetric bivariate polynomial of degree t that timestamps values in the transmitted messages. Each ex-
was previously chosen in Section IV-A1. changed message of BAKMP-IoMT, have a maximum trans-
• Step DAP2. The T A stores the information {RIDP Sη , mission delay ∆T component (a small value). Moreover,
T CP Sη , RIDT A , χ(RIDP Sη , y))} in P Sη ’s database replaying the old transmitted messages does not provide
before its deployment. any profit to the adversary A which were required for
“authentication and key management procedure” among
3) Dynamic cloud server (miners) addition IM Dk , P Sl , CSj and Ui within ∆T . Therefore, BAKMP-
The addition of new cloud server can be done using the IoMT is capable to resist replay attack.
following steps.
• Step DAC1. The T A first chooses a unique identity Proposition 2. BAKMP-IoMT is able to protect against the
IDCSnew
j
for cloud server CSj new and computes cor- “man-in-the-middle attack (MITM)”.
new new
responding pseudo-identity RIDCS = h(IDCS ||N )
j j Proof. Let an adversary A eavesdrops an authentication
utilizing the T A’s secret key N .
request message {M1 , M2 , T S1 } which was exchanged
• Step DAC2. After that T A stores the information
new between Ui and CSj0 , and after that A tries to update
{RIDCS , RIDT A } in CSjnew ’s database before its
j this message so that it resembles like the original au-
deployment. T A then announce the addition of new
thentication message, as {M1a , M2a , T S1a } with the help of
cloud server to the other parties of the network through
parameters such as M1a = rU a
⊕ h(RIDT A ||RIDUi ), and
some secure channel. i
M2 = h(rUi ||RIDUi ||RIDT A ||T S1a ). For the launching of
a
a
Remark 1. In BAKMP-IoMT, various involved com- M IT M , A can start the generation of random nonce rU i
a
municating entities include implantable medical devices and current timestamp T S1 . However, in the absence of
(IM Dk ), personal server (P Sl ), users having mobile de- knowledge of “long term secret” RIDT A , RIDUi and N
vices (Ui /M Di ) and cloud servers (CSj ). Among all these the secret key of T A, A can not regenerate another valid
entities, IM Dk , P Sl and M Di are resource constrained authentication request message {M1a , M2a , T S1a }. Similarly,
end devices which have less computation, communication we can also elucidate that other messages can not be com-
and storage capabilities as compared to the T A and cloud puted again by A which are utilized in the “authentication
servers CSj . Moreover, we need these devices for collection and key management” phase without the “long-term secrets”
and local processing of essential healthcare related data. utilized by Ui and CSj0 or the other entities of the network.
Apart from it, CSj are resource rich nodes which have Hence, BAKMP-IoMT is secured against the man-in-the-
high computation, communication and storage capabilities. middle attack.
Therefore, it is not typically desirable to use IM Dk , P Sl
and M Di for the block creation and consensus via voting Proposition 3. BAKMP-IoMT is secured against various
tasks because of their resource constrained factor. Hence, in “impersonation attacks”.
VOLUME 7, 2019 13
Proof. Let an adversary A tries to impersonate as an is not able to calculate the “session key” on behalf of a gen-
valid communicating entity of the network by creat- uine communicating entity as the “session key” is created
ing an authentication request message on behalf of that using the credentials that are only known to that particular
entity say Ui . After obtaining Ui ’s authentication re- entity i.e., IM Dk , P Sl CSj and Ui . The “session key”
quest M sg1 = {M1 , M2 , T S1 } which was sent to CSj0 computed by a legitimate cloud server CSj0 is SKCSj0 ,Ui =
where M1 = rUi ⊕ h(RIDT A ||RIDUi ) and M2 = h(rUi ||RIDUi ||T S1 ||T S2 || h(rCSj0 || RIDCSj0 )||RIDT A )
h(rUi ||RIDUi ||RIDT A ||T S1 ). Here it is important to no- which consists of various short and long term secret values
tice that M sg1 uses M1 and M2 which are generated i.e., random nonces, timestamps, secret keys and identities,
through “long term secrets” i.e., RIDUi , RIDT A and N , as elaborated earlier. The privileged-insider user of the T A
and also through the “short term secrets” for example, does not have the knowledge of this information. Thus A is
random nonce rUi . A is not capable to generate a valid not able the compute the “session key” on the behalf of a
“authentication request message” representing the legitimate legitimate communicating entity. Moreover, he/she can not
user Ui without having the knowledge of these secret val- impersonate as the “legitimate communicating entity i.e.,
ues. Therefore, BAKMP-IoMT is secured against the “user CSj0 ” as explained in Proposition 3. Therefore, BAKMP-
impersonation attack”. By using the same methodology, we IoMT is able to protect the “privileged-insider attack”.
can prove that BAKMP-IoMT is also secured against other
types of impersonation attacks i.e., “cloud server”, “per-
sonal server” and “implantable medical device”, because role trustedauthority(U, TA, CS: agent, H: hash_func,
Snd, Rcv: channel(dy))
the creation of other messages also utilize both “long term” played_by TA
and “short term” secrets. Hence, BAKMP-IoMT is resilient def=
against the various impersonations attacks. local State: nat,
IDui, IDta, IDcsj, N, RTSui, RIDta, RIDcsj : text,
RIDui, Alpha, CSj,
Proposition 4. BAKMP-IoMT protects “Ephemeral Secret SKuta, SKcsta: symmetric_key
Leakage (ESL) attack”. const sp1, sp2, sp3: protocol_id
% Initialize state, State to 0
init State := 0
Proof. In BAKMP-IoMT, “session key” is calculated by a transition
legitimate user Ui and the cloud server CSj0 , during the “au- %%% User registration phase
thentication and key management process” as SKCSj0 ,Ui = %%% Receive registration request from user (U) securely
1. State = 0 /\ Rcv({IDui}_SKuta) =|>
h(rUi ||RIDUi ||T S1 ||T S2 || h(rCSj0 ||RIDCSj0 )||RIDT A ). State’ := 1 /\ RTSui’ := new()
In the creation of the session key, the pseudo identities /\ RIDui’ := H(IDui.N) /\ RIDta’ := H(IDta.N)
RIDUi , RIDCSj0 of user Ui and cloud server CSj0 are /\ Alpha’ := H(RIDui’.RIDta’.RTSui’)
%%% Send registration response to U securely
used. It also consists of the different random nonce values /\ Snd({RIDui’.Alpha’.RIDta’}_SKuta)
rUi , rCSj0 of user and cloud server. It is important to /\ secret({IDui}, sp1, {U,TA})
notice that “session key” is the amalgamation of both the /\ secret({IDta, RTSui’,N}, sp2, TA)
session-temporary (ephemeral) information also known as %%% Cloud server registration phase
“short term secrets” (various timestamp and random nonce %%% Send registration request to cloud server (CS) securely
values) along with “long-term secrets” (various identities /\ RIDcsj’ := H(IDcsj.N)
/\ Snd({RIDcsj’.RIDta’}_SKcsta)
and secret keys). Therefore, session key can only be revealed /\ secret({IDcsj}, sp3, {CS,TA})
in a situation if A compromises both the “short-term” and end role
“long-term” secret values. Furthermore, as various random
FIGURE 8. HLPSL specification for the role of T A
nonce and timestamps values are utilized in calculation of
the session keys among various entities i.e., Ui and CSj0 ,
IM Dk and P Sl , and P Sl and CSj in all different sessions, Proposition 6. BAKMP-IoMT preserves anonymity and
even if a session key is revealed for a specific session. It untraceability properties.
will not cause the revealing (i.e., illegal computation) of
Proof. Suppose an adversary A seizes the messages M SG1
session keys of other sessions because of coalescence of
= M1 , M2 , T S1 , M SG2 = M3 , M4 , T S2 and M SG3
short and long term secret values. Thus, BAKMP-IoMT is
= M5 , T S3 during the “authentication and key management
capable to protect session-temporary information attack and
phase” between Ui and CSj0 . These messages are computed
it also preserves the “perfect forward secrecy” goal. Hence,
by using the various random nonce values and current times-
BAKMP-IoMT is secured against “ESL attack”.
tamps values which help to generate dynamic and unique
messages in distinct sessions. Apart from that any identity
Proposition 5. BAKMP-IoMT is capable to protect
information is not transmitted in the “plaintext format”. Sim-
“privileged-insider attack”.
ilar method is also followed for other exchanged messages
Proof. The privileged-insider user of the trusted authority among other entities i.e., IM Dk and P Sl , and P Sl and
i.e., attacker A knows the registration information of the CSj . This mechanism helped us to achieve both “anonymity
various entries i.e., IM Dk , P Sl CSj and Ui . Still, he/she and untraceability” properties in BAKMP-IoMT.
14 VOLUME 7, 2019
role user(U, TA, CS: agent, H: hash_func, between a personal server P Sl and a non-compromised IMD
Snd, Rcv: channel(dy)) IM Dk when nc IMDs are already compromised (under the
played_by U
def= influence of attack). Let’s assume this probability as Pe (nc ).
local State: nat, If Pe (nc ) = 0, an “authentication and key management”
IDui, N, IDta, RTSui, TS1, Rui, M1, M2, M5,
Rcsj, IDcsj, TS2, TS3, SKucs :text,
scheme is treated as the “unconditionally secure against
SKuta: symmetric_key IMD physical capture attack”. From a physically stolen
const sp1, sp2, sp3, u_cs_ts1, u_cs_rui, cs_u_rcsj, IMD IM Dk , attacker A will have deduced information
cs_u_ts2, u_cs_ts3: protocol_id
% Initialize state, State to 0
i.e., {RIDIM Dk , χ(RIDIM Dk , y)} along with the secret
init State := 0 pairwise session key SKP Sl ,IM Dk = h(ω||T IP1 ) shared
transition between IM Dk and P Sl from its memory, where ω =
%%% User registration phase
1. State = 0 /\ Rcv(start) =|>
χ(RIDP Sl , RIDIM Dk ). However, it is worthy to notice
%%% Send registration request to the TA securely that all RIDIM Dk and χ(RIDIM Dk , y) are different for
State’ := 2 /\ Snd({IDui}_SKuta) different IMDs. Therefore, the physical stolen of IM Dk by
/\ secret({IDui}, sp1, {U,TA})
%%% Receive registration response from the TA securely A can only help him/her in the obtaining of secret session
2. State = 2 /\ Rcv({H(IDui.N).H(H(IDui.N).H(IDta.N). key between that IM Dk and P Sl not the other session
RTSui’).H(IDta.N)}_SKuta) =|> keys. Thus all other secret keys between the P Sl and other
State’ := 4 /\ secret({IDta, RTSui’,N}, sp2, TA)
non-compromised IMDs are still unrevealed. Hence, the
%%% User login phase compromising of an IMD will not cause the compromising
/\ TS1’ := new() /\ Rui’ := new() of the entire communication, and the secure communications
/\ M1’ := xor(Rui’, H(H(IDta.N).H(IDui.N)))
/\ M2’ := H(Rui’.H(IDui.N).H(IDta.N).TS1’) among personal server and other non-compromised IMDs
%%% Send login request to CS via public channel can be still achieved. Thus BAKMP-IoMT is uncondition-
/\ Snd(M1’.M2’.TS1’)
%%% U has freshly generated the values TS1 and Rui for the CS
ally secure against the IMD physical capture attack.
/\ witness (U, CS, u_cs_ts1, TS1’)
/\ witness (U, CS, u_cs_rui, Rui’)
Proposition 8. BAKMP-IoMT is resilient against the data
modification attack at the cloud server.
%% Authentication and key agreement phase
%% Receive authentication request from the CS via public channel Proof. Cloud server (miner node) CSj receives data from
3. State = 4 /\ Rcv( xor(H(Rcsj’.H(IDcsj.N)), H(H(IDui.N).H(IDta.N))). the concerned personal server P Sl and prepares a block to
H(H(Rui’.H(IDui.N).TS1’.TS2’.H(Rcsj’.H(IDcsj.N)).
H(IDta.N)).TS2’). add this block into the existing blockchain. For that purpose,
TS2’) =|> all miner nodes call the steps of Algorithm 1 and Algorithm
State’ := 6 /\ TS3’ := new() 2. After the completion of all steps of these algorithms, a
/\ SKucs’ := H(Rui’.H(IDui.N).TS1’.TS2’.
H(Rcsj’.H(IDcsj.N)).H(IDta.N)) block will be added into the blockchain. Since, blockchain is
/\ M5’ := H(SKucs’.TS3’) a tamper proof technology and the attacker A does not have
%%% Send authentication reply to CS via public channel ability to update the required fraction of blocks. Therefore,
/\ Snd(M5’.TS3’)
%%% U’s acceptance of values TS2 and Rcsj generated for U by CS A can not modify the data of a block. Hence, BAKMP-
/\ request (CS, U, cs_u_ts2, TS2’) IoMT is resilient against the data modification attack.
/\ request (CS, U, cs_u_rcsj, Rcsj’)
end role
FIGURE 9. HLPSL specification for the role of a user Ui

VI. FORMAL SECURITY VERIFICATION USING AVISPA
TOOL
In this section, we do simulation of the proposed BAKMP-
IoMT for the “formal security verification using the
Proposition 7. BAKMP-IoMT is resilient against “im- widely accepted automated software validation tool, called
plantable medical device (IMD)” physical capture attack. AVISPA” [59].
Proof. Each IMD contains the credentials {RIDIM Dk , A tested security protocol is first implemented under
χ(RIDIM Dk , y)} that are utilized for the “authentication the High Level Protocol Specification Language (HLPSL)
and key establishment” related work with different commu- [60]. HLPSL is a “role-oriented language” containing the
nicating entities. To safeguard against IMD device physical following types of roles:
capture attack is an crucial requirement from the security • Basic roles: They denote “different participating enti-
point of view [57], [58]. Let say nc IMD devices are ties in the protocol”.
physically trapped by an adversary A. We do evaluation of • Composition roles: They present “different scenarios
“IMD physical capture attack” as the fraction of total secure involving basic roles”.
communications which are compromised from the capturing An intruder always takes part in the protocol as “one of the
(physical stolen) of nc IMDs not including the commu- basic legitimate roles and is always represented by i”. The
nication in which the “compromised IMD” are clearly “HLPSL specification of the protocol” is converted into the
extended. For instance, one can calculate the probability “Intermediate Format (IF)” using the HLPSL2IF translator.
of A’s expertise to decrypt the “secure communication” The IF is then given as input to one of the four backends
VOLUME 7, 2019 15
role cloudserver(U, TA, CS: agent, H: hash_func, role session(U, TA, CS: agent, H: hash_func)
Snd, Rcv: channel(dy)) def=
played_by CS local SD1, RV1, SD2, RV2, SD3, RV3: channel (dy)
def=
composition
local State: nat,
trustedauthority(U, TA, CS, H, SD1, RV1)
IDcsj, N, IDta, IDui, RTSui, Rui, TS1,
TS2, Rcsj, M3, SKcsu, M4, TS3: text, /\ user(U, TA, CS, H, SD2, RV2)
SKcsta: symmetric_key /\ cloudserver(U, TA, CS, H, SD3, RV3)
const sp1, sp2, sp3, u_cs_ts1, u_cs_rui, cs_u_rcsj, end role
cs_u_ts2, u_cs_ts3: protocol_id
% Initialize state, State to 0 role environment()
init State := 0 def=
transition const u, ta, cs: agent,
%%% Cloud server registration phase h: hash_func,
%%% Receive registration request to the TA securely ts1, ts2, ts3 : text,
1. State = 0 /\ Rcv({H(IDcsj.N).H(IDta.N)}_SKcsta) =|> sp1, sp2, sp3, u_cs_ts1, u_cs_rui,
State’ := 3 /\ secret({IDui}, sp1, {U,TA})
cs_u_rcsj, cs_u_ts2, u_cs_ts3: protocol_id
/\ secret({IDta, RTSui’,N}, sp2, TA)
intruder_knowledge = {u, ta, cs, ts1, ts2, ts3}
/\ secret({IDcsj}, sp3, {CS,TA})
composition
%%% User login phase session(u, ta, cs, h)
%%% Receive login request message from U via public channel /\ session(u, ta, cs, h)
2. State = 3 /\ Rcv(xor(Rui’, H(H(IDta.N).H(IDui.N))). /\ session(i, ta, cs, h)
H(Rui’.H(IDui.N).H(IDta.N).TS1’).TS1’) =|> /\ session(u, ta, i, h)
end role
%%% Authentication and key agreement phase
State’ := 5 /\ TS2’ := new() /\ Rcsj’ := new() goal
/\ M3’ := xor(H(Rcsj’.H(IDcsj.N)), H(H(IDui.N).H(IDta.N))) %%% Confidentiality (privacy)
/\ SKcsu’ := H(Rui’.H(IDui.N).TS1’.TS2’. secrecy_of sp1, sp2, sp3
H(Rcsj’.H(IDcsj.N)).H(IDta.N))
%%% Authentication
/\ M4’ := H(SKcsu’.TS2’)
authentication_on u_cs_ts1, u_cs_rui
%%% Send authentication request to U via public channel
/\ Snd(M3’.M4’.TS2’) authentication_on cs_u_rcsj, cs_u_ts2
%%% CS has freshly generated the values TS2 and Rcsj for U authentication_on u_cs_ts3
/\ witness (CS, U, cs_u_ts2, TS2’) end goal
/\ witness (CS, U, cs_u_rcsj, Rcsj’) environment()
%%% Receive authentication reply from U via public channel
3. State = 5 /\ Rcv(H(Rui’.H(IDui.N).TS1’.TS2’.H(Rcsj’. FIGURE 11. HLPSL specification for the roles of session, goal and
H(IDcsj.N)).H(IDta.N)).TS3’) =|> environment
% CS’s acceptance of values TS1, Rui and TS3 generated for CS by U
State’ := 7 /\ request (U, CS, u_cs_ts1, TS1’)
/\ request (U, CS, u_cs_rui, Rui’)
/\ request (U, CS, u_cs_ts3, TS3’) • BACKEND: It is the “name of the back-end that is
end role used for the analysis, that is, one of OFMC, CL-AtSe,
FIGURE 10. HLPSL specification for the role of a cloud server CSj
SATMC and TA4SP”.
• Final section includes the “trace of a possible vulner-
ability to the target protocol, if any, along with some
available in AVISPA to its “Output Format (OF)”. The four useful statistics and relevant comments”.
back-ends of AVISPA are: a) “On-the-fly Model-Checker We have implemented the registration, login and authen-
(OFMC)”, b) “Constraint Logic based Attack Searcher (CL- tication phases of our proposed BAKMP-IoMT in HLPSL
AtSe)”, c) “SAT-based Model-Checker (SATMC)” and d) specification. The basic roles for the T A, a user Ui and
“Tree Automata based on Automatic Approximations for a cloud server CSj are shown in figures 8, 9 and 10,
the Analysis of Security Protocols (TA4SP)”. More detailed respectively. The mandatory roles (session and goal &
discussions on these back-ends and HLPSL can be found in environment) are also implemented as composite roles in
[59], [60]. Figure 11.
The OF contains following sections [60]: In the simulation under the AVISPA backends, three
• SUMMARY: It tells “whether the tested protocol is verifications, namely: a) “executability checking on non-
safe, unsafe, or whether the analysis is inconclusive”. trivial HLPSL specifications”, b) “replay attack checking”,
• DETAILS: It states an explanation of “why the tested and c) “Dolev-Yao threat model (DY model) [42] checking”.
protocol is concluded as safe, or under what conditions The “executability check” is essential to assure that “the
the test application or protocol is exploitable using an protocol will reach to a state where a possible attack can
attack, or why the analysis is inconclusive”. happen, during the run of the protocol”. From figures 8, 9
• PROTOCOL: It denotes the “HLPSL specification of and 10, it is clear that “BAKMP-IoMT has been properly
the target protocol in the IF”. translated to HLPSL specification and it meets the design
• GOAL: It presents the “goal of the analysis which is goals by ensuring the executability”. For the “replay attack
being performed by AVISPA using HLPSL specifica- checking” on BAKMP-IoMT, both OFMC and CL-AtSe
tion”. check “if the legitimate agents can execute the specified
16 VOLUME 7, 2019
SUMMARY TABLE 3. Comparison of security and functionality features

SAFE
DETAILS
BOUNDED_NUMBER_OF_SESSIONS Feature Merabet Jang He- BAKMP-IoMT
et al. [38] et al. [36] Zeadally [37]
PROTOCOL SF F1 X X X X
/home/akdas/Desktop/span SF F2 X × X X
/testsuite/results/auth.if SF F3 X X X X
SF F4 X X X X
GOAL SF F5 × X X X
as specified SF F6 X X X X
SF F7 X X X X
BACKEND SF F8 × X X X
OFMC SF F9 X X X X
SF F10 X N/A X X
STATISTICS SF F11 N/A N/A N/A X
SF F12 N/A N/A N/A X
TIME 766 ms SF F13 × × × X
parseTime 0 ms SF F14 × × × X
visitedNodes: 748 nodes SF F15 × N/A X X
depth: 9 plies SF F16 X X X X
SF F17 X × × X
FIGURE 12. Analysis of results of BAKMP-IoMT under OFMC backend
Note: SF F1 : “mutual authentication/access control”; SF F2 : “anonymity”;
SF F3 : “untraceability”; SF F4 : “session-key agreement”; SF F5 : “ses-
SUMMARY sion key security under CK adversary model”; SF F6 : “confidentiality”;
SAFE SF F7 : “integrity”; SF F8 : “strong replay attack”; SF F9 : “man-in-the-
middle attack”; SF F10 : “efficient login phase”; SF F11 : “password update
DETAILS phase”; SF F12 : “biometric update phase”; SF F13 : “dynamic controller
BOUNDED_NUMBER_OF_SESSIONS node addition”; SF F14 : “dynamic IM D addition”; SF F15 : “protection
TYPED_MODEL against stolen mobile device/programmer attack”; SF F16 : “protection
against impersonation attack”; SF F17 : “formal security verification using
PROTOCOL AVISPA tool”.
/home/akdas/Desktop/span ×: “a scheme is insecure against a particular attack or it does not support
/testsuite/results/auth.if a particular feature”; X: “a scheme is secure against a particular attack or
supports a particular feature”; N/A: “not applicable in a scheme”.
GOAL
As specified
TABLE 4. Rough estimated time for various cryptographic primitives [61]
BACKEND
CL−AtSe Notation Description Approx. computation
(time to compute) time (in seconds)
STATISTICS Th “One-way hash function” 0.00032
Analysed : 1437 states Tecm “ECC point multiplication” 0.0171
Reachable : 1434 states Teca “ECC point addition” 0.0044
Translation: 0.07 seconds Tsenc “Symmetric key encryption” 0.0056
Computation: 52.90 seconds Tsdec “Symmetric key decryption” 0.0056
Tme “Modular exponentiation” 0.0192
FIGURE 13. Analysis of results of BAKMP-IoMT under CL-AtSe backend Tf e “Fuzzy extractor function” 0.0171
protocol by performing a search of a passive intruder”. a “timestamp”, a “random number (nonce)” and a “hash
Finally, both OFMC and CL-AtSe backends verify “whether output (if SHA-256 hashing algorithm is applied)” need 160
any man-in-the-middle attack is possible by i for the DY bits, 32 bits, 160 bits and 256 bits, respectively. Then, the
model checking”. The simulation results reported in figures messages M sg1 = hM1 , M2 , T S1 i, M sg2 = hM3 , M4 ,
12 and 13 clearly exhibit that the proposed BAKMP-IoMT is T S2 i and M sg3 = hM5 , T S3 i require (256 + 256 + 32) =
safe against both ‘replay” and ‘man-in-the-middle” attacks. 544 bits, (256+256+32) = 544 bits, and (256+32) = 288
bits. As a result, the total communication cost in BAKMP-
VII. PERFORMANCE ANALYSIS IoMT due to three messages exchange needs 1376 bits.
In this section, we first evaluate the performance of the For computational cost analysis, assume that Th and Tf e
user registration, and user login and authentication phases denote the time needed to execute a “one-way hash function
of our proposed BAKMP-IoMT. Next, we compare the (say, SHA-256 hashing algorithm)” and a “fuzzy extractor
performance of BAKMP-IoMT with the relevant existing function (Gen(·)/Rep(·)”, respectively. During the login
authentication schemes for healthcare applications. and authentication phase, a user Ui needs the computational
During the login and authentication phase, the messages cost of 12Th + Tf e and a cloud server CSj requires
M sg1 = hM1 , M2 , T S1 i, M sg2 = hM3 , M4 , T S2 i and computational cost of 7Th . Thus, the total computational
M sg3 = hM5 , T S3 i are exchanged between a registered cost in BAKMP-IoMT becomes 19Th + Tf e . Since only
user Ui and a cloud server CSj . Assume that an “identity”, hash function and fuzzy extractor are applied, the proposed
VOLUME 7, 2019 17
scheme is very efficient. Finally, a comparative study on communication costs

During the user registration process, a user Ui ’s mobile among the proposed BAKMP-IoMT and other schemes is
0
device M DUi requires the credentials {RIDU i
, RIDT0 A , also provided in Table 6. It is observed that BAKMP-IoMT
0
α , EQ, β, τUi , t}. If we assume that “public reproduc- requires low communication cost as compared to that for
tion parameter τUi ” and “error-tolerance threshold value t” other schemes, such as the schemes of Jang et al. [36], He-
require 160 bits and 32 bits, respectively, the storage cost Zeadally [37] and Merabet et al. [38].
needed to store these credentials in BAKMP-IoMT becomes
(256 + 256 + 256 + 256 + 256 + 160 + 32) = 1472 bits. TABLE 7. Simulation parameters used BAKMP-IoMT
We now perform a detailed comparative study for the
“computation and communication costs” and “security and Parameter Remark
functionality features” among the proposed BAKMP-IoMT Platform used Windows 10 64-bit OS
and other related existing schemes, such as the schemes of Processor Intel (R) core (TM),
Jang et al. [36], He-Zeadally [37] and Merabet et al. [38]. i5-8250U, 1.60 GHz-1.80 GHz
Random-access memory
In Table 3, we have shown a comparative analysis on (RAM) size 8 GB
“security and functionality features” among BAKMP-IoMT Programming platform Eclipse IDE 2019-12 with Java
and other schemes against the considered features SF F1 – Number of IMDs 50 (scenario-1), 100 (scenario-2),
150 (scenario-3)
SF F17 . It is seen that the proposed BAKMP-IoMT provides Number of users 10 (scenario-1), 20 (scenario-2),
superior security and also more “functionality features” 40 (scenario-3)
while these are compared with the schemes of Jang et al. Number of miner nodes 4 in all scenarios
Size of a block 65,632 bits
[36], He-Zeadally [37] and Merabet et al. [38].
TABLE 5. Computation costs comparison
Scheme Computation cost (in milliseconds)

Jang et al. 25Tecm + 15Teca + 5Th ≈ 495.10 ms
He-Zeadally 6Tecm + 8Tsenc /Tsdec + 4Th ≈ 148.70 ms
Protocol-I 6Tecm + 6Th + Teca ≈ 108.92 ms

(Merabet et al.)
Protocol-II 4Tecm + 4Th ≈ 69.68 ms

(Merabet et al.)
BAKMP-IoMT 19Th + Tf e ≈ 23.18 ms
TABLE 6. Communication overheads comparison
Scheme No. of messages No. of bits

Jang et al. 8 5920
He-Zeadally 4 3232
Protocol-I 3 1472
(Merabet et al.)
Protocol-II 3 1472
(Merabet et al.)
BAKMP-IoMT 3 1376 FIGURE 14. Snippet of the main blockchain program
For comparative analysis on computational costs among

the proposed BAKMP-IoMT and other schemes during login VIII. PRACTICAL DEMONSTRATION
and authentication phases, we use various execution time for The pragmatic delineation of BAKMP-IoMT using the
cryptographic primitives as listed in Table 4 based on the strategies of blockchain was proceeded as follows [62].
existing experimental results in [61]. Using these results, Table 7 represents the details of different parameters used
a comparative study on computational costs among the during the experimentation. Three unique scenarios were
proposed BAKMP-IoMT and other schemes has been done considered in the experimentation. The experimentation was
in Table 5. It is also worth noticing that BAKMP-IoMT conducted on a platform having Windows 10 64-bit OS with
requires low computational cost as compared to that for Intel (R) core i5-8250U, 1.60 GHz-1.80 GHz processor.
other schemes, such as the schemes of Jang et al. [36], The size of random-access memory (RAM) size was 8 GB.
He-Zeadally [37] and Merabet et al. [38]. The programming platform was eclipse IDE 2019-12 with
18 VOLUME 7, 2019
Java language. The count of IMDs considered were 50 (in

scenario-1), 100 (in scenario-2) and 150 (in scenario-3).
The number of computed and committed blocks were 5
(in scenario-1), 10 (in scenario-2) and 15 (in scenario-3).
The count of users was taken as 10 (in scenario-1), 20
(in scenario-2) and 40 (in scenario-3) alongside four miner
nodes (i.e., cloud servers). The voting based mechanism is
used for the block verification and addition purpose. The
snippets of the “main blockchain program” and the “data
inside a block of blockchain” are given in Figures 14 and
15, respectively. Various fields utilized in a block of the
blockchain are as follows:
• Block Version (BVer): It denotes the version of a
block. The size of this field can be assumed as 32 bits.
• Hash of previous block (PBHash): It consists the hash
value of the previous block. The size of this field can
be considered as 256-bits (if “SHA256 hash algorithm”
is taken).
• Merkle Tree Root (MR): It is the Merkle tree root
on the encrypted transactions, whose size is 256-bits
as “SHA-256 hash algorithm” is used.
FIGURE 15. Snippet of data inside a block of blockchain • Timestamp: It is the value of timestamp for a partic-
ular block. The size of this field can be considered as
32-bits.
scenario-1
• Owner of Block (OB): It represents the identity of
block owner. The size of this field can be considered
computational cost (seconds)
7 scenario-2
scenario-3
6 as 160-bits.
5 • Owner public key: This field have the information of
4 “public key of the owner (miner) node”. The size of
3 this field is considered as 320-bits (since the “Elliptic
2 Curve Cryptography (ECC) algorithm” is considered).
1 • Encrypted transaction details: It comprises the infor-
0
mation about the “ongoing transactions”. For example,
which entity (communicating party) is sending “which
scenario information” and for “what reason”. The size of each
encrypted transaction is ECC-based ciphertext. Thus,
FIGURE 16. Obtained results of BAKMP-IoMT: impact on computational cost it requires (320 + 320) = 640 bits. If we consider
100 encrypted transactions, the payload of the block
becomes (100 × 640) = 64, 000 bits.
• Hash of current block: It contains the hash value of
scenario-1
250 the current block. The size of this field is 256-bits (if
transaction per second (TPS)
scenario-2
scenario-3 “SHA-256 algorithm” is taken).
200
• Block signature: It contains the “signature information
150 of a particular block”. The size of this field requires
320-bits (if ECC algorithm is applied).
100
The following results were obtained during the re-
50 enactments.
0
A. IMPACT ON COMPUTATIONAL COST
scenario
The effect on increasing number of IMDs and users was
computed as the computation cost (in ms) for all considered
FIGURE 17. Obtained results of BAKMP-IoMT: impact on transaction per
second (TPS)
scenarios. The various estimations of computation costs are
4.20, 5.01 and 6.21 seconds for scenario-1, scenario-2 and
scenario-3, respectively. The reported results are likewise
delineated in Figure 16. It is worthy to see that “computation
VOLUME 7, 2019 19
cost” increases with the number of IMDs and users from [5] S. Chatterjee, A. K. Das, and J. K. Sing, “A Secure User Anonymity-
scenario-1 to scenario-2 as well as from scenario-2 to Preserving Three-Factor Remote User Authentication Scheme for the Tele-
care Medicine Information Systems,” Adhoc & Sensor Wireless Networks,
scenario-3 as increase in number of IMDs and users causes vol. 21, no. 1, pp. 121–149, 2014.
“creation and addition” of more number of blocks in the [6] A. K. Das, “A Secure User Anonymity-Preserving Three-Factor Remote
blockchain. User Authentication Scheme for the Telecare Medicine Information Sys-
tems,” Journal of Medical Systems, vol. 39, no. 3, p. 30, 2015.
[7] V. Odelu, A. K. Das, M. Khurram Khan, K. R. Choo, and M. Jo, “Expres-
B. IMPACT ON TRANSACTION PER SECOND (TPS) sive CP-ABE Scheme for Mobile Devices in IoT Satisfying Constant-Size
Keys and Ciphertexts,” IEEE Access, vol. 5, pp. 3273–3283, 2017.
The impact on our proposed BAKMP-IoMT on transactions [8] S. Challa, M. Wazid, A. K. Das, N. Kumar, A. G. Reddy, E. Yoon,
per second (TPS) is also measured as per the considered and K. Yoo, “Secure Signature-Based Authenticated Key Establishment
Scheme for Future IoT Applications,” IEEE Access, vol. 5, pp. 3028–3043,
scenarios. The values of TPS are 119, 200 and 242 for 2017.
scenario-1, scenario-2 and scenario-3, respectively. The re- [9] V. Odelu, A. K. Das, and A. Goswami, “SEAP: Secure and efficient
ported results are additionally delineated in Figure 17. It authentication protocol for NFC applications using pseudonyms,” IEEE
Transactions on Consumer Electronics, vol. 62, no. 1, pp. 30–38, 2016.
is worthy to see that the value of TPS increases as the [10] A. K. Das, S. Kumari, V. Odelu, X. Li, F. Wu, and X. Huang, “Provably
blockchain grows with more number of IMDs and users. secure user authentication and key agreement scheme for wireless sensor
The reason is straightforward because it causes the creation networks,” Security and Communication Networks, vol. 9, no. 16, pp.
3670–3687, 2016.
and addition of more number of blocks in the blockchain.
[11] S. Malani, J. Srinivas, A. K. Das, K. Srinathan, and M. Jo, “Certificate-
Based Anonymous Device Access Control Scheme for IoT Environment,”
IX. CONCLUSION IEEE Internet of Things Journal, vol. 6, no. 6, pp. 9762–9773, 2019.
[12] M. Wazid, P. Bagga, A. K. Das, S. Shetty, J. J. P. C. Rodrigues, and Y. Park,
In this paper, we designed a novel blockchain enabled “AKM-IoV: Authenticated Key Management Protocol in Fog Computing-
authentication key agreement protocol for IoMT environ- Based Internet of Vehicles Deployment,” IEEE Internet of Things Journal,
vol. 6, no. 5, pp. 8804–8817, 2019.
ment (BAKMP-IoMT). BAKMP-IoMT provides secure key [13] N. Kumar, G. S. Aujla, A. K. Das, and M. Conti, “ECCAuth: A Secure
management among different communicating entities. The Authentication Protocol for Demand Response Management in a Smart
legitimate users can also access the healthcare data from Grid System,” IEEE Transactions on Industrial Informatics, vol. 15, no. 12,
pp. 6572–6582, 2019.
the cloud servers in a secure way. The entire healthcare [14] J. Srinivas, A. K. Das, N. Kumar, and J. J. P. C. Rodrigues,
data is stored in a blockchain maintained by the cloud “TCALAS: Temporal Credential-Based Anonymous Lightweight Authen-
servers. The formal security verification of BAKMP-IoMT tication Scheme for Internet of Drones Environment,” IEEE Transactions
on Vehicular Technology, vol. 68, no. 7, pp. 6903–6916, 2019.
is also performed to demonstrate its resilience against the [15] S. Mandal, B. Bera, A. K. Sutrala, A. K. Das, K. R. Choo, and Y. Park,
different types of possible attacks using the widely-accepted “Certificateless Signcryption-Based Three-Factor User Access Control
AVISPA tool and also through formal and informal security Scheme for IoT Environment,” IEEE Internet of Things Journal, 2020.
[16] S. Chatterjee, A. K. Das, and J. K. Sing, “A novel and efficient user access
analysis. BAKMP-IoMT is compared with other related
control scheme for wireless body area sensor networks,” Journal of King
existing schemes and it also performs better in terms of Saud University - Computer and Information Sciences, vol. 26, no. 2, pp.
security and functionality features, less communication and 181–201, 2014.
communication costs for authentication and key managment [17] M. Wazid, A. K. Das, V. Odelu, N. Kumar, and W. Susilo, “Secure
Remote User Authenticated Key Establishment Protocol for Smart Home
phase as compared to the other schemes. Furthermore, the Environment,” IEEE Transactions on Dependable and Secure Computing,
simulation of BAKMP-IoMT is conducted to demonstrate vol. 17, no. 2, pp. 391–406, 2020.
its impact on the performance parameters. [18] A. K. Das, M. Wazid, N. Kumar, A. V. Vasilakos, and J. J. P. C. Rodrigues,
“Biometrics-Based Privacy-Preserving User Authentication Scheme for
Cloud-Based Industrial Internet of Things Deployment,” IEEE Internet of
ACKNOWLEDGMENTS Things Journal, vol. 5, no. 6, pp. 4900–4913, 2018.
[19] J. Srinivas, A. K. Das, N. Kumar, and J. Rodrigues, “Cloud Centric
The authors thank the anonymous reviewers and the asso- Authentication for Wearable Healthcare Monitoring System,” IEEE Trans-
ciate editor for their valuable feedback on the paper which actions on Dependable and Secure Computing, 2018.
[20] M. Shuai, B. Liu, N. Yu, L. Xiong, and C. Wang, “Efficient and privacy-
helped us to improve its quality and presentation. preserving authentication scheme for wireless body area networks,” Jour-
nal of Information Security and Applications, vol. 52, p. 102499, 2020.
REFERENCES [21] A. K. Sutrala, P. Bagga, A. K. Das, N. Kumar, J. J. P. C. Rodrigues,
and P. Lorenz, “On the Design of Conditional Privacy Preserving Batch
[1] B. Bera, D. Chattaraj, and A. K. Das, “Designing secure blockchain-based Verification-Based Authentication Scheme for Internet of Vehicles De-
access control scheme in IoT-enabled Internet of Drones deployment,” ployment,” IEEE Transactions on Vehicular Technology, 2020, DOI:
Computer Communications, vol. 153, pp. 229 – 249, 2020. 10.1109/TVT.2020.2981934.
[2] M. Wazid, A. K. Das, V. Odelu, N. Kumar, M. Conti, and M. Jo, “Design [22] S. Challa, A. K. Das, V. Odelu, N. Kumar, S. Kumari, M. K. Khan, and
of Secure User Authenticated Key Management Protocol for Generic IoT A. V. Vasilakos, “An efficient ECC-based provably secure three-factor user
Networks,” IEEE Internet of Things Journal, vol. 5, no. 1, pp. 269–282, authentication and key agreement protocol for wireless healthcare sensor
2018. networks,” Computers & Electrical Engineering, vol. 69, pp. 534 – 554,
[3] A. K. Das, A. K. Sutrala, S. Kumari, V. Odelu, M. Wazid, and X. Li, 2018.
“An efficient multi-gateway-based three-factor user authentication and key [23] M. Wazid, A. K. Das, N. Kumar, V. Odelu, A. Goutham Reddy, K. Park,
agreement scheme in hierarchical wireless sensor networks,” Security and and Y. Park, “Design of Lightweight Authentication and Key Agreement
Communication Networks, vol. 9, no. 13, pp. 2070–2092, 2016. Protocol for Vehicular Ad Hoc Networks,” IEEE Access, vol. 5, pp.
[4] M. Wazid, A. K. Das, S. Kumari, X. Li, and F. Wu, “Design of an efficient 14 966–14 980, 2017.
and provably secure anonymity preserving three-factor user authentication [24] A. A. Monrat, O. Schelen, and K. Andersson, “A Survey of Blockchain
and key agreement scheme for TMIS,” Security and Communication From the Perspectives of Applications, Challenges, and Opportunities,”
Networks, vol. 9, no. 13, pp. 1983–2001, 2016. IEEE Access, vol. 7, pp. 117 134–117 151, 2019.
20 VOLUME 7, 2019
[25] Z. Zheng, S. Xie, H.-N. Dai, X. Chen, and H. Wang, “Blockchain chal- Biometrics and Fuzzy Extractor for Crowdsourcing Internet of Things,”
lenges and opportunities: A survey,” International Journal of Web and Grid IEEE Internet of Things Journal, vol. 5, no. 4, pp. 2884–2895, 2018.
Services, vol. 14, p. 352, 10 2018. [47] M. Wazid, A. K. Das, N. Kumar, and J. J. P. C. Rodrigues, “Secure Three-
[26] S. Aggarwal, R. Chaudhary, G. S. Aujla, N. Kumar, K.-K. R. Choo, and Factor User Authentication Scheme for Renewable-Energy-Based Smart
A. Y. Zomaya, “Blockchain for smart communities: Applications, chal- Grid Environment,” IEEE Transactions on Industrial Informatics, vol. 13,
lenges and opportunities,” Journal of Network and Computer Applications, no. 6, pp. 3144–3153, 2017.
vol. 144, pp. 13 – 48, 2019. [48] M. Wazid, A. K. Das, N. Kumar, M. Conti, and A. V. Vasilakos, “A Novel
[27] C. Lin, D. He, N. Kumar, X. Huang, P. Vijayakumar, and K. R. Choo, Authentication and Key Agreement Scheme for Implantable Medical De-
“HomeChain: A Blockchain-Based Secure Mutual Authentication System vices Deployment,” IEEE Journal of Biomedical and Health Informatics,
for Smart Homes,” IEEE Internet of Things Journal, vol. 7, no. 2, pp. 818– vol. 22, no. 4, pp. 1299–1309, 2018.
829, 2020. [49] S. Chatterjee, S. Roy, A. K. Das, S. Chattopadhyay, N. Kumar, and A. V.
[28] H. Zhang, J. Wang, and Y. Ding, “Blockchain-based decentralized and Vasilakos, “Secure Biometric-Based Authentication Scheme using Cheby-
secure keyless signature scheme for smart grid,” Energy, vol. 180, pp. 955 shev Chaotic Map for Multi-Server Environment,” IEEE Transactions on
– 967, 2019. Dependable and Secure Computing, vol. 15, no. 5, pp. 824–839, 2018.
[29] X. Wang, P. Zeng, N. Patterson, F. Jiang, and R. Doss, “An Improved [50] S. Challa, A. K. Das, S. Kumari, V. Odelu, F. Wu, and X. Li, “Provably
Authentication Scheme for Internet of Vehicles Based on Blockchain secure three-factor authentication and key agreement scheme for session
Technology,” IEEE Access, vol. 7, pp. 45 061–45 072, 2019. initiation protocol,” Security and Communication Networks, vol. 9, no. 18,
[30] C. Lin, D. He, X. Huang, X. Xie, and K.-K. R. Choo, “Blockchain-based pp. 5412–5431, 2016.
system for secure outsourcing of bilinear pairings,” Information Sciences, [51] D. Wang and P. Wang, “Understanding security failures of two-factor
2018, doi:https://doi.org/10.1016/j.ins.2018.12.043. authentication schemes for real-time applications in hierarchical wireless
[31] R. Chaudhary, A. Jindal, G. S. Aujla, S. Aggarwal, N. Kumar, and K.-K. R. sensor networks,” Ad Hoc Networks, vol. 20, pp. 1–15, 2014.
Choo, “BEST: Blockchain-based secure energy trading in SDN-enabled [52] C. Blundo, A. D. Santis, A. Herzberg, S. Kutten, U. Vaccaro, and
intelligent transportation system,” Computers & Security, vol. 85, pp. 288 M. Yung, “Perfectly-Secure Key Distribution for Dynamic Conferences,”
– 299, 2019. in Proceedings of 12th Annual International Cryptology Conference
[32] Q. Feng, D. He, S. Zeadally, and K. Liang, “BPAS: Blockchain-Assisted (CRYPTO’92), Lecture Notes in Computer Science, vol. 740, Santa Bar-
Privacy-Preserving Authentication System for Vehicular Ad Hoc Net- bara, California, USA, 1993, pp. 471–486.
works,” IEEE Transactions on Industrial Informatics, vol. 16, no. 6, pp. [53] A. K. Das and I. Sengupta, “An effective group-based key establishment
4146–4155, 2020. scheme for large-scale wireless sensor networks using bivariate polyno-
[33] A. Jindal, G. S. Aujla, and N. Kumar, “SURVIVOR: A blockchain based mials,” in 3rd IEEE International Conference on Communication Systems
edge-as-a-service framework for secure energy trading in SDN-enabled Software and Middleware (COMSWARE 2008), Bangalore, India, 2008,
vehicle-to-grid environment,” Computer Networks, vol. 153, pp. 36 – 48, pp. 9–16.
2019. [54] D. Johnson, A. Menezes, and S. Vanstone, “The Elliptic Curve Digital
[34] D. Mingxiao, M. Xiaofeng, Z. Zhe, W. Xiangwei, and C. Qijun, “A review Signature Algorithm (ECDSA),” International Journal of Information Se-
on consensus algorithm of blockchain,” in IEEE International Conference curity, vol. 1, no. 1, pp. 36–63, 2001.
on Systems, Man, and Cybernetics (SMC), Banff, Canada, 2017, pp. [55] H. Zhang, J. Wang, and Y. Ding, “Blockchain-based decentralized and
2567–2572. secure keyless signature scheme for smart grid,” Energy, vol. 180, pp. 955–
[35] H. Zhang, G. Kou, and Y. Peng, “Soft consensus cost models for group 967, 2019.
decision making and economic interpretations,” European Journal of Op- [56] X. Wang, P. Zeng, N. Patterson, F. Jiang, and R. Doss, “An Improved
erational Research, vol. 277, no. 3, pp. 964 – 980, 2019. Authentication Scheme for Internet of Vehicles Based on Blockchain
[36] C. S. Jang, D. G. Lee, J.-w. Han, and J. H. Park, “Hybrid Security Protocol Technology,” IEEE access, vol. 7, pp. 45 061–45 072, 2019.
for Wireless Body Area Networks,” Wireless Communications and Mobile [57] A. K. Das, P. Sharma, S. Chatterjee, and J. K. Sing, “A dynamic password-
Computing, vol. 11, no. 2, pp. 277–288, 2011. based user authentication scheme for hierarchical wireless sensor net-
[37] D. He and S. Zeadally, “Authentication protocol for an ambient assisted works,” Journal of Network and Computer Applications, vol. 35, no. 5,
living system,” IEEE Communications Magazine, vol. 53, no. 1, pp. 71– pp. 1646–1656, 2012.
77, 2015. [58] S. Kumari, A. K. Das, M. Wazid, X. Li, F. Wu, K. K. R. Choo, and M. K.
[38] F. Merabet, A. Cherif, M. Belkadi, O. Blazy, E. Conchon, and D. Sauveron, Khan, “On the design of a secure user authentication and key agreement
“New efficient M2C and M2M mutual authentication protocols for IoT- scheme for wireless sensor networks,” Concurrency and Computation:
based healthcare applications,” Peer-to-Peer Netw. Appl., vol. 13, no. 2, Practice and Experience, vol. 29, no. 23, pp. 1–24, 2017.
pp. 439–474, 2020. [59] AVISPA, “Automated Validation of Internet Security Protocols and Ap-
[39] B. Chase and E. MacBrough, “Analysis of the XRP Ledger Consensus plications,” 2019, http://www.avispa-project.org/. Accessed on October
Protocol,” CoRR, vol. abs/1802.07242, 2018. [Online]. Available: 2019.
http://arxiv.org/abs/1802.07242 [60] D. von Oheimb, “The high-level protocol specification language hlpsl
[40] C. Lin, D. He, X. Huang, M. K. Khan, and K.-K. R. Choo, “DCAP: A developed in the eu project avispa,” in Proceedings of 3rd APPSEM II
Secure and Efficient Decentralized Conditional Anonymous Payment Sys- (Applied Semantics II) Workshop (APPSEM’05), Frauenchiemsee, Ger-
tem Based on Blockchain,” IEEE Transactions on Information Forensics many, 2005, pp. 1–17.
and Security, vol. 15, pp. 2440–2452, 2020. [61] D. He, N. Kumar, J. H. Lee, and R. S. Sherratt, “Enhanced three-factor
[41] L. Ismail and H. Materwala, “A Review of Blockchain Architecture and security protocol for consumer USB mass storage devices,” IEEE Trans-
Consensus Protocols: Use Cases, Challenges, and Solutions,” Symmetry, actions on Consumer Electronics, vol. 60, no. 1, pp. 30–37, 2014.
vol. 11, no. 10, 2019. [62] M. Fan and X. Zhang, “Consortium blockchain based data aggregation and
[42] D. Dolev and A. Yao, “On the security of public key protocols,” IEEE regulation mechanism for smart grid,” IEEE Access, vol. 7, pp. 35 929–
Transactions on Information Theory, vol. 29, no. 2, pp. 198–208, 1983. 35 940, 2019.
[43] R. Canetti and H. Krawczyk, “Analysis of Key-Exchange Protocols and
Their Use for Building Secure Channels,” in Advances in Cryptology —
EUROCRYPT, B. Pfitzmann, Ed. Innsbruck (Tyrol), Austria: Springer
Berlin Heidelberg, 2001, pp. 453–474.
[44] R. Canetti and H. Krawczyk, “Universally composable notions of key
exchange and secure channels,” in Advances in Cryptology — EURO-
CRYPT, L. R. Knudsen, Ed. Amsterdam, The Netherlands: Springer
Berlin Heidelberg, 2002, pp. 337–351.
[45] T. S. Messerges, E. A. Dabbish, and R. H. Sloan, “Examining smart-card
security under the threat of power analysis attacks,” IEEE Transactions on
Computers, vol. 51, no. 5, pp. 541–552, 2002.
[46] S. Roy, S. Chatterjee, A. K. Das, S. Chattopadhyay, S. Kumari, and M. Jo,
“Chaotic Map-based Anonymous User Authentication Scheme with User
VOLUME 7, 2019 21
Neha Garg is currently pursuing Ph. D in Com- Ashok Kumar Das (M’17–SM’18) received a
puter Science and Engineering at Graphic Era Ph.D. degree in computer science and engineer-
deemed to be University Dehradun India. She has ing, an M.Tech. degree in computer science and
received B.Tech. degree in Computer Science and data processing, and an M.Sc. degree in mathe-
Engineering from Uttar Pradesh Technical Uni- matics from IIT Kharagpur, India. He is currently
versity Lucknow, U.P., India in 2005 and M.Tech. an Associate Professor with the Center for Secu-
degree in Computer Science and engineering in rity, Theory and Algorithmic Research, Interna-
2009. Her research interests include network se- tional Institute of Information Technology, Hy-
curity, Internet of Things and blockchain. She has derabad, India. His current research interests in-
published more than 25 research papers in her clude cryptography, network security, blockchain,
research areas. security in Internet of Things (IoT), Internet of Vehicles (IoV), Internet of
Drones (IoD), smart grids, smart city, cloud/fog computing and industrial
wireless sensor networks, and intrusion detection. He has authored over
220 papers in international journals and conferences in the above areas,
including over 190 reputed journal papers. Some of his research findings are
published in top cited journals, such as the IEEE Transactions on Informa-
tion Forensics and Security, IEEE Transactions on Dependable and Secure
Computing, IEEE Transactions on Smart Grid, IEEE Internet of Things
Journal, IEEE Transactions on Industrial Informatics, IEEE Transactions on
Vehicular Technology, IEEE Transactions on Consumer Electronics, IEEE
Journal of Biomedical and Health Informatics (formerly IEEE Transactions
on Information Technology in Biomedicine), IEEE Consumer Electron-
ics Magazine, IEEE Transactions on Cloud Computing, IEEE Access,
IEEE Communications Magazine, Future Generation Computer Systems,
Computers & Electrical Engineering, Computer Methods and Programs
in Biomedicine, Computer Standards & Interfaces, Computer Networks,
Expert Systems with Applications, and Journal of Network and Computer
Applications. He was a recipient of the Institute Silver Medal from IIT
Kharagpur. He is on the editorial board of KSII Transactions on Internet
and Information Systems, International Journal of Internet Technology
and Secured Transactions (Inderscience), and IET Communications, is a
Guest Editor for Computers & Electrical Engineering (Elsevier) for the
special issue on Big data and IoT in e-healthcare, ICT Express (Elsevier)
for the special issue on Blockchain Technologies and Applications for
5G Enabled IoT, and Wireless Communications and Mobile Computing
Mohammad Wazid (M’17–SM’20) received (Wiley/Hindawi) for the special issue on Attacks, Challenges, and New
M.Tech. degree in Computer Network Engineer- Designs in Security and Privacy for Smart Mobile Devices, and has served
ing from Graphic Era deemed to be University, as a Program Committee Member in many international conferences. He
Dehradun, India and Ph.D. degree in Computer also severed as one of the Technical Program Committee Chairs of the In-
Science and Engineering from the International ternational Congress on Blockchain and Applications (BLOCKCHAIN’19),
Institute of Information Technology, Hyderabad, Avila, Spain, June 2019.
India. He is currently working as an Associate
Professor in the Department of Computer Sci-
ence and Engineering, Graphic Era deemed to
be University, Dehradun, India. He is also the
head of “Cybersecurity and IoT research group” at Graphic Era deemed
to be University, Dehradun, India. Prior to this, he was working as an
assistant professor at the Department of Computer Science and Engi-
neering, Manipal Institute of Technology, MAHE, Manipal, India. He
was also a postdoctoral researcher at cyber security and networks lab,
Innopolis University, Innopolis, Russia. His current research interests
include information security, remote user authentication, Internet of things
(IoT), cloud/fog/edge computing and blockchain. He has published more Devesh Pratap Singh is currently the Professor
than 70 papers in international journals and conferences in the above and Head of Computer Science and Engineering
areas. Some of his research findings are published in top cited journals, department at Graphic Era deemed to be Univer-
such as the IEEE Transactions on Dependable and Secure Computing, sity Dehradun India. He has received M. Tech
IEEE Transactions on Smart Grid, IEEE Internet of Things Journal, IEEE degree in Computer Science and Engineering
Transactions on Industrial Informatics, IEEE Journal of Biomedical and from Uttarakhand Technical University Dehradun
Health Informatics (formerly IEEE Transactions on Information Technol- India in 2009. He has also received Ph.D. in
ogy in Biomedicine), IEEE Consumer Electronics Magazine, IEEE Access, 2015. His research interests include Information
Future Generation Computer Systems (Elsevier), Computers & Electrical Security, Wireless Sensor Networks, Internet of
Engineering (Elsevier), Computer Methods and Programs in Biomedicine Things and Soft Computing. He has published
(Elsevier), Security and Communication Networks (Wiley) and Journal more than 50 research papers in his area of expertise.
of Network and Computer Applications (Elsevier). He has also served
as a Program Committee Member in many international conferences. He
was a recipient of the University Gold Medal and the Young Scientist
Award by UCOST, Department of Science and Technology, Government
of Uttarakhand, India. He has received Dr. A. P. J. Abdul Kalam award for
his innovative research works. He has also received ICT Express (Elsevier)
Journal “Best Reviewer” award for the year of 2019.
22 VOLUME 7, 2019
Joel J. P. C. Rodrigues [S’01, M’06, SM’06,

F’20] is a professor at the Federal University of
Piauí, Brazil; and senior researcher at the Instituto
de Telecomunicações, Portugal. Prof. Rodrigues
is the leader of the Next Generation Networks
and Applications research group (CNPq), Direc-
tor for Conference Development - IEEE ComSoc
Board of Governors, IEEE Distinguished Lec-
turer, Technical Activities Committee Chair of
the IEEE ComSoc Latin America Region Board,
the President of the scientific council at ParkUrbis - Covilhã Science and
Technology Park, a Past-Chair of the IEEE ComSoc Technical Committee
on eHealth, a Past-chair of the IEEE ComSoc Technical Committee on
Communications Software, Steering Committee member of the IEEE Life
Sciences Technical Community and Publications co-Chair, and Member
Representative of the IEEE Communications Society on the IEEE Bio-
metrics Council. He is the editor-in-chief of the International Journal on
E-Health and Medical Communications and editorial board member of
several high-reputed journals. He has been general chair and TPC Chair of
many international conferences, including IEEE ICC, IEEE GLOBECOM,
IEEE HEALTHCOM, and IEEE LatinCom. He has authored or coauthored
over 850 papers in refereed international journals and conferences, 3
books, 2 patents, and 1 ITU-T Recommendation. He had been awarded
several Outstanding Leadership and Outstanding Service Awards by IEEE
Communications Society and several best papers awards. Prof. Rodrigues
is a member of the Internet Society, a senior member ACM and a fellow
of IEEE.
YoungHo Park (M’17) received his BS, MS,

and Ph.D degrees in electronic engineering,
Kyungpook National University, Daegu, Korea in
1989,1991, and 1995, respectively. He is currently
a professor at School of Electronics Engineering,
Kyungpook National University. In 1996-2008, he
was a professor at School of Electronics and Elec-
trical Engineering, Sangju National University,
Korea. In 2003-2004, he was a visiting scholar at
School of Electrical Engineering and Computer
Science, Oregon State University, USA. His research interests include
computer networks, multimedia, and information security.
VOLUME 7, 2019 23

Design of Secure Authenticated Key Management Protocol For Cloud Computing Environments

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Design of Secure Authenticated Key Management Protocol For Cloud Computing Environments

Uploaded by

Copyright:

Available Formats

This article has been accepted for publication in a future issue of this journal, but has not been

BAKMP-IoMT: Design of Blockchain

I. INTRODUCTION or even on a hybrid blockchain, it will raise privacy issues.

Scheme Cryptographic Techniques Drawbacks/Limitations

FIGURE 1. Network model of blockchain based IoMT communication environment

B. KEY MANAGEMENT 2) Key management between personal server and cloud

P Sl CSj h(x||P WUi || σUi ), δ = h(α||RP WUi ||σUi ) and EQ =

D. LOGIN PHASE • Step AU3. After receiving authentication reply

Ui /M DUi CSj0 and T P2 . Next, CSj examines the timeliness of T P2

IM Dk P Sl Blockchain CSj , CSj0 Ui

Obtain dIM Dk and T P3 .

FIGURE 9. HLPSL specification for the role of a user Ui

SUMMARY TABLE 3. Comparison of security and functionality features

scheme is very efficient. Finally, a comparative study on communication costs

TABLE 5. Computation costs comparison

Scheme Computation cost (in milliseconds)

He-Zeadally 6Tecm + 8Tsenc /Tsdec + 4Th ≈ 148.70 ms

Protocol-I 6Tecm + 6Th + Teca ≈ 108.92 ms

Protocol-II 4Tecm + 4Th ≈ 69.68 ms

BAKMP-IoMT 19Th + Tf e ≈ 23.18 ms

TABLE 6. Communication overheads comparison

Scheme No. of messages No. of bits

BAKMP-IoMT 3 1376 FIGURE 14. Snippet of the main blockchain program

For comparative analysis on computational costs among

Java language. The count of IMDs considered were 50 (in

Joel J. P. C. Rodrigues [S’01, M’06, SM’06,

YoungHo Park (M’17) received his BS, MS,

You might also like