A Blockchain-Assisted Lightweight Anonymous Authentication Scheme for Medical Services in Internet of Medical Things

Internet of medical things (IoMT) enable physicians to provide precise care on the Internet for registered patients anywhere, bringing convenience to people’s everyday life. Considering the importance of patient’s privacy in IoMT, data security between patients and medical servers should be protected. Therefore, the authentication of identity and the agreement of a shared secret key are particularly important. In this work, we propose a lightweight anonymous authentication scheme between patients and medical servers in IoMT. We combine blockchain technology with biometric technology in order to form a shared session secret key. It can protect the privacy of patients through mutual authentication between patients and servers. Afterwards, the formal analysis of BAN logic shows that our scheme is secure. Non-formal analysis shows that our scheme achieves designed security objectives. Finally, comprehensive comparative experiments show that our proposed scheme achieves a better performance in both computation and communication efficiency.


Introduction
With the development of information technology, Internet of Medical Things has been integrated into people's daily life, bringing great convenience to medical treatment. Patients can complete various medical services such as registration via smart terminals, instead of going to the hospital. It greatly saves patient's time and money. However, due to massive devices in internet of medical things, patients are facing privacy leakage and network attacks while enjoying the convenience of electronic medical services [1].
Accordingly, how to protect privacy has become a major issue in IoMT. Wang [2] demonstrates that authentication technology is usually used to achieve a high-level privacy protection scheme. In order to complete the authentication between the user and multiple servers in IoMT, a complex authentication scheme is required. However, it is 1 3 often believed that servers are centralized, honest, and curious [3]. Although the centralized "client-server" model can fulfill the patient's authentication, centralization brings various privacy and security challenges [4,5]. How to achieve effective authentication between patients and medical servers while protecting privacy is a worthwhile studying question.
In the IoMT environment, there must be a lightweight authentication scheme to achieve patient authentication due to limited computing power of patient devices. Although many authentication schemes have been proposed by scholars [6][7][8], it is difficult to balance validity and computational complexity. They are deficient in security and reliability more or less.
In recent years, the research of blockchain has attracted more and more attentions. Blockchain-assisted technology provides a potential way for authentication scheme, especially in medical field, the internet of vehicles, and smart grid, etc. [9][10][11]. Unfortunately, there are little researches on lightweight authentication scheme for medical field based on blockchain currently. Therefore, we propose a lightweight anonymous authentication scheme based on consortium blockchain in IoMT. Members of the consortium blockchain include server nodes and the registration center (RC). In summary, our scheme realizes lightweight mutual authentication between patients and medical servers based on the consortium blockchain. The main contributions of this work are as follows: • We propose a lightweight anonymous authentication scheme between patients and medical servers based on consortium blockchain in IoMT. Our scheme achieves privacy protection, data confidentiality and integrity, resistance to replay attacks, resistance to masquerading attacks, and resistance to offline password guessing attacks. • We design concrete implementation steps for the authentication protocol. It combines blockchain and fuzzy extraction technology. The secret key can be shared between the patient and the server when mutual authentication is completed in our protocol. What's more, we formalize the proof (using BAN logic language) in order to ensure the reliability and security of the protocol. • We conduct a detailed comparison of our protocol with compared protocols. Our scheme can protect the privacy of patients well. Furthermore, our scheme mainly uses XOR and hash algorithms for mutual authentication, instead of using bilinear pairing with a large amount of calculation. Therefore, the authentication scheme is lightweight. It does not take up too much memory resource in IoMT environment. The time complexity and space complexity are low, and both have a computational complexity of O(n). It is particularly suitable for deployment in IoMT environment.
Blockchain technology has the advantages of decentralisation, tamper-proofing and anonymity. It is particularly suitable for authentication in the data-sensitive IoMT environment. In this work, we combine blockchain technology and biometric authentication technology to design an effective lightweight and anonymous authentication protocol. The protocol completes authentication in the IoMT environment while protecting the patient's sensitive privacy information.
The remaining part of this paper is organized as follows: An overview about existing works is described in Sect. 2. Preliminaries are presented in Sect. 3. Section 4 describes the system architecture, the threat model and security requirements. Afterwards, Sect. 5 describes the details of the agreement. Furthermore, we do security analysis, including formal analysis and nonformal analysis in Sect. 6. We compare the computational overhead and communication overhead with comparative approaches in Sect. 7. Finally, Sect. 8 concludes the work.

