Abstract

With the development of telecommunication systems and customized monitoring devices, telehealth has been widely used to improve medical quality and reduce overall health costs. However, the convenience of connection between the providers and patients through a public channel also leads to significant security and privacy concerns. Though there have been many authentication schemes designed for secure communications in telecare systems, most of them suffer from malicious attacks or have heavy computation and communication costs. Thus, in this article, we proposed a blockchain-based user authentication scheme integrating with access control and physical unclonable function (PUF). Permissioned blockchain and PUF are used to support secure data sharing across the healthcare service providers and identify the devices, respectively. Security analysis shows that our protocol satisfies the security requirements for telehealth services and is provably secure in the random oracle model. The performance evaluation demonstrates that it has less computation and communication costs compared with three of the latest schemes.

1. Introduction

Telecare medical information systems (TMIS) support remote medical services by providing online patient diagnosis to reduce healthcare service costs and improve patient health outcomes. The COVID-19 pandemic has promoted the use of telehealth to deliver, which can interrupt the transmission of the disease and facilitate public health mitigation by reducing outings.

As shown in Figure 1, patients at home are equipped with wearable monitoring devices. These devices can continually collect and transmit health data (e.g., blood pressure, blood sugar, heart rate, and more) to mobile devices. Health data will be transmitted to healthcare service providers (e.g., hospitals and health authorities) over the open internet. Then, care staff (e.g., doctors and nurses) can monitor the patient’s condition remotely and make timely treatment decisions for better outcomes.

Vulnerabilities in the wireless networks offer some easy entry points for malicious adversaries, yet these networks are important for connections between patients at home and remote healthcare organizations. Many countries have laws that are designed to protect the patient’s privacy, such as the Health Insurance Portability and Accounting Act (HIPAA) in the United States. Security in telecare services, i.e., how to ensure patient data security and privacy during transmission through the public channel, becomes a significant concern [1, 2].

User authentication is a necessary first step to ensure that only authorized users have access to protected data. Password-based user authentication scheme as the most convenient mechanism is widely employed, however, it is vulnerable to various attacks and could be a threat to data security. Multifactor authentication is a recommended approach in which any user is granted access to certain data after validating two or more pieces of evidence the user has.

In the meantime, people’s mobility between different healthcare institutions raises some problems: user authentication in multiple servers and secure data sharing across different servicers. To address the above issues, multiserver authentication is used for access to multiple servers with one credential [3] in existing schemes. However, most schemes [46] have unsatisfactory performance or may suffer serious security problems in the telehealth services environment.

Furthermore, interaction with patient records from personal devices may be fraught with peril since it is difficult for healthcare servers to verify whether those devices meet security configuration requirements. Attackers could impersonate legal users for free treatment or profit once they guess the correct password. Otherwise, they could impersonate the healthcare providers to offer false treatment, which will cause a critical medical accident.

Therefore, it is necessary to design a new authentication scheme to ensure security and data sharing and resist various attacks in the telecare services environment.

1.1. Our Contribution

In this paper, we propose a multiserver authentication scheme with the integration of user authentication and access control, which determines the access control to achieve selective data disclosure, enhance data privacy, and improve the scheme’s efficiency.

Blockchain has been widely applied in different areas because of its properties of immutability and decentralization [79]. In our scheme, some registration information will be recorded in the blockchain served as a trusted bulletin board to achieve secure data sharing across different healthcare provider servers.

PUF has been a promising cryptographic primitive, and it has been demonstrated in the security domain as well [10]. It serves as one of the authentication factors to identify the devices in the IoT systems, with the characteristics of being unclonable, unpredictable, and computable. We will introduce this technology to resist various attacks (e.g., impersonation attacks and physical attacks) for telehealth services.

The major contributions of this paper are summarized as follows:(i)Firstly, by leveraging blockchain technology and PUFs, we design an efficient user authentication protocol with access control for the telehealth system.(ii)Secondly, a comprehensive security analysis is given to show that the proposed protocol is provably secure and can satisfy the security requirements in the telehealth system.(iii)Finally, we implement a prototype by smart contract based on Hyperledger Fabric. We analyze the performance to show that our scheme has less computation and communication costs than previously proposed protocols.

1.2. Organization of Our Paper

The paper is organized as follows: in section 2, we discuss some related literature. In section 3, we introduce the preliminaries used in this paper. In sections 4 and 5, we present the details of the system framework and proposed authentication protocol for telecare service. In sections 6 and 7, we give provable security in the random oracle model and evaluate the performance of the proposed scheme. Finally, section 8 concludes this paper.

