BAKMP-IoMT: Design of Blockchain Enabled Authenticated Key Management Protocol for Internet of Medical Things Deployment

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.


I. INTRODUCTION
Internet of Medical Things (IoMT) is an assortment of health care systems (medical devices, software applications and The associate editor coordinating the review of this manuscript and approving it for publication was Naveen Chilamkurti . services etc.) to provide secure transmission of health related data between smart devices which help the remotely located doctors, care-providers, medical test centers to store and exchange health data electronically. It further provides real time medical services and assistance through Internet enabled smart devices like smart phones, smart medical wearable and implanted devices, electronic medical reports (EMR) etc. Other benefits of IoMT includes reduced health care costs, provides timely medical responses, fast decision making and improved quality of medical treatment. Presently, billions of devices are connected to Internet of Things (IoT) for various verticals of applications including the healthcare. With this exponential growth, user's privacy and security becomes most challenging issues in IoT (especially in IoMT) and requires essential consideration. Several potentials for security and privacy breaches that might occur in the healthcare systems are unauthorised access to enormous patients sensitive data (i.e., personal and medical records) that helps in making life critical decisions. Other malicious activities are modification of health data, hijacking of medical devices, gaining access to hospitals networks and exploitation of exchanged and stored information are performed to threat the lives of the patients. This necessitates to explore optimized solutions to deal with the threats and attacks on IoMT. Among several security mechanisms blockchain has the potentials to conquer the impediments of conventional ways to deal with the security and user privacy and is considered to be the backbone of future IoT (i.e., IoMT) applications with various benefits like enhanced security, reduced cost, true traceability, improved speed and efficient mechanism etc. Therefore, integrating Blockchain with IoMT can provide resilience to several attacks related to ''user authentication problem & key management'' problem such as ''replay'', ''man-in-themiddle'', ''impersonation'', ''password guessing'', ''illegal session key computation'', ''health data disclosure'', ''denial of service (DoS)'', ''privileged insiders'', etc., and in turn provides better healthcare services in a secured and real time environment.

A. MOTIVATION
As discussed earlier IoMT communication environment is vulnerable to various types of attacks. Therefore, we need some strong mechanism to secure the communication occur in an IoMT environment. For such purpose, the mechanism of blockchain will be helpful as it is decentralized and temper-proof can resist different types of attacks. Hence, a secure, blockchain-enabled authenticated key management protocol for IoMT is proposed. Moreover, in the designing of the proposed scheme, we consider a private blockchain. This is primarily because the healthcare data are typically strictly confidential and private. Therefore, if we put the confidential and private health related information on a public or even on a hybrid blockchain, it will raise privacy issues. It is then recommended to consider a private blockchain in such an environment.

B. CONTRIBUTIONS OF PROPOSED WORK
The contributions of this paper are manyfold: • We propose a novel blockchain-based authentication and key management scheme for IoMT environment, called BAKMP-IoMT. Moreover, the private blockchain is considered in the designing of BAKMP-IoMT.
In BAKMP-IoMT, we only incorporate efficient one-way cryptographic hash function and bitwise XOR operations.
• The comparison of BAKMP-IoMT with relevant existing schemes is conducted, which identifies that the proposed BAKMP-IoMT furnishes better security and functionality features, and low communication and computational costs as compared to those schemes.
• Finally, the simulation of BAKMP-IoMT is conducted to demonstrate its impact on the performance parameters.

C. PAPER STRUCTURE
The discussion on the associated existing schemes in healthcare applications is given in Section II. The system models (network and threat) are discussed in Section III. Various phases associated with the proposed ''blockchain based authentication and key management scheme for Internet of Medical Things (BAKMP-IoMT)'' have been discussed in Section IV. The security analysis of BAKMP-IoMT is carried out in Section V. To make further security analysis strong, the detailed formal security verification using AVISPA tool has been provided in Section VI. The comparative performance analysis of BAKMP-IoMT with relevant existing authentication schemes is also provided in Section VII. Moreover, the practical demonstration of BAKMP-IoMT using the strategies of blockchain is given in Section VIII. Finally, we conclude the work in Section IX.