Related Work
In this section, we first present research trends of authentication in IoMT. Then, we conduct a brief report about blockchain-assisted technology for medical services.

Authentication in IoMT
In recent years, scholars have proposed many authentication and key agreement schemes in IoMT. A user authentication scheme based on lightweight passwords was proposed by Lamport [12] for the first time. The scheme relies on the password only, thus it is not secure enough. Thereafter, several authentication schemes were proposed for various applications as follows.
Malasri [13] proposed a wireless sensor network authentication scheme based on an elliptic curve in IoMT. Unfortunately, the scheme is vulnerable to relay node attacks and denial of service provision. Chuang [14] proposed a multi-server environment-based biometric anonymous authentication scheme, but Mishr [15] pointed out that the scheme is vulnerable to server spoofing, smart card theft, and counterfeiting attacks. Based on the mobile edge computing network, He [16] designed an improved user authentication scheme. However, Odelu et al. [17] proved that He's scheme is prone to replay attack, tracking attacks, and user simulation. They [17] proposed a biometric based smart card authentication protocol, which could better overcome the above shortcomings. In [18], Jia et al. proposed an anonymous authentication scheme based on fog computing environment. It is also apt to a temporary session attack because the attacker can guess the identity of the user when the user session key is leaked. Irshad. [19] proposed a pairing-free lightweight authentication protocol for mobile cloud computing framework. The authentication was achieved without involvement of trusted entity. It also lacks the formal security analysis.
In addition, Kumari et al. [20] proposed a provable secure multi server authentication scheme based on cloud computing. However, Feng [21] found that the scheme proposed in [20] failed to guarantee user anonymity and perfect forward security. So they designed a multi server authentication scheme based on anonymous biometrics. Meanwhile, A three factor multi server authentication scheme based on elliptic curve cryptology system was proposed by Ali and Pal [22]. But Wang [23] pointed out that it is vulnerable to user simulation and denial of service attacks. Thereafter, Wang et al. [23] proposed an improved authentication scheme. However, Wu [24] underlined that the scheme proposed by Wang et al. is vulnerable to user simulation and server simulation attacks.
The above authentication schemes mainly rely on flexible security models and ingenious interaction schemes. It is mainly assumed that there is a trusted authoritative center, which could make the network vulnerable to be damaged due to a single point of failure. One of the ideal ways to solve centralization problem is to use blockchain-assisted technology.

Blockchain for medical services
The blockchain is a shared distributed ledger that records network transaction information of peer-to-peer devices. The ledger in the network will be kept by a copy among member 1 3 nodes. The transaction between peer nodes will be permanently recorded in the block. Therefore, blockchain technology can ensure the authenticity, reliability, and non-tampering of data.
Recently, Ekblaw [25] proposed an electronic medical record management system in IoMT, which used blockchain to ensure the accuracy of medical records. However, the protocol does not specify the access control strategy for data access. It may lead to the exposure of medical record information. Jiang [26] built a healthcare information exchange blockchain platform, which combines offline storage and online verification to ensure the privacy and authentication of healthcare data. In [27], Wang. et al. gave an authentication protocol based blockchain for user identity management, but Vivekanandan [28] pointed out that the computation cost of Wang's scheme is more higher. Siyal [29] analyzed the challenges faced by blockchain in the medical field, they believed that electronic medical records could be verified when using blockchain without third-party verification, but the scheme of Siyal et al. [29] could not guarantee the reliability of data. It would lead to the decline of data availability. What's more, Sastry et al. [30] proposed a user authentication protocol in mobile cloud environment based on blockchian. They used a three-factor authentication mechanism to authenticate users by bilinear pairing. However, the use of bilinear pairs brings high computational costs.
Yaz [31] proposed a novel decentralized authentication of patients in a distributed hospital network. However, the approach of Yaz [31] is decentralized. It was designed for IoT devices with limited computational, memory and energy capabilities. Nevertheless, it did not involve that how to implement a prototype of the proposed approach in a real-world setting. In [32], Fan et al. proposed a verifiable scheme to achieve oneto-many data sharing via blockchian. The blockchain data is maintained by users, but it is difficult to determine the consortium blockchain members. Recently, Zhang et al. [33] proposed a transaction processing scheme for IoT consortium blockchain adaptively with IoMT applications, which is proved to achieve anonymous, traceability, and nonframeability.
In summary, the existing works provided a variety of frameworks for patient and medical server authentication. They are broadly divided into two categories: some studies have focused more on the security of the scheme and the other studies focused mainly on the computational overhead. In fact, most of them manage to achieve a certain balance between data security and computational complexity. In addition, these authentication schemes rarely used blockchain technology to ensure the reliability of data. These works also did not provide detailed solutions for specific applications. In this work, we design an anonymous authentication scheme based on the consortium blockchain, in which the secret key is shared between the patient and the server. The protocol can protect patient privacy and achieve a variety of security requirements.