To secure remote healthcare services, some authentication schemes have been proposed. Debiao et al. [11] proposed an improved scheme to overcome the weakness of Wu et al.’s scheme [12] for TMIS. Their scheme is more efficient and applies to low-power mobile devices. However, the scheme cannot resist the offline password attack. Kumari et al. [13] proposed an improved user authentication scheme for applications in TMIS. Chen et al. [14] proposed a medical data exchange protocol based on the cloud environment for medical advice. Patient inspection information can be protected by asymmetric encryption. However, the scheme cannot provide user anonymity and has heavy computation costs.

Chiou et al. [15] resolved these security problems and provided a complete system implementation. Mohit et al. [4] reviewed Chiou et al.’s [15] protocol and found that it is susceptible to user anonymity and some attacks. They designed a lightweight authentication scheme in the cloud environment for TMIS. However, Kumar et al. [5] found that Mohit et al.’s [4] scheme is vulnerable to various attacks and cannot provide user anonymity and session key protection. They proposed an improved protocol for single-server architecture in TMIS but could not satisfy the perfect forward secrecy or multiserver environment.

Multiserver authentication scheme was first proposed by [3] using a neural network. Because of the complexity of the neural network, lots of schemes [1619] were proposed to improve the performance and enhance the security. Multiserver authentication scheme without online RC [20, 21] is suitable for various applications, which reduces the cost of trusted RC establishment and authentication communication.

Recently, blockchain has become a research hotspot in telemedicine to ensure healthcare data security and to support data sharing. Liu et al. [22] proposed privacy-preserving mutual authentication in TMIS, which provides user anonymity and malicious users traceability if necessary. Yazdinejad et al. [23] designed a blockchain-based authentication scheme to reduce reauthentication across different hospitals, which can increase throughput and reduce time overhead for resource-limited devices. Li et al. [24] proposed a group authentication mechanism for authorized group members to access sensitive health records in the remote medical monitoring scene. Cheng et al. [25] designed a multiple identity authentication for a secure medical data sharing model based on blockchain to avoid over-reliance on a third party. Lin et al. [26] designed a transitively closed undirected graph authentication scheme for dynamic blockchain-based identity management systems, which is efficient for signers to update their certificates without signing again. Wang et al. [27] proposed a decentralized, secure, and lightweight certificateless signature (CLS) protocol by transforming the logic of KGC into smart contract code, which can resist key generation center compromised attacks and distributed denial of service (DDoS) attacks. Xiong et al. [28] presented ECDSA batch verification protocol in the blockchain-enabled Internet of Medical Things (IoMT) to enhance authentication efficiency and support identification algorithms for false signatures.

Nevertheless, all of the above schemes have no consideration for integration authentication with access control to improve the system efficiency. The idea of the integration of user authentication and access control was first proposed by Harn and Lin [29] to avoid potential security problems between these two protection mechanisms. Later, some improved protocols [3032] were designed to enhance security and implement a protection scheme in distributed systems. Recently, Lin et al. [33] presented a remote mutual authentication scheme with fine-grained access control based on blockchain for industry 4.0 deployment. Xiong et al. [34] proposed an integrated scheme for a mobile cloud environment (MCC) without the trusted party to store the access control list. However, the computational overhead is expensive for limited mobile devices in telemedicine services.

Additionally, many PUF-based authentication schemes have been proposed for IoT systems, wireless sensor networks (WSNs), and so on. Since smart cards/devices are not tamper-resistant, some two-factor authentication schemes are susceptible to various physical attacks. To address the issues, PUFs are used as one of the authentication factors presented in some literature [3538] to enhance the properties of lightweight authentication solutions.

In this paper, we will construct a blockchain-based user authentication scheme for better efficiency and security, in which access control integration can enhance the authentication efficiency, and a physical unclonable function is applied to identify the devices against various attacks in the telehealth environment.

3. Preliminaries

3.1. Bilinear Pairings

Let be large prime numbers. Let be a cyclic additive group and be a multiplicative group with the same order . denotes a bilinear map, where a generator of and a generator of , when the subsequent conditions meet.(i)Bilinear: for all and .(ii)Nondegeneracy: there exists an element such that .(iii)Computability: given any two elements , it is efficient to compute .

The following mathematical problems are difficult, i.e., there is no polynomial algorithm to solve will be used in our proposed scheme.(i)Discrete Logarithm (DL) Problem: given an element , find such that .(ii)Computational Diffie-Hellman (CDH) Problem: given two elements , where are unknown, calculate .(iii)Modified Bilinear Inverse Diffie-Hellman with k Value (k-mBIDH) Problem: given k elements and k+2 elements , where is unknown, calculate for any .