II. RELATED WORK
In recent years, several authentication and access control mechanisms have been designed in Internet of Things (IoT), wireless sensor networks, healthcare, and other applications [1]- [23].
Monrat et al. [24] surveyed the potential applications of blockchain in diverse disciplines like healthcare, voting, energy trading stock exchange, insurance, education etc. They also discussed the opportunities, trade off and challenges of blockchain in respective domains. Moreover, the taxonomy and architecture of blockchain was provided. Furthermore, several other approaches to reach a consensus in the blockchain was surveyed. Some future research directions of the domain were also highlighted.
Zheng et al. [25] discussed the concepts and characteristics of blockchain and identifies it's benefits in various domains apart from ''bitcoin''. Further, the authors discussed a number of technical challenges like scalability, privacy leakage, selfish mining associated with consensus algorithms ''Proof of Work (PoW)'' and ''Proof of Stake (PoS)''. Their study also focused on state-of-art of blockchain including recent growth and future directions. Further, they planned to work on smart contract in a detailed manner to overcome associated defects and limitations.
Aggarwal et al. [26] discussed the usage of blockchain in ''smart communities'' like ''smart cities'' and ''smart nations'' where different IoT devices are located in different geographical regions. Processes of block creation and block verification, various consensus mechanisms, cryptographic primitives are also discussed. Further, classification of the application realm in cyber security is provided in an extensive manner. For example, financial systems, intelligent transportation systems, IoT, smart grid, healthcare networks, voting systems, data center networks etc. Thereafter they discussed various process models (behavior model, government sector, business model) where clusters are formed by grouping the similar process and thus provided data security using blockchain technology. Moreover they provided the information regarding communication infrastructure support like wired and wireless networks (5G, Wifi, SDN, Mobile computing).
Lin et al. [27] discussed the benefit of smart homes and other smart facilities for the society. At the same time they also focused on the risks associated with the remotely accessed and controlled IoT devices that could be exploited for malicious purpose. Thus they analyzed the importance of a secure and efficient remote user authentication and presented a system. For example, ''Homechain'' which integrates blockchain, group signatures and message authentication code.
Zhang et al. [28] discussed the issues in smart grid like secure communication, reliable mutual authentication and privacy credentials, key management etc., and considered key management between smart meters, the most critical aspect of smart grid. They presented a decentralized keyless signature scheme using consortium blockchain which is computationally cost effective, time effective, scalable, robust and efficient.
Wang et al. [29] discussed about the ''Internet of Vehicles (IoV)'' as one of the important application of mobile vehicles and wireless technologies, providing the information regarding mobile position, direction, speed and other real time information thus avoiding the traffic jams and accidents. Further, proposed a decentralized authentication mechanism using consensus algorithm of blockchain for IoV. They used blockchain to design new key distribution mechanism for joining the new node's information in the blockchain ledger.
Lin et al. [30] focused on the limitation of the IoT system due to resource constrained IoT devices and proposed an ''outsourcing of bilinear pairings (SOBP)'' integrated with permissioned blockchain to address the shortcoming. Thus helps in overcoming the limitations of IoT. They utilized the potentials of permission blockchain (i.e., enhancing security, service availability and system scalability). Finally authors proved and implemented the proposed system to evaluate its security, performance and feasibility.
Chaudhary et al. [31] focused on the emerging and recent technology ''Tactile Internet'' in the field of intelligent transportation system and identified the need to create a secure energy trading ecosystem. Further, proposed a blockchain based secure energy trading scheme in electric vehicle (EVs) for validating EVs request, selecting minor nodes to validate the request, etc. In order to make it computationally effective i.e., low latency and provide real time services, SDN was utilized as an under lying architecture.
Feng et al. [32] discussed the VANET environment i.e., vehicles were connected through wireless communication medium. Some of the potential benefits were like intelligent routing, weather monitoring emergency call etc. They also identified the importance of accuracy and reliability of the communicated message. Further, proposed a framework named as ''blockchain assisted privacy pressuring authentication system (BPAS)'' that preserved the vehicle privacy and provides automatic authentication in VANET. Blockchain automatically checked the message credibility, monitor vehicle behavior and also traced immutable communication record. Further security analysis was conducted to check the proposed framework for security and privacy of VANET.
Jindal et al. [33] proposed a framework to provide energy trading between electric vehicles (EVs) and charging stations (CSs). To secure the energy trading transactions in software defined networking (SDN) aided vehicle to grid environment, consensus based blockchain was used. It reduced the latency and increased the throughout and thus make the proposed system effective and efficient.
Mingxiao et al. [34] surveyed the effectiveness of blockchain because of its decentralization, stability, security and non-modifiability properties. It identified that consensus algorithm played an important role in the success of blockchain. Further, they reviewed the principles, characteristics, performance analysis and application scenarios of different consensus algorithm.
Zhang et al. [35] highlighted the importance of reaching a consensus in group decision making process (GDM) with minimum cost and maximum return. Further, proposed a generalized ''minimum cost soft consensus models'' and ''maximum return model'' under a certain degree of consensus. The correlation between both the model and their economic significance was also presented. In order to prove its utility the proposed models were applied in loan consensus problem in P2P lending utilizing data from Chinese P2P platform and demonstrated how it helped borrowers and lenders to attain a certain level of consensus about interest rate. It efficiently coordinated the supply and demand in P2P lending.
Jang et al. [36] designed a ''hybrid security scheme that uses both heterogeneous cryptosystems, such as symmetric and asymmetric (public) key cryptographic techniques''. Unfortunately, their scheme fails to maintain ''anonymity property'' and also it does not support ''dynamic controller node addition and medical device addition''.
He and Zeadally [37] designed another authentication protocol by using the ''ambient intelligence, specifically for an Ambient Assisted Living (AAL) system''. Their protocol helps in monitoring health-related information and also in providing ''tele-health care services''. Their system applies the ''wearable sensors in the wireless body area networks (WBANs) and assistive robotics''.
Chase and MacBrough [39] provided a comprehensive description and carried detailed analysis of XRP ledger consensus protocol (low latency Byzantine agreement protocol to reach a consensus without universal agreement of network participants. Along with providing the detailed description of the XRP ledger consensus protocol, they validated the networks conditions required to guarantee correctness of the algorithm.
In order to achieve both anonymity and regulation properties, Lin et al. [40] designed a ''conditional anonymous payment scheme'' and applied the designed scheme to construct their first ''decentralized conditional anonymous payment system''. As compared with the Zerocash, they have shown that their proposed system can be deployed for practical real-world deployment.
Ismail and Materwala [41] provided a detailed study on the evolution of blockchain frameworks and consensus protocols. They identified the need to develop a scalable, cost-efficient and green blockchain frameworks to address the goals for a green collaborative, decentralized and agile ecosystems like smart cities, such as health care and governance. An overview of blockchain technology including blockchain layers i.e., infrastructure layer, platform layer, distributed computing layer and application layer/business logic were also presented. Furthermore, the taxonomy, classification (compute-intensive based, voting based and capability based) and comparison among different consensus protocols were provided.
Finally, in Table 1 we summarize discussed existing authentication schemes with their applied cryptographic techniques and disadvantages/limitations.

III. SYSTEM MODELS
We follow the following two models in the designing of BAKMP-IoMT.
A. NETWORK MODEL BAKMP-IoMT uses network model as shown in Figure 1. In this figure, we have a patient who is implanted with medical devices such as neurostimulator, cochlear implant, cardiac pacemaker and gastric stimulator. There is personal server node (sometimes called as controller node) nearby to the patient which collects the data from the IMDs through some wireless communication technology such as bluetooth. Personal server then transmits the collected data to the cloud server through the access point. Cloud servers receive and store the data which can be used for the further processing. There are some users who are interested in accessing the data of the patient (i.e., doctor, nurse and patient's relative). Various network entities i.e., IMDs, personal server, cloud server and users, in the system is registered by the trusted authority. Patient's data can be accessed by the user from the cloud server after performing the certain steps of the user authentication process. In this model cloud servers are the resource rich devices which have high processing, storage and communication capacity. Cloud server acts the miner node in this blockchain based Internet of Medical of Things communication environment. After receiving the data from the personal server, cloud server (miner node) prepares a block and add this in the blockchain when it is successfully committed by the other miners. This kind of communication environment is susceptible to different attacks such as ''replay'', ''manin-the-middle'','' impersonation'', ''password guessing'', ''session key computation'' through physical capturing of devices, ''health data disclosure'' and ''denial of service''. Communication between IMDs to personal server, personal server to cloud server and cloud server to user, must be secured. Hence, session key must be established between the user and the cloud server, and also between the cloud server and personal server. Since majority of implantable medical devices have limited resources so we select to utilize lightweight cryptographic operations (i.e., hash, XOR operations) in the different exchanged messages. The addition of blockchain operations at the cloud servers give more resilience to this scheme against the possible attacks. Therefore, we need a secure data access scheme in the blockchain based IoMT communication environment. Using this scheme the communicating entity (i.e., doctor) can securely access the data of a patient without any disclosure. Moreover, in our proposed scheme (BAKMP-IoMT), we consider only a private blockchain because the healthcare data is fully confidential and private. As a result, if these data is somehow put on a public or even on a hybrid blockchain, privacy issues related to healthcare data will arise.

B. THREAT MODEL
BAKMP-IoMT is designed using the guidelines of widelyused (DY) threat model [42]. According to DY model any two communicating parties communicate over an open insecure channel and also, the end-point entities such as IMDs, personal server and users are not in general trustworthy. An adversary (A) can read (eavesdrop) the communicated messages and can also modify or delete the transmitted messages over insecure channel. We also follow Canetti and Krawczyk's adversary model, known as the CK-adversary model [43], [44] which is current de facto standard model in the modeling of an ''authenticated key-agreement security protocol''. According to the assumptions of CK-adversary model, A can have all the potentialities as in the DY model along with that he/she can compromise the secret credentials and with the session states (session keys) in the sessions. Apart from that A can physical capture some IMDs, personal servers or the mobile device of the users and extracts the stored information from these devices by utilizing the sophisticated power analysis attack [45]. This derived information can be used to perform other malicious activities for example acquiring of secret credentials and session key computations, ''device impersonation attack'', ''replay attack'', ''privileged-insider attack'' and ''man-in-the-middle attack''. At long Last, the trusted authority (TA) is thought to be full trusted entity in the network and it won't be compromised. Moreover, cloud servers acts as the miners in the network. Hence, they are also considered as the trusted entities.
In order to improve the security of BAKMP-IoMT, following three factors are used for authentication purpose: 1) mobile device MD U i of a user U i which stores significant credentials required for authentication, 2) password of U i , and 3) personal biometric of U i . To safeguard against replay attack, different random nonces (numbers) and current timestamps are utilized. Moreover, all the network entities participating in BoMT communication environment are assumed to be synchronized with their clocks. This is a fair assumption, which is included in the designing of several newly proposed authentication protocols [46]- [49], [50]. We utilize cryptographic one-way hash function and bitwise XOR operations to form BAKMP-IoMT lightweight as IMDs are resource constraint in nature. For biometric verification, we utilize the fuzzy extractor at the user side only. In order to provide better security, expensive computations are carried on resource-rich devices i.e., user's mobile device and cloud server, in the network [51].
It is worth noticing that the trusted authority (TA) only involves during the registration phase, which is one-time process. The TA does not have any other role in our proposed system. Moreover, the TA does not take any participation in active role during the communication (for example, key management phase, user login and authentication & key agreement phases, and blockchain construction and addition phase). In addition, even the TA does not know what kind of information the entities exchange and what are the values of established session keys among various network entities.
Hence, it will be definitely a risky task to involve the cloud servers for the registration of different network entities, and in that situation, some active attacks, such as ''privileged insider attack'', ''illegal credential leakage attack'' and ''unauthorised session key computation attack'' may be possible. As a result, we utilize only the trusted authority (TA) for the purpose of registration of various network entities instead of the cloud servers.