Complexity Assumption
We put forward technical preliminaries in this subsection. Our scheme is based on the following two difficult problems, which cannot be solved in finite polynomial time.

Definition 1 Elliptic Curve Discrete Logarithm Problem (ECDLP). Let G be an additive
cycle consisting of points on the elliptic curve. P is a generator of G, and q is the order of group G. ECDLP problem can be described as: Given xP, output x in polynomial time.

ECDLP Assumption:
It is assumed that it is difficult to calculate x under the circumstance of xP ∈ G in polynomial time.
Definition 2 Computational Diffie-Hellman Problem (CDHP). Given P, aP, bP ∈ G , P is a generator of a cyclic group G with order q. a and b are unknown random numbers where a, b ∈ Z * q . An algorithm that solves the computational Diffie-Hellman problem is a probabilistic polynomial time turing machine. The input of turing machine is (P, aP, bP). The output of turing machine is abP.
CDHP Assumption: Computational Diffie-Hellman assumption means that there is no such a probabilistic polynomial time turing machine to solve the CDHP.

Fuzzy Extraction Technique
Considering that the biological characteristics of the same person may have small errors each time, we use fuzzy extraction technology to overcome the impact of such small differences. The same random string is restored when the difference in biological characteristics is less than the threshold. Specifically, fuzzy extraction technology consists of two algorithms: Key generation algorithm and Key recovery algorithm.

Definition 2 Key recovery algorithm.
, the input is the patient's biometrics BIO ′ i and auxiliary string PP ∈ {0, 1} * . The output is a random string SP ∈ {0, 1} n when the difference between the biometric and the re-input is less than the threshold.

Blockchain Technology
Blockchain is a collection of data elements. Elements in the collection are called blocks. All the blocks form a chain in order. Blockchain has the characteristics of distribution, decentralization, and trustiness. In the absence of a trusted central node, the blockchain can achieve mutual trust and consensus among network nodes. The blockchain system can be divided into three subtypes: public blockchain, private blockchain, and consortium blockchain.
The public blockchain is permissionless. It is a permissionless network where anyone can join and participate in consensus processes. Unlike public blockchains, private blockchain is a closed network. It is controlled by an individual or private organization. However, consensus blockchains are semi-open, access-controlled systems which can be used to establish industry alliances for the same organization type.
The consortium blockchain generally consists of full nodes and light nodes in an industry consortium. Full nodes requires high-level hardware and networking equipment in order to participate in the consensus process of a blockchain consortium. In contrast, light nodes only store the summary information of the block and transactions related to themselves. They don't take part in consensus decisions. As a result, these nodes adopt a certain consensus to determine the generation and addition of blocks. Therefore, a consortium blockchain provides better control, moderate costs, and high reliability, which makes it ideal for building a decentralised and trusted system.
In our scheme, we utilize a consortium blockchain, which is composed of a registry and multiple servers in IoMT environment. Due to the different characteristics of full nodes and light nodes, it is important to note that not every entity can participate in the consensus process of the consortium blockchain. Thus only the members of the consortium blockchain can access the data on the blockchain. So it is confidential except for consortium blockchain members.

System Model
In this section, we describe composition of the system model and function of each entity. In addition, we also present the threat model and security goals in IoMT environment.