3.2. Chinese Remainder Theorem (CRT)

Given N coprime integers , where for and . For integer , there exists the following:

The common solution can be computed as follows:where and for .

3.3. Physical Unclonable Function

The physical unclonable function is a one-way mapping from a challenge space to a response space based on the unclonable characteristic of the underlying physical device. A set of challenge-response pairs (CRPs) is unique for each device, which can be used to identify the device. A PUF circuit must meet the properties below:(i)Unpredictability: given any challenge , the probability to evaluate the response of PUF is negligibly small without PUF instance.(ii)Computability: given any challenge , it is easy to evaluate the response for any PUF instance.(iii)Uniqueness: for any two and , given the same challenge , the probability to evaluate the same response is negligibly small.(iv)One-way: given any , there exists no polynomial algorithm InversePUF: for any challenge .

3.4. Fuzzy Extractor

The PUF circuit is susceptible to interference to generate the noisy response with low entropy, which may fail to authenticate the device. Fuzzy extractor has been developed to recover a reliable high-entropy response from a noisy response to enhance the security of authentication. Fuzzy extractor consists of the following two algorithms:(i): a probabilistic key generation algorithm to generate the key and helper data .(ii): a deterministic reconstruction algorithm to recover the key from a noisy response and helper data , which the Hamming distance between the original response and the noisy response is at most .

3.5. Blockchain and Smart Contract

Blockchain technology is an immutable and distributed data ledger consisting of an append-only sequence of blocks chained by the cryptographic hash function. Based on permission authorized to network nodes, blockchain platforms are divided into three types: private blockchain, consortium blockchain, and public blockchain. In the proposed scheme, Hyperledger Fabric is chosen to support the flexible transaction and Turing-complete smart contracts.

The smart contract is an autoexecuted program deployed in the blockchain network, which can achieve complex functions, and it can be invoked by authorized nodes sending a legal transaction. The transaction is contained in the block after verification by the nodes. In our proposed scheme, we design the smart contract for registration information sharing between a trusted register center and multiple healthcare servers. The register center and servers can upload, query, and update the information by sending a transaction signed by its private key to invoke the smart contract. Users can query the information to ensure that their information can be authenticated by the whole network.

4. System Framework and Security Model

4.1. Network Model

Figure 2 describes the network model that consists of four types of entities in our proposed scheme, namely the trusted registration center (RC), the permissioned blockchain network (BC), the servers (hospital and medical institutions), and the mobile users (patients and healthcare servicers).(i)RC: it is a trusted third party and is responsible for system initialization, user/server registration, and registration information recorded in the blockchain network. It generates a master private key and issues a private key of the user/server according to their identities. Besides, it also randomly generates a challenge and sends it to the user’s devices. The registration record and challenge-response pair will be uploaded in the permissioned blockchain.(ii)BC: it acts as a trusted recorder for registration, sharing, and updating by the smart contract. The trusted RC and servers join as network nodes to maintain the permissioned blockchain network together.(iii)Healthcare Servers: the servers provide data storage for patient health records from wearable devices and support remote healthcare services between the healthcare provider and patients at home.(iv)Mobile Users: there are two types of mobile users: patients and healthcare providers. We assume that all the mobile devices are equipped with a PUF and fuzzy extractor. The output of the PUF is used as one of the authentication factors. Moreover, a fuzzy extractor has been employed to recover the noisy PUF. The mobile devices of patients can upload biomedical data collected by wearable devices to remote servers for personalized medical services after mutual authentication. The mobile devices of healthcare providers can get patient conditions and offer clinical diagnostics after authentication.

4.2. Network Assumptions

Patients can enjoy remote medical service by off-chain subscription service that hospitals/medical institutions provide and generate the access control list representing patients’ service time. Healthcare providers should also get permission (e.g., read, write, delete) to operate the data to achieve diverse data sharing across different institutions.

Each subscription service maps to a specific value according to the mapping rules predefined and will be stored in the blockchain by each server, which can be retrieved by any server to check the validity. The access control list is represented by , where , where represents the access permission the user applies for in , as shown in Tables 1 and 2. The server predefines the mapping rules of access permission, as shown in Table 3, and sends it to the RC in the registration phase.

Following the research efforts [39], after mapping, RC calculates the common solution of each user using CRT as follows:

In the authentication phase, the specific access permission can be calculated by the common solution.

then the server can check whether the user has been authorized or expired by equation (4).

4.3. Security Requirements