A. PRE-DEPLOYMENT
In this phase the registration of various network entities is done by TA. The pre-deployment phase is explained below.

1) IMD REGISTRATION
The TA selects a unique identity ID IMD k for implantable medical device IMD k and computes corresponding pseudo-identity where the co-efficients a i,j 's are selected from GF(p) and Z p = {0, 1, 2, · · · , p − 1} with p being an adequately large prime and t is sufficiently greater than the total count of IMDs to be deployed. For instance, a bivariate polynomial [a m,n (RID IMD k ) m ]y n , which is certainly a univariate polynomial of the same degree t. Then TA stores the credentials {RID IMD k , χ (RID IMD k , y)} in IMD k 's memory before their implementation. Note that for safeguarding unconditional security and t-collusion resistant property against IMD physical capture attack by an adversary A [52], [53], it is necessary to achieve the property t n IMD . This is because if greater than t IMDs are not trapped by A, the original polynomial χ(x, y) will not be computed by the compromised polynomial shared from these IMDs's memory respectively.

2) PERSONAL SERVER REGISTRATION
The TA first chooses his/her own identity ID TA and computes corresponding pseudo-identity RID TA = h(ID TA ||N ). TA further selects a unique identity ID PS l for personal server PS l and computes corresponding pseudo-identity RID PS l = h(ID PS l ||N ) using the TA's secret key N and temporal credential TC PS l = h(ID PS l ||ID TA ||RTS PS l ||N ) where the registration timestamp of PS l is RTS PS l . TA then computes the polynomial share χ(RID PS l , y) = t m,n=0 [a m,n (RID PS l ) m ]y n for each PS l , where χ (x, y) = t m,n=0 a m,n x m y n ∈ GF(p)[x, y] is the same symmetric bivariate polynomial of degree t that is previously chosen in Section IV-A1. Then TA stores the information {RID PS l , TC PS l , RID TA , χ(RID PS l , y))} in PS l 's database before its deployment. VOLUME 8, 2020