System Architecture
The system consists of five entities: patients, smart terminals, registration center, servers, and blockchain network. In particular, the blockchain network includes blockchain and smart contracts. The system model is shown in Fig. 1.

Patient
Firstly, a patient provides identity information, personal password, and biometric information (e.g. face image information collected through smart terminals). Whereafter, the patient registers at the RC and servers respectively. When the patient completes registration and identity verification, a shared key is formed and relevant medical services are provided for patients in turn.

Smart Terminal
The smart terminal can collect the patient's password, biometric information, and identity information in the mobile edge computing network. They are sent to RC subsequently. It's worth noting that the smart terminal can be authenticated by the server after being registered with the RC.

Registration Center
The RC receives request information from a smart terminal. It invokes a smart contract to check whether the user is legitimate or not. The RC grants the user registration when the user's identity meets the registration criteria and the user is not registered simultaneously. When the user completes the registration, the RC uploads relevant information (such as a hash value of the patient's identity, a hash value of the XOR of key and biological features) to the blockchain via a smart contract.

Servers
Once receiving the authentication request message from the smart terminal, the server decides whether the user authentication message is legal or not, by comparing the user authentication message with the registration information on the blockchain.
Furthermore, the user also needs to complete the authentication for the server. This is a two-way authentication process. After the two-way authentication of the server and the smart terminal is completed, a session key will be formed between the two sides.

Blockchain
Blockchain can guarantee the imtamability and integrity of data. In details, patients upload their anonymous and real identities to the blockchain in IoMT. The server judges whether the user's real identity is tampered with by the attacker. As a general view, we use the consortium blockchain in our schemes. The consensus mechanism uses the PBFT algorithm. Members of the consortium blockchain include a RC and every server in IoMT environment.

Threat Model
In our scheme, we consider the registry is credible, and the data stored in the server database is secure. The attacker cannot steal the data in the server database. There is a preshared secret key between the registry and the server. Particularly, the secret key is only known to the registry and the server.
We assume that the communication between the registry and the server is secure in IoMT. It means that their pre-shared secret keys are not compromised. We assume that attackers can intercept the communication messages between the patient and the server in the mobile edge computing environment. We assume that attackers may launch the following attacks, such as replay attack, masquerading user attack, masquerading server attack, or offline password guessing attack.

Security Requirements
Taking into account the above security threats in IoMT, security requirements are described as follows: Date confidentiality and integrity. Date confidentiality and integrity should be guaranteed by encryption and signature. The key can guarantee the confidentiality of the patient's data. Attackers fail to recover the shared key from the intercepted message. Blockchain should ensure that the data uploaded to the ledger will not be tampered with. In a general way, it is critical to protect patients' medical information.
Resist replay attacks. An external adversary may capture the previous message and replays the out-of-date messages to victim. Replay attacks can render the system unservicable, causing delays in patient care. Here, our scheme uses a timestamp and random number mechanism. It can effectively resist the attacker's replay attack.
Resist masquerading attack. In order to maintain the security of the patient's identity, the unique identity of the patient should not be misused by strangers. In other words, the attacker cannot forge a legal patient's identity for authentication (i.e., the attacker cannot pretend to be a patient for authentication by spoofing the server).
Resistance to offline password guessing attacks. Patient's password is sensitive information. It is fairly important to keep it secure. Passwords should not be inferred from existing knowledge. It is not feasible for an attacker to try to log in by guessing the password offline, because an attacker can not access knowledge of the password.
Effective anonymous privacy protection. Attackers cannot deduce the patient's identity information from the anonymous information. Malicious attackers cannot infer the user's real identity from the user's anonymous information. The patient's private information should be guaranteed effectively.

Proposed Protocol
In this section, we first present an overview about the process of our protocol briefly. Table 1 shows some of the parameters used in our protocol. Afterwards, we describe the proposed protocol in details, as shown in Fig.2.