To ensure the security of the remote healthcare service, the proposed scheme should satisfy the following requirements [21, 3436, 40]:Single registration: for convenience to users, the proposed scheme should provide single registration. Users only register with the trusted RC once before they can communicate with healthcare servers.No online registration center: the proposed scheme should achieve mutual authentication without RC to relieve the communication overhead and resist the single point of failure.Mutual authentication: to ensure that legal users and servers could access healthcare data, the proposed scheme should provide mutual authentication between and to verify the legality of each other.User anonymity: to preserve the privacy of users, the proposed scheme should protect user identity. Any adversary cannot extract the real identity from the intercepted message.Untraceability: for the better protection of user privacy, no potential adversary can trace the user’s activities and behavior patterns by analyzing the intercepted message.Session key agreement: the proposed scheme should generate the session key between the users and servers to encrypt the message in future communications.Perfect forward secrecy: the proposed scheme should provide perfect forward secrecy to ensure the security of messages in the previous sessions. No potential attackers can generate the session key of previous sessions even if they obtain the long-term private key of two participants.Two-factor security: the proposed scheme should provide two-factor security, i.e., password and mobile device embedded with PUF.Access control for data privacy: the healthcare service providers can provide personalized remote healthcare services that users subscribe to for a specific service time. In the meantime, healthcare providers can be authorized to access the data with different permissions for preserving data privacy.Resistance of various attacks: to resist known attacks existing in the service system, the proposed scheme should resist known attacks, including impersonation attacks, physical attacks, replay attacks, man-in-the-middle attacks, etc.

5. The Proposed Scheme

We describe the proposed scheme in this section. The proposed scheme consists of seven phases: blockchain initialization, system setup phase, server registration phase, user registration phase, mutual authentication phase, password update phase, and access rights update phase.

5.1. Blockchain Initialization

RC establishes a consortium blockchain (e.g., Hyperledger Fabric) among RC and servers as network nodes to maintain the blockchain. The servers must register and enroll the identities as legitimate members to engage in the consensus process.

In the meantime, the smart contract (SC) will be deployed in the blockchain network and can be invoked by transaction. Algorithms 1 and 2 show that the smart contract supports the upload and query of challenge-response pair (CRP) and access permission. In the subscription phase, the servers will upload the subscription service time (for patients) or service permission (for healthcare providers) into the blockchain, which can be validated when RC computes users’ common solution. In the registration phase, RC will randomly generate the challenge and then receive the response produced by user’s fuzzy extractor via a secure channel. The challenge-response pair will be stored in the ledger to share with servers in the authentication process.

function uploadSubs(, , )
if userExists  = = false
  expiretime = time.Now().Month() +
  service = Service \{, , expiretime\}
  return putState(, service)
else
  return Errorf(“the user has already exists”)
function querySubs(, )
 err, result = getState
if (err = = null)
  return result
else
  return err
function updateSubs(, )
if userExists  = = true
  expiretime = time.Now().Month() +
  service = Service \{, , expiretime\}
  return putState(, )
else
  return Errorf(“the user does not exist”)
function uploadCRP(, , , , )
if userExists  = = false
  status = ‘valid’
    = time.Now()
  user = User \{, , , , , status\}
  return putState(, user)
else
  return Errorf(“the user has already exists”)
function queryCRP
 err, result = getState
if (err = = null && result.getStatus() = = ‘valid’)
  return result
else if (result.getStatus() ! = “valid”)
  return Errorf(“the CRP of user has been expired”)
return err
function updateCRP(, , , )
if userExists  = = true
  status = ‘valid’
    = time.Now()
  user = User \{, , , , , status\}
  return putState(, user)
else
  return Errorf(“the user does not exist”)
5.2. System Setup Phase

In this phase, the trusted RC generates system parameters and selects the master private key.(1)RC selects additive group and multiplicative group with the same prime order and a bilinear pairing . RC also chooses a generator of and then computes of .(2)RC randomly chooses as the master private key and calculates its public key .(3)RC selects seven secure hash functions , , , , , , , (4)RC publishes system parameters and keeps securely.

5.3. Server Registration Phase

As shown in Figure 3, the server registers with the RC to obtain its long-term private key through a secure channel. The steps below will be executed between and RC.(1)The server selects its and predefines the access control mapping rules . Then, transmits them to RC.(2)RC computes , selects a coprime integer , and sends to . RC stores securely.(3)After receiving, keeps secretly.

5.4. User Registration Phase