3) CLOUD SERVER (MINERS) REGISTRATION
The TA first chooses a unique identity ID CS j for cloud server CS j and computes corresponding pseudo-identity RID CS j = h(ID CS j ||N ) using the TA's secret key N . After that TA stores the information {RID CS j , RID TA } in CS j 's database before its deployment.

B. KEY MANAGEMENT
Key management phase is required to secure the communication between IMD k to PS l and PS l to CS j . After the successful completion of all steps of key management phase IMD k to PS l and PS l to CS j establish secret pairwise keys for their secure communication.

1) KEY MANAGEMENT BETWEEN IMPLANTABLE MEDICAL DEVICE AND PERSONAL SERVER
To establish secret pairwise key between an implantable medical device IMD k and a personal server PS l following steps are used: • IMD k first generates current timestamp TIP 1 and sends the message . PS l then transmits the message substantiate the timeliness of TIP 2 by investigating if where TIP * 2 is the receiving time of the message. If TIP 2 is successfully verified, IMD k computes ω = χ (RID IMD k , RID PS l ), the secret key SK IMD k ,PS l = h(ω ||TIP 1 ) and MS 1 = h(SK IMD k ,PS l ||TIP 2 ). Then IMD k checks whether MS 1 = MS 1 . If the condition is fulfilled, the calculated secret pairwise key is correct. Later on, both IMD k and PS l store SK IMD k ,PS l (= SK PS l ,IMD k ) for their future secure communication. This phase is summarized in Figure 2.

2) KEY MANAGEMENT BETWEEN PERSONAL SERVER AND CLOUD SERVER
To establish secret pairwise key between a personal server PS l and a cloud server CS j following steps are performed: • PS l first produces a random nonce r 1 and a current timestamp TPC 1 and calculates M 1 = h(r 1 ||TC PS l ) Otherwise CS j immediately terminates the session with PS l . Further, CS j produces a random nonce r 2 and a current timestamp TPC 2 , and computes . Then PS l checks whether M 4 = M 4 , if so CS j is authenticated with PS l and computed session key is correct.
• Further PS l generates a current timestamp TPC 3 and computes M 5 = h(SK PS l ,CS j ||TPC 3 ) sends message At the end, both PS l and CS j store SK PS l ,CS j (= SK CS j ,PS l ) for their future secure communication. This phase is summarized in Figure 3.

C. USER REGISTRATION
For accessing the data of IMD k in a ''blockchain based Internet of Medical Things'' communication, user (i.e., doctor) U i is registered using User registration method. For this purpose, U i requires secure registration at the trusted authority TA either in person or through a secure channel using the below mentioned steps: • Step REG1. U i /MD U i chooses his/her identity ID U i and sends the request for registration ID U i to TA securely.
• Step REG2. After receiving registration request, TA computes U i 's pseudo identity as where RTS U i is the registration timestamp generated for U i by TA. TA then prepares a registration reply for U i as RID U i , α, RID TA , h(·) and send that to U i through a secure channel.
• Step REG3. After receiving registration reply RID U i , α, RID TA , h(·) from TA, U i selects a password PW U i according to his/her liking and also furnish biometric data BIO U i to the terminal of a specific device.
where σ U i and τ U i are the biometric secret key of l bits and public reproduction parameter.
• Step REG4. U i selects 160-bit secret number x and computes pseudo-random password , Gen(·), Rep(·), t} in its memory. U i discards the information RID U i , RID TA , α, x from MD U i 's memory as a means to safeguard the lost/stolen smart card/mobile device attack by an adversary.
• Step REG5. For the secure communication between TA and CS j , we assume a master symmetric key MK TA−CS j . After U i 's successful registration, TA transmits the information {RID U i } encrypted utilizing the symmetric key MK TA−CS j , and then the CS j decrypts the received information utilizing the same symmetric key MK TA−CS j to store it in its database. Finally, the CS j accumulates information {RID CS j , RID TA , RID U i } in its database. This phase is abridged in Figure 4.