Overview
The protocol is made up of three phases: system setup phase, registration phase, and authentication phase.
When a patient i with identity ID i arrives at a hospital for a medical service, he/she firstly send Me1 = ID i , PW i , BIO i to the RC, then RC can obtain Me1. The RC calculates SP and PP according to the user's biometrics BIO i through the fuzzy extraction function. Also, the RC calculates A i , B i , AID i , E RS , V u respectively, where AID i is an anonymity of the patient i. The RC invokes the smart contract in blockchain to determine whether the patient i is registered. If AID i has not been registered, RC will add AID i to the registerable list using smart contracts.
Afterwards, the patient i generates Me5= AID � i , M 1 , M 2 , E RS , T 1 and sends it as an authentication message to the server. Once receiving the authentication message, the server The key entered by the patient i AID i ∶ The anonymous identity of patient i m i ∶ A secret number selected by patient i k ij , k ji ∶ A shared key between patient i and server j m j ∶ A secret number selected by server j PSK : Pre-shared key between registration center and server Whereafter, the server has completed the one-way authentication of the patient. Similarly, the server replies to the patient's smart terminal with the response information M 3 , M 4 , T 3 . The server is certified by the patient if the following equation is proved to be true.
Finally, the server and the patient form a shared session key k ij . The server sends the authentication result to the accounting node and writes it to the consortium blockchain through the PBFT algorithm. The authentication message is disclosed on the consortium blockchain.

Protocol Description
The proposed protocol contains three process: System setup phase, Registration phase, and Authentication phase.

Phase1: System setup phase
Step1: G 1 is an additive cyclic group of points on an elliptic curve. P is the generator of a cyclic group. The order of the cyclic group G 1 is prime q. Z * q is a reduced residue systems modulo q and a, b ∈ Z * q . Step2: The RC selects four secure hash functions h 1 Then the RC announces initialization public parameters as {G 1 , a, b, q, h 1 , h 2 , h 3 , h 4 }.

Phase2: Registration phase
Step1: The patient i enters personal information such as ID i , PW i ,BIO i on the smart terminal. Once the smart terminal receives the above information, it sents Me1 = ID i , PW i , BIO i to RC via a secure channel.
Step2: The RC first carries out a preliminary identification of the user's ID i to ensure that the patient can be effectively treated in the hospital. If the user's ID i is valid, the RC will authorize the patient's identity and continue to work on the next operation.
Step3: The RC calculates the following parameters, where BIO i is the input of the fuzzy extraction function and (PP, SP) is the output of the fuzzy extraction function. m is a nonce selected by the RC. AID i is the anonymity of ID i . E RS and V u are intermediate parameters. (1) It is noteworthy that PSK is the pre-shared key between RC and server, which is only shared between RC and server.
Step4: The RC invokes the smart contract to query whether AID i is on the blockchain. If AID i doesn't exist on the blockchain, the RC will do three operations in parallel as follows.
First, the RC invokes the smart contract. The smart contract adds AID i to a registerable list and uploads (ID i , AID i ) to the consortium blockchain.
Second, the RC sents Me3 = {AID i ‖SP � � E RS � � V u } to the patient i via a secure channel. Third, the RC keeps the mapping table of (ID i , A i , AID i ) in its own database. Otherwise, AID i has already existed on blockchain. It indicates that the patient has been registered before and it can directly enter the authentication phase.

Phase3: Authentication phase
Step1: The patient enters identity ID ′ i , password PW ′ i and Biological characteristics BIO ′ i on the smart terminal.
Step2: The smart terminal calculates the following equation: Subsequently, it checks whether the following equation holds or not: If the equation is not valid, the smart terminal refuses the patient. Otherwise, it proceeds to the next step.
Step3: The patient selects a random number m i ∈ Z * q by the smart terminal and keeps the nonce m i secretly. The smart terminal calculates M 1 , M 2 as follows:

as authentication information requested for the server.
Step4: Once the server receives the patient's authentication message, it firstly checks T 2 − T 1 < ΔT , where T 2 is the current timestamp. If it does not hold, it will be terminated. Otherwise, the server uses BIO ′ i and PP to recover a random string SP, where BIO ′ i is entered by the patient i. PP is recovered from E RS using the pre-shared secret key PSK.
Secondly, the server invokes the smart contract to download ID i according to AID ′ i from the blockchian. Afterwards, the server checks the following equation: If the equation does not hold, it will stop. Otherwise it continues to proceed to the next step of the agreement.
Step5: The server chooses a nonce m j ∈ Z * q secretly and calculates m j P . Then the server calculates the following parameters: The server can calculate the shared session key as follow: Then the server replies to the patient with a message Me7 = M 3 , M 4 , T 3 .
Step6: When the smart terminal receives a reply message from the server. It decides the following equation T 4 − T 3 < ΔT holds or not, where T 4 is the current timestamp. If it does not established, the smart terminal stops. Otherwise, it continues to perform as follows: Thus the smart terminal also verifies whether the following equation holds or not: If it does not hold, it will stop. Otherwise, the smart terminal continues to calculate follow parameters: Then it sends a confirmation message Me9 = M 5 to the server. Step7: The server verifies the following equation: If the equation holds, the certification is completed. The server sends the authentication result to the accounting node. The node writes it to the consortium blockchain through the PBFT algorithm and publishes the authentication result on the blockchain.
In summary, we give a detailed description of the protocol in this section. As can be seen from our protocol, patients complete lightweight anonymous authentication with the server finally, and they negotiate a shared key K ij . In the next section, we will further prove that the shared key formed by our protocol is secure, and our protocol can resist various security attacks.

Security Analysis
In this section, we describe formal and informal security analysis for our scheme. Formal security analysis is done by BAN logic. It verifies the security features of our scheme to ensure the session key protocol between the patient and the server. Informal security analysis is accomplished by analyzing protocols against several related attacks.

Formal Analysis
BAN logic is a formal analysis method proposed by Burrows [34]. It is used to define and analyze the communication process between two parties. The specific instructions are as follows: 1. The message-meaning rule: The entity U believes that the key k is shared by U and S.
U receives X which is encrypted with k. Then U believes S once said X.
2. The nonce verification rule: If U believes that X is fresh and S sends X to U, U believes that S believes X.
3. The belief rule: If U has trusted in the set of messages ( X, Y ), U trusts in the message X.
4. The fresh conjunction rule: If U believes the part of ( X, Y ) is fresh, U believes that the whole ( X, Y ) is fresh.
5. The jurisdiction rule: If U believes that S has jurisdiction rule over the message X, and U trusts S on the trueness of X, U trusts S on the trueness of X.

Idealization
The protocol is idealized as follow:

Initial state assumption
In the protocol, there are the following assumptions in the initial state.
Our scheme is considered to meet the certification requirements if it achieves the following goals:

Scheme analysis
Here, we analyze the protocol using rules and assumptions.    The above proof shows that the expected goal is realized. It demonstrates that our scheme achieves mutual authentication between patient i and server j in IoMT. Meanwhile, patient i and server j believe that the session key K ij = m i m j P is securely shared between them in in IoMT.

Nonformal Analysis
In this subsection, we describe how the protocol effectively achieves security goals.

The Proposed Protocol Can Achieve Data Confidentiality and Integrity
The patient uses the shared session key K ij =m i m j P to encrypt the message when the authentication is completed. The patient will use the secret key m i m j P to encrypt the registration message. So the ciphertext fail to be decrypted if there is no decryption key.
Under the assumptions of ECDLP, given m i P ∈ G , it is difficult to calculate m i . What's more, even if the attacker intercepts m i P and m j P , it still cannot obtain m i m j P because calculating K ij from m i P and m j P is a CDHP difficult problem. Thus, only the expected user can decrypt the ciphertext, which enhances data confidentiality. Finally, the blockchain is a distributed multi-party secure ledger. Related information is stored on the blockchain. The data of the blockchain can't be tampered with, which ensures data integrity.

The Proposed Protocol Can Resist Replay Attacks
The proposed scheme uses timestamps and random numbers, which can resist replay attacks. Firstly, the timestamp T 1 , T 2 , T 3 , T 4 is used to avoid replay attacks. It can ensure the freshness of the message.
Specifically, the patient's authentication message contains a timestamp such as AID ′ i , M 1 , M 2 , E RS , T 1 . Thereby the attacker's replay attack is avoided by comparing the timestamps. Secondly, replay attacks are avoided because of the use of random numbers. It can be avoided by judging whether the random numbers contained in the reply message are the same as the initial values.