There are two types of mobile users in this scheme, including patients (remote service subscribers) and healthcare providers (remote service providers). The following steps will be executed by mobile users to register with RC, as shown in Figure 4.(1)The mobile user selects an identity and a password and generates a nonce . After subscription service, the access control list and will be sent to RC through a secure channel.(2)After receiving the request, RC computes the common solution using CRT according to the access control list of user , mapping rules , and by equation (3). After that, RC generates a random number , , and calculates using and its master private key. RC also generates a random challenge and sends it to .(3)After receiving the challenge , extracts the outputs of the PUF and then obtains the secret key and helper data from using a fuzzy extractor. After that, sends , to RC for authentication in future.(4)RC computes , , and and then uploads the “challenge-response” pair in the blockchain to share with the servers (healthcare providers), where denotes the service start time as shown in Algorithm 2. After that, RC sends to and stores the user registration table in the blockchain.(5) stores in the secure memory.

5.5. Authentication Phase

As depicted in Figure 5, the user authenticates with the server , and then a common session key is generated for secure communications.(1) inputs his identity and password . His/Her mobile device computes and then checks whether the equation holds. If not, it terminates the request. Otherwise, the device extracts the PUF output and using a fuzzy extractor. After that, it chooses a random number and calculates , where denotes the current timestamp. sends to via a public channel.(2)On receiving the message, first checks whether the timestamp is fresh. If not, rejects the session. Otherwise, computes by its secret key and . invokes the smart contract to get by input parameters . After that, checks whether the equation holds. If not, fails to authenticate . Otherwise, calculates to check whether the access control permission has expired by the equation , where denotes current time. If expired/not authorized, terminates the request. Otherwise, selects a random number , computes , and sets the session key , where is the current timestamp. Then, sends to . Note that the server can obtain and validate the user identity from the two following equations:(3)After receiving the message, first checks whether is fresh. If not, terminates the session. Otherwise, computes to check whether and are equal. If not, aborts the session. Otherwise, calculates the session key .

5.6. Password Update Phase

If wants to update the password, the following steps are executed between and his/her mobile device:(1) inputs , old , and new into the mobile device.(2)The mobile device computes and checks whether holds. If not, the mobile device rejects the request. Otherwise, the mobile device calculates . Then, the mobile device replaces with .

5.7. Access Rights Update Phase

must update the access control list and send a new to the RC after the renewal of subscription. The steps will be carried out between and RC.(1) generates a new access control list and sends to RC via a secure channel.(2)After receiving the message, RC obtains the old access control list from the user registration table by the index and updates . Then, RC computes the new common solution using CRT. After that, RC regenerates and sends to . Finally, RC updates the user registration table .

6. Security Analysis

We will demonstrate that the proposed scheme is provably secure under the random oracle model and satisfy the security requirements mentioned in Section 4.3.

6.1. Security Model

We define the formal security model for the proposed scheme through a game played between an adversary and a challenger . Let denote the ith instance of the participant , where denotes two participants: the mobile user and the server who are involved in the execution of the proposed scheme. In the game, can initiate a series of queries to , which can answer them as follows:(i): when sends a message , first checks whether is in the hash-list . If so, return the value. Otherwise, generates a random number and stores in the hash-list . After that, return to .(ii)ExtractUserID (): when sends a query with the user’s identity , generates a private key and stores in the user-list .(iii)ExtractServerID (): when sends a query with the server’s identity , generates a private key and stores in the server-list .(iv)Send (): when sends a query with a message , responds with the result by executing the proposed scheme. can start the proposed scheme by sending .(v)Reveal (): when sends this query, returns the session key of the ith instance.(vi)Corrupt (): when sends this query with the participant identity, returns the corresponding private key.(vii)Test (): can send this query only once. Upon receiving the query, flips a coin . If , returns the session key of ith instance. Otherwise, selects a random number and returns it.

After executing the aforementioned queries, output the guess in the test query phase. If , we say breaks the semantic security of the proposed scheme. The advantage that violates the authenticated key agreement (AKA) of this scheme is denoted by .

Definition 1. (AKA-security): we say an authentication scheme is AKA-security if is negligible for any polynomial adversary .
Let and denote the events that can violate authentication by forging a login message and authentication by forging a response message, respectively. The advantage that violates the mutual authentication of this scheme is denoted by .

Definition 2. (MA-security): we say an authentication scheme is MA-security if is negligible for any polynomial adversary .

6.2. Provable Security

We will prove that our proposed scheme is MA-security and AKA-security in the security model above.

Lemma 1. No polynomial adversary can forge a legal login message if the DL problem is difficult.