D. LOGIN PHASE
In order to login into the system, U i is required to execute the below mentioned steps: • Step LOG1. U i furnishes his/her identity ID U i and password PW U i and also marks biometrics information BIO U i at the sensor of the specified device. MD U i computes biometric secret key σ U i = Rep(BIO U i , τ U i ) with the constraint that the hamming distance between the actual biometrics BIO U i furnished at the time of user registration process and currently provided BIO U i is less than or equal to the error tolerance threshold value t.
• Step LOG2. MD U i next computes other parameters such as After the computation of these parameters, MD U i also calculates EQ = h(ID U i || RID TA ||δ ), and then examines the equality of EQ = EQ. If it results in a match, MD U i validates the authenticity of U i locally, else the login phase ends immediately.

E. AUTHENTICATION AND KEY AGREEMENT PHASE
After receiving the login request M 1 , M 2 , TS 1 from U i , the specified steps are executed between a user U i and cloud VOLUME 8, 2020 server i.e., CS j which provides service to U i . After the successful completion of these steps, mutual authentication is achieved between communicating parties U i and CS j and for their secure communication, session Key is also established.
• Step AU1. CS j first examines the timeliness of TS 1 by the expression |TS 1 − TS * 1 | ≤ T , where the maximum transmission delay is denoted by T and TS * 1 is the reception time of the message M 1 , M 2 , TS 1 . If it matches, CS j computes r U i = M 1 ⊕ h(RID TA ||RID U i ) and M 2 = h(r U i ||RID U i || RID TA ||TS 1 ) by using the stored value RID U i for user U i . Further CS j verifies the equality of the equation M 2 = M 2 . If it holds, U i is authenticated by CS j . Else, CS j terminates the session with U i immediately.
• Step AU2. Then CS j generates the current timestamp TS 2 along with 128-bit random nonce r CS j and computes

F. BLOCKCHAIN CONSTRUCTION AND ADDITION PHASE
To serve this purpose, an implantable medical device IMD k , personal server PS l , cloud server CS j and user U i can perform following steps: • Step BDA1. When IMD k has to send some data to PS l , it first generates a current timestamp TP 1 and prepares a message by applying the encryption using the computed and established pairwise secret key SK IMD k ,PS l , say msg 1 = E SK IMD k ,PS l (d IMD k , TP 1 ) and sends this to PS l via open channel. After receiving • Step BDA2. In the proposed model, the cloud servers act as the miner nodes. Each cloud server receives the data of the patient from the personal server through the established secret key securely between the cloud server and the personal server. After receiving , CS j decrypts the message E SK PS l ,CS j (d IMD k , TP 2 ) to get the values of d IMD k and TP 2 . Next, CS j examines the timeliness of TP 2 by the expression |TP 2 − TP * 2 | ≤ T , where TP * 2 is the receiving timestamp of the message. If it holds, the message is treated as a valid one.
• Step BDA3. Using data d IMD k , CS j starts the procedure of block creation and its addition into the blockchain. The procedure is explained as follows.
Here, the details of generating a block by the CS j and verification of the created block by the P2P cloud server (CS) network is provided. The block is added in the blockchain when the consensus is successfully committed among all the cloud servers in P2P CS network. The structure of block is depicted in Figure 6. After successfully collecting the data d IMD k , CS j builds the transactions of the collected data. Let Tx 1 , Tx 2 , · · · , Tx n t be the transactions generated during a session by the CS j . The creation of a block, say BLK i , contains the transactions Tx 1 , Tx 2 , · · · , Tx n t as provided in Figure 6. The concept of private blockchain is used in the BAKMP-IoMT for the better secrecy and confidentiality of the information. The block BLK i can be formed as follows.
-A public key encryption E(·) is used to encrypt all the transactions utilizing public key Pub CS j (for BAKMP-IoMT, we employ the ''ECC encryption''). When the block BLK i is built by CS j , this block is forwarded to other miner nodes (cloud servers) in the P2P CS network. For the verification and addition of the constructed block (i.e., BLK i ) using the consensus algorithm by P2P CS network, the following steps are needed to be executed.
-When a block BLK i is received by a cloud server, a miner (cloud server CS j ) will be chosen as a leader, say L from the all available cloud servers in the P2P CS network using the existing leader selection process described in [28]. -The ''Ripple Protocol Consensus Algorithm (RPCA)'' [29] for block verification and addition via voting method is utilized. It is also assumed that each cloud server CS in the P2P CS network has an ECC-based private-public key pair (r CS , Pub CS ), where Pub CS = r CS · G. -Moreover, the public keys of other cloud servers are accessible to CS. -Algorithms 1 and 2 are used to explain this process, which is similar to the consensus mechanism applied in [1].
• Step BDA4. Suppose a user U i needs to access secret information d IMD k from B IMD k . For this issue, his/her request goes to the corresponding cloud server (miner node, i.e., CS j ). Furthermore, note that CS j and CS j maintain a common ledger. Therefore, CS j has access B IMD k . CS j extracts d IMD k from B IMD k by applying the operations of blockchain. For example, CS j extracts KU IMD k from certificate part of B IMD k . CS j further applies the hash function h(·) on data d IMD k and gets h(d IMD k ). CS j then decrypts E KP IMD k (h(d IMD k )) and again gets h(d IMD k ). If both hashes are equal, that is, h(d IMD k ) = h(d IMD k ), the block B IMD k was not modified; otherwise, CS j discards the data of B IMD k .
• Step BDA5. U i and CS j already established the session key SK CS j ,U i . Therefore, CS j generates a current timestamp TP 3 , and computes a message This phase is summarized in Figure 7.