The Proposed Protocol Can Resist Masquerading Attacks
The attacker cannot forge the patient's authentication message to pass authentication. On the one hand, the attacker does not have the user's ID i and the server's random number m, so the attacker cannot forge AID i . On the other hand, even if the user intercepts the user's anonymous identity, the attacker cannot forge In addition, it is unrealistic for the attacker to recover m i P from M 1 , because the attacker fail to obtain SP. SP is generated by the biological characteristics of the patient. So the attacker can't pretend to be the user.

The Proposed Protocol Can Resist Offline Password Guessing Attacks
If the attacker holds the patient's smart terminal and attempts to log in by guessing the password offline, it is also not feasible. Because the following equation can't be passed.
Obviously, the attacker fails to obtain the user's identity information and biometric information. So the attacker fails to perform offline password guessing attacks.

The Proposed Protocol Can Achieve Anonymity and Privacy Protection of Information
Firstly, the user obtains the anonymity AID i which is assigned by the registry. The generation of anonymity requires a random number m provided by the registry. The attacker cannot obtain the random number m, so the anonymity can not be faked by the attacker. In addition, patients use anonymity AID i for registration and authentication without revealing their real identity ID i , which could protect personal privacy. Finally, even if a malicious attacker intercepts the patient's anonymous information such as AID i , the attacker still could not obtain the patient's real ID i from the anonymous AID i due to the one-way nature of the hash function. It also protects the patient's privacy.

Implementation and Performance Evaluation
In this section, we implement the proposed cryptographic algorithms, using PBC library 0.5.14 and JAVA programming language. The experimental data and computation time were obtained from a computer with Intel(R) Core(Dual) @ 2.20GHz processor, and the Ubuntu 12.04.1 operating system. We use the Type A curves defined within the PBC library because they are widely used in primitives cryptography. In the PBC library, the Type A curve is chosen as E(F q ) ∶ y 2 = x 3 + x . The group order of G 1 is 160bits and the order of the base field is 512bits. So p is a 512bits prime number and q is also a 512bits prime number. The length of the element in G 1 is 1024bits. The output length of hash map is 160bits.