Proof. suppose the adversary can output a legal login message with non-negligible probability , then the challenger can solve the DL problem with non-negligible advantage.
Given a DL instance , the task of is to compute , where is unknown to . generates a random number , sets , and sends the system parameters to . will maintain seven hash-lists (i = 0, 1, 2, 3, 4, 5, 6), a mobile user list , and a server list . randomly chooses a user’s identity as the challenge identity and answers ’s queries as follows:(i): maintains the lists , which are initially empty. , firstly, checks whether exists in . If it does, returns to . Otherwise, generates a random number , stores in , and returns to .(ii)ExtractUserID (): maintains the mobile user list , which is initially empty. , firstly, checks whether exists in . If it does, returns to . Otherwise, executes the following steps:(a)If , randomly selects , and a random number as the output of fuzzy extractor. computes . Otherwise, sets and stores and in and , respectively, and returns to .(b)If , generates two random numbers , computes , sets , selects a random number as the output of fuzzy extractor, stores and in and , respectively, and returns to .(iii)ExtractServerID (): maintains the server list , which is initially empty. , firstly, checks whether is in . If it does, returns to . Otherwise, selects , computes , stores and in and , respectively, and then returns to .(iv)Send (): can send the following queries:(a)Send : when sends this query, , firstly, checks if holds. If it does, aborts the game. Otherwise, checks whether exists in . If not, executes the ExtractUserID query. After that, with the private key , generates a random number and calculates as described. stores in and returns to .(b)Send : when sends this query, checks whether exists in . If not, executes the ExtractServerID . After that, with the private key , computes and extracts . obtains from , verifies if holds. If not, rejects the message. Otherwise, generates a random number , computes as described, and returns it to . If , then successfully forges a legal login message.(c)Send : upon receiving this message, checks if holds with in . If not, rejects the message. Otherwise, authenticates .(v)Reveal (): upon receiving this message, returns the session key if is accepted. Otherwise, returns ‘’ to .(vi)Corrupt (): upon receiving the identity (or ), looks up (or ) and returns (or ) to .(vii)Test (): generates a random number with the same length of session key and returns it to .Suppose forges a legal login message with . By applying forking lemma, can generate another legal login message with the same input of the simulation and different hash oracle queries. Then, we can get the following equations:Based on equations (7) and (8), we have the following:By equations (8), is the answer of DL problem. The advantage that solves the DL problem is given below. Firstly, some events are defined as follows:(i): the simulation does not abort in any Send query.(ii): successfully forges a legal message.(iii): .Let and denote the number of queries and Send queries. Then, we have the following equations:By equation (9), the advantage that solves the DL problem is as follows:Thus, can solve the DL problem with non-negligible probability by playing the game with . It contradicts with the difficulty of DL problem. We conclude that no polynomial adversary can forge a legal login message with non-negligible probability.

Lemma 2. No polynomial adversary can forge a legal response message if the -mBIDH Problem is difficult.

Proof. suppose the adversary can forge a legal response message with non-negligible probability , then the challenger can solve the k-mBIDH problem with non-negligible advantage. Given a k-mBIDH instance, , the task of is to compute , where are unknown to and . sends the system parameters to . will maintain seven hash-lists (i = 0, 1, 2, 3, 4, 5, 6), a mobile user list , and a server list . chooses a random identity as the challenge identity.
(i = 0, 1, 2, 3, 4, 6), Reveal, Corrupt, and Test query are the same as those in the simulation of Lemma 1. , Extract, and Send query are executed as follows:(i)ExtractServerID (): maintains the server list , which is initially empty. , firstly, checks whether is in . If it is, returns to . Otherwise, executes the following steps:(a)If , selects and . stores and in and , respectively, and returns to .(b)If , sets , stores and in and , respectively, and returns to .(ii)ExtractUserID (): maintains the mobile user list , which is initially empty. , firstly, checks whether exists in . If it does, returns to . Otherwise, randomly selects and computes . sets and generates a random number as the output of fuzzy extractor. stores and in and , respectively, and returns to .(iii)Send (): can send the following queries:(a)Send : If ’s partner is , sets and calculates as described. Otherwise, looks up from and generates a legal login message as described.(b)Send : When sends this query, checks whether holds. If it does, aborts the game. Otherwise, behaves the operations as described.(c)Send : Upon receiving this message, checks if holds.If not, rejects the message. Otherwise, authenticates . If , it means that successfully forges a legal response message.
Suppose forges a legal response message with . In the game, must send query after recovering . Thus, must have executed the query with the message . We have the following:The advantage that solves the k-mBIDH Problem is given below. Some events are defined as follows:(i): the simulation does not abort.(ii): successfully forges a legal response message.(iii): .(iv): selects a correct tuple from .Let , , and denote the number of query and Send query. Then, we have the following equations:By equation (12), the advantage that solves the k-mBIDH Problem is as follows:Thus, can solve the k-mBIDH problem with non-negligible probability by playing the game with . It contradicts with the hardness of k-mBIDH problem. We conclude that no polynomial adversary can forge a legal response message with non-negligible probability.