G. PASSWORD AND BIOMETRIC UPDATE PHASE
BAKMP-IoMT provides the facility to update password and biometric information by any authorized user. Following steps can be used by a legal user to update his/her password and biometric information regardless of time without involving TA. These steps must be rigorously executed to maintain VOLUME 8, 2020 Algorithm 1 Consensus Procedure for Block Verification and Addition in Blockchain Input: Given a block BLK i = {BVer, PBHash, MR, TR, OB,Pub CS j , {E Pub CS j (Tx s ) |s = 1, 2, · · · , n t }, CBHash, BSign}; private-public keys pairs (r CS j , Pub CS j = r CS j · G) for all other cloud servers in the P2P CS network. Output: Verification and addition of BLK i in the blockchain.
1: First, a leader (L) is selected among the peer nodes in the P2P CS network using the existing leader selection process described in [28]. Assume L has a block BLK i = {BVer, PBHash, MR, TR, OB, Pub CS j , {E Pub CS j (Tx s ) |s = 1, 2, · · · , n t }, CBHash, BSign}. 2: L sets VTCount ← 0, where VTCount signifies the vote counter. L also sets flag CS j = 0, ∀{j = 1, 2, · · · , n cs , L = CS j }, where n cs is the number of cloud servers in the P2P CS network. 3: L creates distinct random nonce rn j and a current timestamp TS j for each cloud server. 4: L encrypts rn j with the public key Pub CS j of each CS j as E Pub CS j (rn j , TS j ). 5: L sends the message SMsg j = {BLK i , E Pub CS j (rn j , TS j ), TS j } to all other cloud servers CS j , (j = 1, 2, · · · , n cs , L = CS j ). 6: Assume SMsg j receives from L by each CS j in the P2P CS network at time TS * j . 7: for each cloud server CS j do 8: if (|TS j − TS * j | < T ) then 9: Compute the Merkle tree root, MR * on the encrypted transactions {E Pub CS j (Tx s ) |s = 1, 2, · · · , n t }. 10: if (MR * = MR) then 11: Terminate the consensus process. 12: else 13: Calculate block hash CBHash * on the received block Block i as CBHash * = h(BVer|| PBHash|| MR * || TR|| OB|| Pub CS j || E Pub CS j (Tx 1 )|| E Pub CS j (Tx 2 )|| · · · ||E Pub CS j (Tx n t )). 14: if (CBHash * = CBHash) then 15: Verify the signature BSign = (r m , s m ) on BLK i on the message msg = CBHash * with the help of ECDSA signature verification algorithm. 16: if signature is valid then 17: Decrypt the encrypted random nonce using pre-computed private key r CS j as (rn * j , TS j ) = D r CS j [E Pub CS j (rn j , TS j )] by applying the ECC decryption algorithm. 18: if (TS j = TS j ) then 19: Send the block verification message containing verification status (VStatus) and decrypted random nonce as RMsg j = {E Pub L (rn * j , VStatus)} to the leader L. 20: end if 21: end if 22: end if 23: end if 24: end if 25: end for Algorithm 2 Consensus for Block Verification and Addition in Blockchain (Continued. . .) 26: for each received RMsg j from the responders CS j do 27: L computes (rn j , VStatus) = D r L [E Pub L (rn * j , VStatus)]. 28: if ((rn j = rn j ) and (VStatus = valid) and (flag CS j = 0)) then 29: L sets VTCount = VTCount + 1 and flag CS j = 1. 30: end if 31: end for 32: if (VTCount is more than 50% of the votes) then 33: Transaction enters to the next round. 34: if (VTCount less than the threshold value, that is, 80% of the votes) then 35   α n , EQ n , β n , and τ n U i , respectively. Finally, MD U i stores the information {RID n U i , RID n TA , α n , EQ n , β n , τ n U i , h(·), Gen(·), Rep(·), t} in its memory.

H. DYNAMIC NODES ADDITION PHASE
Following steps can be used by the BAKMP-IoMT to add a new device i.e., IMD in the network any time.

1) DYNAMIC IMD ADDITION
The addition of IMD can be done using the following steps.
• Step DAI1. A unique identity for new IMD, ID IMD ν is selected by the TA and it also computes the corresponding pseudo-identity RID IMD ν = h(ID IMD ν ||N ) where the TA's secret key is N . Next the TA determines a unique symmetric bivariate polynomial χ (x, y) = t m,n=0 a m,n x m y n ∈ GF(p)[x, y] of degree t over a finite field (Galois field) GF(p) (= Z p ), where the co-efficients a i,j 's are chosen from GF(p) and Z p = {0, 1, 2, · · · , p − 1} with p being a satisfactorily large prime and t is enough larger than the total count of IMDs to be deployed. For instance, a bivariate polynomial χ(x, y) = x 4 + 3x 3 + 2x 2 y 2 + 3y 3 + y 4 over GF(5) is symmetric as χ (y, x) = y 4 + 3y 3 + 2y 2 x 2 + 3x 3 + x 4 = χ(x, y). • Step DAI2. The TA computes a polynomial share χ(RID IMD ν , y) = t m,n=0 [a m,n (RID IMD ν ) m ]y n , which is clearly a univariate polynomial of the same degree t. Then TA stores the credentials {RID IMD ν , χ(RID IMD ν , y)} in IMD ν 's memory before their deployment.

2) DYNAMIC PERSONAL SERVER ADDITION
The addition of new personal server can be done using the specified steps. TC PS η , RID TA , χ(RID PS η , y))} in PS η 's database before its deployment.