Comparisons of Security Properties
To show the security of our scheme, we compared the security properties of our scheme with existing authentication schemes. From Table 2, it is very obvious that only our scheme has conducted multiple security properties. Existing schemes introduced in [35,36,[38][39][40] are vulnerable to several security threats compared with our work.
In particularly, we use blockchain technology to protect the integrity and reliability of data in IoMT. What's more, the consortium blockchain also guarantees the security of data. Meanwhile, non-consortium members cannot access the ledger on the blockchain. So it easily comes to the conclusion that our scheme can achieve better security goals.

Comparisons of Communication Overhead
In this subsection, we compare security properties: the communication overhead and computational overhead with other comparative schemes. We denote that | G | is the size of an element in group G 1 and | Q | is the size of an element in Zp. It's easy to figure out that | G | = 1024bits, and | Q | = 160bits. It should be pointed out that the length of a respose message or an identity were all set to 32bits. The timestamp is set to 32bits in our implementation. Specifically, the packet sizes in our experiment are as follows: | AID i | = 160bits, | SP | = 160bits, | E RS | = 160bits, | V u | = 160bits, | PW i | = 32bits and | ID i | = 32bits. As mentioned above, the blockchain is designed to guarantee the reliability and immutability of certificates, so the communication overhead of uploading and downloading to blockchain were ignored in order to unify the benchmark. We mainly compare cryptography communication overhead with other schemes [38][39][40] in Table 3. In registration phase of our scheme, the content of communica- The total communication overhead is 5 | Q | +64 = 864 bits. Meanwhile, the communication overhead of Kumar [38] is | G | +32 = 1056 bits . The communication overhead of Tsai [39] is | G | +32 = 1056 bits . The communication overhead of Lwamo. [40] is 3 | Q | +32 = 512 bits . It can be found that the communication overhead of our scheme is lower than that of Kumar and Tsai's scheme [38,39], except for Lwamo's scheme [40].
In authentication phase, the communication overhead in our scheme contains Me5, Me7, and Me9.
It should be pointed out that there are two reasons for higher communication overhead in our sheme contrasted to comparison schemes [38,40]. One reason is that we hide the random secret number in the group elements (e.g. m i P , m j P ) in the communication process in order to enhance the security of the protocol. The other reason is that we get a lower computational complexity and a more robust safety feature at the expense of some communication overhead.

Comparisons of Computational Overhead
In this subsection, we conduct extensive experiments and performance evaluations in order to compare the computer overhead. The calculation time benchmark used in this paper was evaluated by referring to the experimental benchmark given by Kilinc and Yanik [37]. In computational overhead analysis, the average computational time for hash functions ( T h ), Point multiplication ( T mul ), Pairing operation ( T bp ) are 0.0023ms, 2.226ms, and 5.811ms respectively. Point addition ( T pa ) is 0.0288ms, Modular exponentiation ( T exp ) is 3.85ms. String to point hash ( T mtp ) is 12.418ms, public key encryption(T enc ) is 3.85ms, decryption(T dec ) is 3.85ms and the computational overhead of XOR operation time is disregarded.
We compared the computational cost of our scheme with that of the comparative schemes. In Registration phase, the computational cost of our scheme is 3T h + 3T xor = 0.0069ms . As a contrast, the computational cost of [38][39][40] is Table 3 Communication  overhead  Transactions  Registration phase  Authentication phase The proposed 5 | Q | +64 2 | G | +6 | Q | +64 Kumar [38] | G | +32 2 | G | +2 | Q | +32 Tsai [39] | G | +32 3 | G | + | Q | +32 Lwamo [40] 3 | Q | +32 10 | Q | +32 31.23ms, 27.41ms, and 3.86ms respectively. In authentication scenario, the computational cost of [38][39][40] is 25.44ms, 16.14ms, and 23.13ms, but in fact, the computational cost of our scheme is only 7T h + 2T xor + 4T mul = 8.92ms , which is the least amount of time compared with the other literatures in our experiment, as shown in Table 4. Furthermore, Fig. 3 shows the comparison of calculation time at different scenario more intuitively between our scheme and the candidate schemes. The total time overhead of the proposed solution is 8.93ms, while the time overheads of the comparison solutions [38][39][40] are 56.67ms, 43.55ms and 26.99ms respectively. It can be seen that our scheme performs best in terms of computational complexity on overall process. This is because we used lightweight algorithms such as hash functions and XOR, instead of variable operation on groups and bilinear pairs. In details, the total communication overheads of schemes [38][39][40] are 3456 bits, 4320 bits and 2144 bits respectively, while the total communication overhead of the proposed scheme is 3936 bits, so our communication overhead is not too expensive. In general, the computational complexity of our scheme and comparison schemes are all O(n). In addition, our scheme performs the best in time complexity, and the space complexity is acceptable. Therefore, our scheme achieves a superior experimental performance under the premise of effective lightweight anonymous authentication.

Conclusion
In this work, we present a lightweight anonymous authentication scheme based on the consortium blockchain to achieve mutual authentication between patients and medical servers in IoMT. A blockchain-assisted technology is used to ensure the confidentiality and integrity of patients private data. Meanwhile, fuzzy extraction technology is used to realize key aggregation. In addition, the proof of BAN logic demonstrates the security of the proposed Kumar [38] T mtp + 3T mul + 3T exp + 2T pa + 4T h 2T bp + T pa + 3T exp + 2T mul + 5T h + T mul Tsai [39] T mtp + 5T mul + T exp + 4T h 2T bp + 2T mul + 2T pa + 2T exp + 4T h Lwamo [40] 5T h + T xor + T dec 9T h + T xor + 3T enc + 3T dec scheme. Informal safety analysis shows that our scheme has achieved the designed security goals. Finally, comparative experiment shows that our scheme achieves a better performance in computation and communication overhead. It is an efficient mutual authentication protocol in IoMT.
Author Contributions Shu Wu contributed to protocl design and manuscript preparation; Aiqing Zhang performed the protocol analysis and important guidance work; Jindou Chen contributed to protocol analysis and manuscript preparation; Guangyu Peng designed system model and security objectives; Ya Gao designed securiyt objectives and protocl analysis.