Theorem 1. The proposed scheme is MA-security if the DL problem and k-mBIDH problem are hard.

Proof. Lemma 1 and 2 demonstrate that no polynomial adversary can forge a legal login message or response message if the DL problem and k-mBIDH problem are hard. In other words, the mobile user and the server can authenticate each other. Therefore, the proposed scheme is MA-security.

Theorem 2. The proposed scheme is AKA-security if CDH problem is hard.

Proof. suppose can guess correctly with non-negligible probability in the Test query, then can solve the CDH problem with non-negligible probability. Some events are defined as follows:(i): guesses the value of correctly.(ii): makes the Test query to the user.(iii): makes the Test query to the server.(iv): forges a legal login message between the user and server.Since the probability that can guess the value of correctly is at least , then we have . We can get the equations as follows:Then,The event and are equal. We can get the following:Then, the advantage that solves the CDH problem is as follows:The event means that impersonates the user and has , which is the solution of CDH problem. According to Lemma 1, is negligible. Then, we can get , which is non-negligible because is non-negligible. It means that can solve the CDH problem with non-negligible probability by playing the game with . It contradicts the difficulty of CDH problem. We conclude that no polynomial adversary can guess correctly, and the proposed scheme is AKA-security.

6.3. Security Requirement Analysis

We also show that the proposed scheme satisfies the security requirements described in Section 4.3.Single registration: According to the description of the proposed scheme, the trusted RC generates the registration information for users. Then, users can be authenticated by other healthcare service providers.No online registration center: According to the specification of the proposed scheme, RC is not involved in the mutual authentication.Mutual authentication: According to the proof of Lemma 1 and Lemma 2, we know that no polynomial adversary can forge a legal login message and response message. Thus, the user and the server can authenticate each other by the received message.User anonymity: Based on the description of the proposed scheme, the user identity is hidden in the login message , where . An adversary can extract only if he/she can get after solving the k-mBIDH problem. Besides, the registration recorded in the blockchain is hidden by the hash function .Untraceability: In the proposed scheme, random is generated in each new session to compute a new login message , where . Because of the randomness of , the adversary cannot find any relation among these login messages of different sessions and thus cannot trace the users’ behavior.Session key agreement: Based on the description of the proposed scheme, the user and the server will generate a session key for future secure communications. We know that no adversary can compute from and since the CDH problem is hard.Perfect forward secrecy: Assume that there is an adversary who gets the long-term private key of the user and the server and intercepts the exchange message of previous sessions. Then, the adversary cannot compute in even if he gets and from since the CDH problem is hard. Therefore, the adversary cannot generate previous session keys even if he knows both private keys of the user and server.Two-factor security with PUF: Assume that an adversary steals the mobile device and extracts the data by a side channel attack. He can guess the password , however, he cannot verify the correctness of the password without knowing the identity . He cannot get the response output of PUF without . Moreover, the adversary cannot be authenticated in his mobile device because of the uncloneability of PUF even if he knows the password. Thus, our proposed scheme can satisfy the two-factor security.Access control for data privacy: The proposed scheme provides access control in the authentication process. The common solution can be used to determine the access permission . The server can determine the access permission of the user efficiently without any other access control list to make data disclosure minimum. Besides, the common solution is associated with the RC’s private key , which means no adversary can forge the access permission message.Resistance of various attacks: To resist known attacks existing in the service system, the proposed scheme should resist known attacks.(i)Insider attack: An insider in the system only knows user identity but cannot verify the password or private key without . Thus, the proposed scheme can resist an insider attack.(ii)Stolen card attack: An adversary gets the user’s smart card and extracts the data . However, he cannot verify the password without the user’s identity. Therefore, the proposed scheme can withstand the stolen card attack.(iii)Offline password guessing attack: An adversary gets the user’s smart card and extracts the data . However, he cannot verify the password without the user’s identity. Therefore, the proposed scheme can resist the offline password guessing attack.(iv)Replay attack: According to the description of the proposed scheme, we use the timestamp to check the freshness. Besides, the user and the server will generate new random numbers in each session. Both of them can find the replay of a message by the validity of the received message.(v)User impersonation attack: Based on the proof of Lemma 1, we show that no adversary can forge a legal login message without the user’s private key. The server can check the validity of the login message.(vi)Server impersonation attack: Based on the proof of Lemma 2, we show that no adversary can forge a legal response message without server’s private key. The user can check the validity of the response message since the server will extract using its private key.(vii)Man-in-the-middle attack: According to Theorem 1, we conclude that our proposed scheme provides mutual authentication, which means no adversary can forge a legal message without knowing the private keys.(viii)Physical attack: No adversary can recreate the same PUF to authenticate the device since PUFs are almost impossible to clone. Besides, the response and helper data are kept a secret, and only is stored in the blockchain, which can resist the modeling attack.