3) DYNAMIC CLOUD SERVER (MINERS) ADDITION
The addition of new cloud server can be done using the following steps. Hence, in practice it is preferable to use the cloud servers (CS j ) for block consensus via voting and blockchain implementation. Though the RPCA mechanism is not that heavy, but still we preferred to execute block consensus via voting and blockchain implementation over the peer nodes (CS j ) in the P2P cloud servers network only in order to reduce the computational burden on IMD k , PS l and MD i . As discussed earlier, we consider a private blockchain in BAKMP-IoMT, which provides more security, and at the same time it has several restrictions and limited entities. As far as the annual fee is concerned, in most of the countries the healthcare facilities (including healthcare infrastructure) are supported by the government organisations. Therefore, payment of annual fee will not be an issue for healthcare infrastructure users in the proposed scheme.

V. SECURITY ANALYSIS OF BAKMP-IoMT
This section contains the ''security analysis of BAKMP-IoMT'' in Propositions 1-8, which prove the resilience of BAKMP-IoMT against the below mentioned attacks.
Proposition 1: BAKMP-IoMT can resist ''replay attack''. Proof: In BAKMP-IoMT, we have used different current timestamps values in the transmitted messages. Each exchanged message of BAKMP-IoMT, have a maximum transmission delay T component (a small value). Moreover, replaying the old transmitted messages does not provide any profit to the adversary A which were required for ''authentication and key management procedure'' among IMD k , PS l , CS j and U i within T . Therefore, BAKMP-IoMT is capable to resist replay attack.

Proposition 2: BAKMP-IoMT is able to protect against the ''man-in-the-middle attack (MITM)''.
Proof: Let an adversary A eavesdrops an authentication request message {M 1 , M 2 , TS 1 } which was exchanged between U i and CS j , and after that A tries to update this message so that it resembles like the original authentication message, as {M a 1 , M a 2 , TS a 1 } with the help of parameters such as M a 1 = r a U i ⊕ h(RID TA ||RID U i ), and M a 2 = h(r U i ||RID U i ||RID TA ||TS a 1 ). For the launching of MITM , A can start the generation of random nonce r a U i and current timestamp TS a 1 . However, in the absence of knowledge of ''long term secret'' RID TA , RID U i and N the secret key of TA, A can not regenerate another valid authentication request message {M a 1 , M a 2 , TS a 1 }. Similarly, we can also elucidate that other messages can not be computed again by A which are utilized in the ''authentication and key management'' phase without the ''long-term secrets'' utilized by U i and CS j or the other entities of the network. Hence, BAKMP-IoMT is secured against the man-in-the-middle attack.
Proof: Let an adversary A tries to impersonate as an valid communicating entity of the network by creating an authentication request message on behalf of that entity say U i . After obtaining U i 's authentication request Here it is important to notice that Msg 1 uses M 1 and M 2 which are generated through ''long term secrets'' i.e., RID U i , RID TA and N , and also through the ''short term secrets'' for example, random nonce r U i . A is not capable to generate a valid ''authentication request message'' representing the legitimate user U i without having the knowledge of these secret values. Therefore, BAKMP-IoMT is secured against the ''user impersonation attack''. By using the same methodology, we can prove that BAKMP-IoMT is also secured against other types of impersonation attacks i.e., ''cloud server'', ''personal server'' and ''implantable medical device'', because the creation of other messages also utilize both ''long term'' and ''short term'' secrets. Hence, BAKMP-IoMT is resilient against the various impersonations attacks.

Proposition 4: BAKMP-IoMT protects ''Ephemeral Secret Leakage (ESL) attack''.
Proof: In BAKMP-IoMT, ''session key'' is calculated by a legitimate user U i and the cloud server CS j , during the ''authentication and key management process'' as SK CS j ,U i = h(r U i ||RID U i ||TS 1 ||TS 2 || h(r CS j ||RID CS j )||RID TA ). In the creation of the session key, the pseudo identities RID U i , RID CS j of user U i and cloud server CS j are used. It also consists of the different random nonce values r U i , r CS j of user and cloud server. It is important to notice that ''session key'' is the amalgamation of both the session-temporary (ephemeral) information also known as ''short term secrets'' (various timestamp and random nonce values) along with ''longterm secrets'' (various identities and secret keys). Therefore, session key can only be revealed in a situation if A compromises both the ''short-term'' and ''long-term'' secret values. Furthermore, as various random nonce and timestamps values are utilized in calculation of the session keys among various entities i.e., U i and CS j , IMD k and PS l , and PS l and CS j in all different sessions, even if a session key is revealed for a specific session. It will not cause the revealing (i.e., illegal computation) of session keys of other sessions because of coalescence of short and long term secret values. Thus, BAKMP-IoMT is capable to protect session-temporary information attack and it also preserves the ''perfect forward secrecy'' goal. Hence, BAKMP-IoMT is secured against ''ESL attack''.
The OF contains following sections [58]: • SUMMARY: It tells ''whether the tested protocol is safe, unsafe, or whether the analysis is inconclusive''.
• DETAILS: It states an explanation of ''why the tested protocol is concluded as safe, or under what conditions the test application or protocol is exploitable using an attack, or why the analysis is inconclusive''.
• PROTOCOL: It denotes the ''HLPSL specification of the target protocol in the IF''.
• GOAL: It presents the ''goal of the analysis which is being performed by AVISPA using HLPSL specification''.
• BACKEND: It is the ''name of the back-end that is used for the analysis, that is, one of OFMC, CL-AtSe, SATMC and TA4SP''.
• Final section includes the ''trace of a possible vulnerability to the target protocol, if any, along with some useful statistics and relevant comments''. We have implemented the registration, login and authentication phases of our proposed BAKMP-IoMT in HLPSL specification. The basic roles for the TA, a user U i and a cloud server CS j are shown in figures 8, 9 and 10, respectively. The mandatory roles (session and goal & environment) are also implemented as composite roles in Figure 11. In the simulation under the AVISPA backends, three verifications, namely: a) ''executability checking on non-trivial HLPSL specifications'', b) ''replay attack checking'', and c) ''Dolev-Yao threat model (DY model) [42] checking''. The ''executability check'' is essential to assure that ''the protocol

VII. PERFORMANCE ANALYSIS
In this section, we first evaluate the performance of the user registration, and user login and authentication phases of our For computational cost analysis, assume that T h and T fe denote the time needed to execute a ''one-way hash function (say, SHA-256 hashing algorithm)'' and a ''fuzzy extractor function (Gen(·)/Rep(·)'', respectively. During the login and authentication phase, a user U i needs the computational cost of 12T h + T fe and a cloud server CS j requires  computational cost of 7T h . Thus, the total computational cost in BAKMP-IoMT becomes 19T h + T fe . Since only hash function and fuzzy extractor are applied, the proposed scheme is very efficient.
During the user registration process, a user U i 's mobile device MD U i requires the credentials {RID U i , RID TA , α , EQ, β, τ U i , t}. If we assume that ''public reproduction parameter τ U i '' and ''error-tolerance threshold value t'' require 160 bits and 32 bits, respectively, the storage cost needed to store these credentials in BAKMP-IoMT becomes (256 + 256 + 256 + 256 + 256 + 160 + 32) = 1472 bits.
We now perform a detailed comparative study for the ''computation and communication costs'' and ''security and functionality features'' among the proposed BAKMP-IoMT and other related existing schemes, such as the schemes of Jang et al. [36], He and Zeadally [37] and Merabet et al. [38].
In Table 3, we have shown a comparative analysis on ''security and functionality features'' among BAKMP-IoMT and other schemes against the considered features SFF 1 -SFF 17 . It is seen that the proposed BAKMP-IoMT provides superior security and also more ''functionality features'' while these are compared with the schemes of Jang et al. [36], He and Zeadally [37] and Merabet et al. [38].  For comparative analysis on computational costs among the proposed BAKMP-IoMT and other schemes during login and authentication phases, we use various execution time for cryptographic primitives as listed in Table 4 based on the existing experimental results in [59]. Using these results, a comparative study on computational costs among the proposed BAKMP-IoMT and other schemes has been done in Table 5. It is also worth noticing that BAKMP-IoMT requires low computational cost as compared to that for other schemes, such as the schemes of Jang et al. [36], He and Zeadally [37] and Merabet et al. [38].
Finally, a comparative study on communication costs among the proposed BAKMP-IoMT and other schemes is also provided in Table 6. It is observed that BAKMP-IoMT requires low communication cost as compared to that for other schemes, such as the schemes of Jang et al. [36], He and Zeadally [37] and Merabet et al. [38].

VIII. PRACTICAL DEMONSTRATION
The pragmatic delineation of BAKMP-IoMT using the strategies of blockchain was proceeded as follows [60]. Table 7 represents the details of different parameters used during the experimentation. Three unique scenarios were considered in the experimentation. The experimentation was conducted on a platform having Windows 10 64-bit OS with Intel (R) core i5-8250U, 1.60 GHz-1.80 GHz processor. The size of random-access memory (RAM) size was 8 GB. The programming platform was eclipse IDE 2019-12 with 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.
• Timestamp: It is the value of timestamp for a particular block. The size of this field can be considered as 32-bits.
• Owner of Block (OB): It represents the identity of block owner. The size of this field can be considered as 160-bits.
• Owner public key: This field have the information of ''public key of the owner (miner) node''. The size of this   field is considered as 320-bits (since the ''Elliptic Curve Cryptography (ECC) algorithm'' is considered). • Block signature: It contains the ''signature information of a particular block''. The size of this field requires 320-bits (if ECC algorithm is applied). The following results were obtained during the reenactments.

A. IMPACT ON COMPUTATIONAL COST
The effect on increasing number of IMDs and users was computed as the computation cost (in ms) for all considered 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 cost'' increases with the number of IMDs and users from scenario-1 to scenario-2 as well as from scenario-2 to scenario-3 as increase in number of IMDs and users causes ''creation and addition'' of more number of blocks in the blockchain.

B. IMPACT ON TRANSACTION PER SECOND (TPS)
The impact on our proposed BAKMP-IoMT on transactions per second (TPS) is also measured as per the considered scenarios. The values of TPS are 119, 200 and 242 for scenario-1, scenario-2 and scenario-3, respectively. The reported results are additionally delineated in Figure 17. It is worthy to see that the value of TPS increases as the blockchain grows with  more number of IMDs and users. The reason is straightforward because it causes the creation and addition of more number of blocks in the blockchain.

IX. CONCLUSION
In this paper, we designed a novel blockchain enabled authentication key agreement protocol for IoMT environment (BAKMP-IoMT). BAKMP-IoMT provides secure key management among different communicating entities. 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. The formal security verification of BAKMP-IoMT is also performed to demonstrate its resilience against the different types of possible attacks using the widely-accepted AVISPA tool and also through formal and informal security analysis. BAKMP-IoMT is compared with other related existing schemes and it also performs better in terms of security and functionality features, less communication and communication costs for authentication and key managment phase as compared to the other schemes. Furthermore, the simulation of BAKMP-IoMT is conducted to demonstrate its impact on the performance parameters.