6.4. Security Comparisons

We now compare our proposed scheme with other prior related schemes, namely those of Xiong et al. [34], Jia et al. [21], and Son et al. [6]. As shown in Table 4, [6, 21, 34] cannot provide two-factor security, in which PUF serves as one of the authentication factors. [21] cannot support access control in the authentication process. All of them cannot resist physical attacks and others. Therefore, our scheme can satisfy all the listed security requirements and have better security.

7. Performance Analysis

In this section, we discuss the computational and communication costs of the proposed scheme and other related schemes [6, 21, 34, 37].

We will directly use the parameters of Jia et al. [21] scheme for the comparison in Table 5. We do not consider the execution time of registration phases, since they are executed only once. We also focus on the communication costs in the registration phase. The size of the element in , , and is 1024, 1024, and 160 bits, respectively, denoted by . Suppose the output length of the hash function and user’s identity is 256 bits. The length of the timestamp and common solution is 32 bits.

The summary of computation and communication costs is shown in Tables 6, 7 and Figures 6, 7. The proposed scheme has a lower computation cost compared to that in the scheme [6, 34] on the mobile users’ side and [6, 21] on the server side. Besides, the proposed protocol has lower communication costs compared to those in [21]. Though the scheme [6, 34] has lower communication costs than ours, our scheme can be more efficient and meet more desirable security requirements.

We implement a software prototype based on Hyperledger Fabric 2.0 on a single machine running an Intel(R) Core(TM) i7-8700 CPU @ 3.20 GHz, 8 GB RAM, and Ubuntu 18.04 for 64 bits operations system. We deploy a test network that consists of three peer organizations and a single orderer organization with three ordering nodes in a single channel to simulate the healthcare provider servicers in certain areas. The block size is 100 transactions in a batch and the block timeout is 2s to wait before creating a batch. The raft consensus algorithm is used for agreement on the consistence of transactions across the network. The smart contracts written in Go are deployed over the network, which is shown in Algorithm 1 and 2. All transactions of uploading, query, and update are driven via Hyperledger Fabric gateway to evaluate the throughput (TPS) and latency as shown in Figures 8 and 9. The performance demonstrates that the maximum throughput is 310 TPS for uploading the transactions and 600 TPS for query and update. The average latency for all transactions increases as increased in the total transactions. There are lots of factors that will affect the performance of the framework, such as the choices of ledger database, endorsement policy, network configuration parameters, and so on.

8. Conclusion

In this paper, we proposed a user authentication scheme with access control based on CRT for multiserver architectures, which not only secures sensitive health data transmission but enhances data privacy. The highlight of our protocol is that the decent integration of blockchain and PUF can achieve secure data sharing across medical institutions and identify each device for further security in the telehealth environment. Security analysis shows that our proposed scheme meets all of the desirable requirements above. Moreover, the performance analysis demonstrated that this protocol has lower communication and computation costs.

Future research will focus on more flexible access control updates and the improvement of computational and communication efficiency for resource-limited devices. We will also explore a privacy-preserving data sharing mechanism based on the blockchain and the improvement of blockchain performance. In addition, there is no doubt that a centralized registration center is convenient and available but our protocol is susceptible to some common security flaws, such as single point of failure, distributed denial of service (DDoS) attacks, and register center compromised attacks. Decentralized blockchain technology to mitigate central registration center problems is also a significant direction.

Data Availability

The data that support the findings of this study are available from the corresponding author upon reasonable request.

Conflicts of Interest

The authors declare no conflicts of interest.

Acknowledgments

The work was supported by the National Key Research and Development Program of China (No. 2021YFA1000600), the Shandong Provincial Key Research and Development Program (Nos. 2021CXGC010107and 2020CXGC010107), the National Natural Science Foundation of China (Nos. 62172307, U21A20466, 61972294, and 61932016), the Blockchain Core Technology Strategic Research Program of Ministry of Education of China (No. 2020KJ010301), the Special Project on Science and Technology Program of Hubei Province (No. 2020AEA013), the Natural Science Foundation of Hubei Province (No. 2020CFA052), the Wuhan Municipal Science and Technology Project (No. 2020010601012187), and the Guangxi Key Laboratory of Trusted Software (No. kx202001).