Abstract
Wearable health monitoring systems (WHMSs) have become the most effective and practical solutions to provide users with low-cost, noninvasive, long-term continuous health monitoring. Authentication is one of the key means to ensure physiological information security and privacy. Although numerous authentication protocols have been proposed, few of them cater to crossdomain WHMSs. In this paper, we present an efficient and provably secure crossdomain multifactor authentication protocol for WHMSs. First, we propose a ticket-based authentication model for multidomain WHMSs. Specifically, a mobile device of one domain can request a ticket from the cloud server of another domain with which wearable devices are registered and remotely access the wearable devices with the ticket. Secondly, we propose a crossdomain three-factor authentication scheme based on the above model. Only a doctor who can present all three factors can request a legitimate ticket and use it to access the wearable devices. Finally, a comprehensive security analysis of the proposed scheme is carried out. In particular, we give a provable security analysis in the random oracle model. The comparisons of security and efficiency with the related schemes demonstrate that the proposed scheme is secure and practical.
1. Introduction
The advance in technologies such as sensing devices and wireless communication has propelled the wide application of Internet of things in the medical field [1–3]. One of the typical applications is wearable health monitoring systems (WHMSs), which is an effective and practical solution to provide users with ubiquitous, low-cost, noninvasive, long-term continuous health monitoring.
In the classic WHMS model [4], there are three types of participants in a single security domain, i.e., wearable device (WD), cloud server (CS), and mobile device (MD). Typically, various WDs, such as smart bracelets and smart shoes worn on users, can send the collected data to CS via the MD held by the users through Bluetooth, Wi-Fi, or other wireless networks [5]. The CS, as a trusted entity, is mainly in charge of device registration and private information storage. A MD (such as a smartphone) connected to the Internet can access the WDs with the aid of CS.
To achieve ubiquity, it is impractical to deploy a single-domain WHMS which includes all entities. In this paper, we mainly focus on multidomain WHMSs (see Figure 1). Without loss of generality, we suppose that there are two different domains, i.e., D1 and D2. The patient in domain D1 has a variety of WDs for collecting physiological data, while in another domain D2, the doctor monitors the patient through the MD and analyzes the patient’s health data for medical treatment.
Although WHMSs bring great convenience to people, they also pose many security and privacy issues, such as sensitive personal information leakage and unauthorized access to device information [6]. Therefore, as one of the key means to fulfill data security and privacy protection [7], the authentication protocol is the focus of this paper.
To this end, numerous authentication protocols have been proposed in [8–10]. Most of them mainly concern a single domain where the wearable device collecting data and the mobile device accessing data held by the user are registered with the same server. However, in this paper, the two may be from two different domains. That is, few of them fit for multidomain WHMSs. Therefore, it is urgent to propose a multidomain authentication protocol for WHMSs.
1.1. Related Work
In order to resist malicious attacks on communication between wearable devices and smart devices, a number of authentication and key agreement (AKA) protocols for WHMSs have been put forward.
Kumar et al. [11] presented a two-factor authentication protocol based on a password and smart card (i.e., E-SAP), in which only symmetric key primitives are involved to achieve mutual authentication and key establishment. Li et al. [12] revealed that many previous schemes could not hide the user’s identity information during the login session phase. Therefore, in order to protect the privacy of user identity, the dynamic identity-based AKA scheme was proposed. Amin et al. [13] designed a two-way AKA protocol for a medical monitoring system to realize the anonymity of medical staff. However, Jiang et al. [14] analyzed Amin et al.’s scheme [13] and pointed out that it could not prevent mobile device stealing attacks and sensor key exposure. Once a smart device is stolen or lost, it may lead to sensitive data leakage in the device. In order to mitigate the above situation, the biometric is introduced as the third authentication factor, resulting in a large number of three-factor authentication protocols [15–18].
In recent years, the rapid development of cloud technology has made it possible to transfer computation and storage burdens of wearable devices to cloud servers, which greatly reduces the computation cost of deploying WHMSs. To this end, cloud-assisted AKA protocols are proposed.
In 2016, the yoking proof-based AKA protocol was proposed in [19], which is applied to the deployment of wearable devices with the aid of cloud servers. Specifically, local authentication is performed between the mobile device and two wearable devices, while remote authentication is performed by a cloud server. In the same year, a new asymmetric three-party authentication scheme for mutual authentication between wearable devices and mobile devices was proposed in [20]. But in [21], it is pointed out that one of the hypotheses in [19] is impractical; that is, a long-term key shared between the mobile devices and the wearable device is required before the protocol starts. In addition, in terms of security, the scheme in [19] is not resilient to desynchronization attacks. Moreover, it is also revealed in [20] that an out-of-band channel is needed in the authentication phase of the scheme in [21], while in general, it is assumed that a secure channel is only needed in the registration phase.
In 2017, Wu et al. [20] provided a cloud server-assisted AKA scheme for the wearable computing, which realizes mutual authentication and anonymity for the wearable device. In their scheme, the cloud server can be considered a trusted entity. In 2018, Srinivas et al. [22] proposed a novel cloud server-centric authentication scheme for medical surveillance systems, in which the cloud server acts as a relay in the authentication procedure between the users and wearable sensor nodes. Most recently, a cloud-centric three-factor AKA protocol was proposed in [23], which unifies three biometric encryption methods.
In a multidomain scenario, smart devices located in one security domain want to access wearable devices in another domain. In this direction, a multigateway authentication scheme is proposed for a wireless sensor network in [24]. However, the scheme is prone to lost smart card attack since it does not involve public key cryptographic primitives.
1.2. Our Contributions
For the security and privacy of personal private data in multidomain WHMSs [25], we design a crossdomain multifactor authentication protocol. Our contributions are summarized as follows.
Firstly, we propose a ticket-based authentication model for multidomain WHMSs. Specifically, a MD of a doctor and a WD are registered with MCS and WCS, respectively. The two CSs have established a trust relationship. The MD can request a ticket from MCS and remotely access the WD.
Secondly, we propose a crossdomain three-factor authentication scheme based on the above model. Only a doctor who can present all three factors can request a legal ticket which can be used to access the wearable devices. Moreover, both Elliptical Curve Cryptography (ECC) and fuzzy verifier [26] are introduced to avoid lost smart card attacks, and the Elliptic Curve Diffie-Hellman (ECDH) is employed to fulfill the strong confidentiality of the protocol.
Finally, we present the security and performance analysis of the proposed scheme. The provable security analysis under the random oracle model is given. By comparing its security and efficiency with the related schemes, the security and practicability of the scheme are demonstrated.
1.3. Organization of This Paper
The paper is organized as follows. In Section 2, we propose a crossdomain three-factor AKA scheme for WHMSs. The provable security analysis and informal security analysis are presented in Sections 3 and 4, respectively. Section 5 provides security analysis and efficiency comparison. The conclusion is given in Section 6.
2. The Proposed Protocol
In this paper, we are committed to a crossdomain scenario. Specifically, security domain D1 contains several WDs of a patient and the cloud server WCS, and security domain D2 contains the MD of a doctor and the cloud server MCS. The MD used by the doctor needs to access the WD that collects the patient’s physiological data in the case of remote diagnosis [27].
We provide an authentication model for multidomain WHMSs (see Figure 2), which achieves mutual authentication and key agreement between WD and MD from two different domains [28]. The details are as follows. First, the MD sends an access request to the MCS to which it belongs. The MCS sends a ticket request to the WCS, and then, WCS responds to the MCS with the ticket, which contains the secret information associated with the WD. After obtaining the ticket forwarded to the MD through the MCS, the MD can use it to initiate an access request to the WD, and WD will send a response message after the authentication from WD. Finally, the WD and the MD achieves mutual authentication and also negotiates the session key for the future communication.
We present a crossdomain three-factor authentication protocol which includes 8 stages, i.e., (1) initialization phase, (2) wearable device registration phase, (3) mobile device registration phase, (4) login phase, (5) authentication phase, (6) session key agreement phase, (7) password and biometric update phase, and (8) dynamic smart device addition phase. The symbols and their descriptions in the scheme are shown in Table 1.
2.1. Initialization Phase
At this stage, and preshare the key . Each pair has a shared key and can be identified based on each other’s identity. A finite cyclic group generated by a point of a large prime on the elliptic curve is selected by . It selects as a private key, calculates the public key , and publishes it. stores its and the private key in the database.
2.2. Wearable Device Registration Phase
The holder of performs the following steps (see Figure 3): (a) issues the registration request to through the secure channel(b)When receiving the registration request, selects an identity for and calculates the shared key . Then, stores in its database. Finally, the message is sent by to via the secure channel(c) stores the parameters in its memory
2.3. Mobile Device Registration Phase
The holder of (i.e., ) performs the following steps (see Figure 4): (a) selects and and enters (e.g., fingerprint) on the mobile device . Then, sends them to with the identity through a secure channel(b)Once the identity of is received, generates a key for this and calculates temporal certificate . stores in its database. Then, is sent to (c) continues the calculation of , where is the biometric key and is the reproduction parameter. Then, calculates the fuzzy verifiers and and stores the parameters in its memory
2.4. Login Phase
As shown in Figure 5, enters , , and (e.g., fingerprint). Then, calculates and and checks if holds. If not, interrupts the request. Otherwise, it selects the current timestamp and calculates . It continues to generate a random number and then computes , , , , and . transmits a message to .
2.5. Authentication Phase
At this stage, the mutual authentication between the participants is realized, as shown in Figure 5. (a)After receiving the message of , verifies according to the equation . If the timestamp is valid, it continues to calculate , , and . obtains the corresponding according to and the table stored in its database and calculates and and checks if the equation holds. If so, is considered legal by . It continues to generate the current timestamp and determines which to be requested as well as the corresponding share key according to . Then, calculates and and sends to (b) receives the message sent by , and checks the validity of the timestamp . If it is valid, gets the corresponding according to , decrypts to obtain with , and then checks the equation . If it fails, the session is interrupted. Otherwise, it continues to calculate and verifies if is true. If true, is considered legal by . obtains the responding key according to , generates the current timestamp and a temporary key , and calculates , , , and . It sends the message to (c)After receiving , checks the freshness of . If the timestamp is valid, it continues to compute , , and and verifies if holds. If true, is considered legal by . generates the current timestamp and calculates and . It sends a message to (d)After is received, checks the freshness of and calculates and . It checks if is true. If established, is considered legal by
2.6. Session Key Agreement Phase
At this stage, a session key is established between and , as shown in Figure 6. (a) generates a timestamp , selects a random number and computes and , and transmits a message to (b)After accepting , checks the freshness of the timestamp . So it obtains by decrypting with key and verifies the validity of . It continues to calculate and verifies if the equation is true. If it fails, the session is interrupted. Otherwise, treats as legitimate. generates the current , selects a random number , and computes , , and . Eventually, it sends to (c)After receiving , calculates and then verifies if holds. If not, the session is interrupted. Conversely, is considered legal by . Finally, it calculates the session key
2.7. Password and Biometric Update Phase
At this stage, the old password and biometric are updated with new ones. The details are as follows. (a)Firstly, inputs identity , password , and biometric on . Then, calculates and and checks if is true. If so, the previously entered information is considered valid and continues to enter the new password and biometrics that the doctor wants to update in the next step; otherwise, the session is terminated(b) enters a new password and/or . Then, calculates the relevant parameters , , and . Finally, updates the original to
2.8. Dynamic Smart Device Addition Phase
New and new can be dynamically added at this phase. (1)First, add a new wearable device named . In essence, this process looks like the initialization phase, so it just needs to register at : (a) issues a registration request to through a secure channel(b)After the registration request is received, selects an identity for and calculates the share key , in which represents the timestamp when registering . Then, stores in its database. Finally, the message is given to by over the secure channel(c) stores the parameters into their memory(2)Secondly, add a new mobile device called : (a) selects and and enters on the mobile device . Then, is sent to by via a secure channel(b)After receiving the identity of , generates a key for this and calculates , in which represents the registration timestamp of . stores in its database. Then, is sent to (c)After receiving the message, calculates , where is the biometric key and is the common recovery parameter(d)After the above process is completed, continues to calculate and and stores the parameters in its memory
3. Provable Security Analysis
3.1. Adversary Model
We give the security model in this paper. It is assumed that the cryptographic primitives used are secure. That is, is not capable of guessing the result of the hash functions, the random numbers, and the preshared keys of both parties used in the protocol.
Hypothesis 1. Communication channels are mainly divided into a private channel (i.e., a secure channel) and a public channel (i.e., an unsecure channel). For the public channel, we use the classic Dolev-Yao model [29], where an adversary can eavesdrop, intercept, delete, or modify any messages sent through the open channel. However, for a secure channel generally used in the registration phase, the adversary cannot obtain any information through this channel.
Hypothesis 2. According to [26], with the improvement of the attacker’s ability, the privacy information in a smart card can be obtained by power analysis attacks or by exploiting software vulnerabilities. Therefore, we assume in this paper that an adversary can resolve the confidential information after obtaining the smart card.
Hypothesis 3. As the adversary model proposed in [26], the adversary can offline exhaust all elements of the Cartesian product during the polynomial time, where and denotes the password space and the identity space, respectively.
Hypothesis 4. As the security model of the three-factor AKA protocol proposed in [30], any two of three authentication factors can be obtained by . However, it does not have the ability to obtain all authentication factors at the same time. The three cases are as follows: (a) can get the doctor’s passwords and MDs(b) can get passwords and biometrics(c) can get MDs and biometrics
Hypothesis 5. The adversary can get a session key established in the previous session.
3.2. Security Model
We explain the security model used by the security proof in this section. There are four main participants in this paper: WD, WCS, MD, and MCS.
Generally, the adversary of the authentication protocol is a probabilistic polynomial time adversary, who can control the transmission channel, passively eavesdropping or actively modifying or delaying messages [31].
Participants. Let represent the th session instance of the participant , also known as the oracle.
Status. There are generally three states: accept, reject, and invalid. It is in the “accept” state when the oracle receives the correct message. It is in the “reject” state when the oracle receives the error message; when the output has no answer, we use ⊥ to indicate the invalid result.
Partnering. Instances of two participants can become partners of each other if and only if (1) both instances are in the “accept” state and have the same session key, (2) both instances share the same identity, (3) the of the former is the partner of the latter and vice versa, and (4) no other instance accepts the same session as both instances.
Freshness. An instance is said to be “fresh” if and only if (1) the attacker did not send a query to this instance or its partner instance and (2) the attacker did not corrupt the instance before the instance is in the accept state.
Adversary. The ability of the adversary can be simulated by the following queries to oracles:
. This query simulates passive eavesdropping attacks of . For this query, the public-transmitted content of authentication instances executed between all participants will be obtained by .
. This oracle query simulates an active attack, and sends the modified message to the instance on behalf of another party. After the instance receives the message, will get a response message generated by the participant . can be a wearable device, a mobile device, and a cloud server in both domains.
. When the instance obtains a session key, the attacker has the ability to get the key. When an instance does not have a session key, the attacker gets an invalid flag ⊥.
. Through this query, can get secret credentials of corrupted participants, such as passwords, biometrics, and mobile devices. This query can simulate the forward security of the session key.
. It can determine the security of the session key owned by the instance . After the simulator receives this query, it will perform a flip coin operation. When the result is 1, the attacker returns a real session key; when the result is 0, the attacker returns a random key string with the same length as the key. In this case, must distinguish whether the returned value is a real session key or a random value, and the probability is 1/2.
We define the semantic security of the session key. can only perform the query to fresh instances, and there are no restrictions on other queries. It is necessary for to judge that the bit used by the simulator is 0 or 1 after the query. If it can guess the correct result, the attacker is considered to have succeeded in the semantic security of the protocol and defined this successful event as . The size of the dictionary space is , and the advantage of the attacker to make this attack is defined as . An authentication protocol is called semantically secure, if and only if for all probability polynomial time attackers, they have the advantage which is larger than that can be ignored, where is the number of active attacks by .
3.3. Security Proof
Theorem 1. Suppose that is the proposed authentication protocol, is an elliptic curve group, and is a PPT adversary. is the advantage for to break the semantic security of the protocol . can execute at most send queries and queries of different instances in the longest time , so we have
Proof. We use a series of mixed experiments to prove that the protocol is AKA secure. These experimental games start from a real attack scenario. Through continually changing some simulation rules in the experiments, we have the final experiment in which the attacker has little advantage in distinguishing between a session key and a random key of the same length. Let be the advantage of the attacker in and denote the degree of distinction between and .
. This is a scheme under the random oracle model. According to the definition of the advantage of the previous attacker, we have
. In the hybrid experiment, we maintain a hash table list to simulate all random oracles. When is a string and wants to query , the oracle first searches the list for the corresponding record . If found, the value corresponding to the record is returned. Conversely, the oracle produces a random bit string , returns the value to the interrogator, and stores the record in the hash table. Since the random oracle is perfectly simulated in polynomial time, the attacker cannot distinguish from .
. In the previous experiment, we have known that the oracle is perfectly simulated in polynomial time, so we exclude relatively unlikely hash collisions. When a collision occurs in the passive session or oracle simulation, then we will end the simulation of the entire game and believe that the attacker has won the game. Based on a birthday paradox, we have
. Simulation of the passive session has been changed in the experiment, considering the probability that the attacker would not make any random oracle query but can forge the authentication information . and are indistinguishable from unless they provide valid information to end the game. Specifically, for the authentication message , where or in the case that no corruption request is made, cannot be obtained or the key is unknown to the attacker, and the valid information cannot be calculated, so the attacker has a negligible probability of success. So
. Simulation of the active session has been changed in the experiment. For a query, if does not corrupt the MD, while is the valid verification message generated by , then we only need to let achieve the final victory of the game and stop the simulation game. If such events occur, the attacker can get the random number when knowing and generate the random number , in which , , and and the message contains . The probability of successful construction of the message described above is equal to the probability of solving the Elliptic Curve Discrete Logarithm Problem (ECDLP) in ECC. The ECDLP is a difficult problem in cryptography, so the probability of an attacker’s success is negligible. In short, we have
. We continue to change the simulation of the active sessions during the experiment. If the attacker sends a query to the WCS, it will get the session key between the WCS and the MCS and can also calculate the temporary key . However, in order to generate valid verification information , needs to generate a valid . It is able for to know the identity of and specify the according to the general rules, but cannot get the key shared by WCS and WD in advance. If can guess and get a valid , we terminate the simulation of the game and declare that the attacker has already won the game. The probability of such an event is negligible, so there will be
. We change the simulation rules of the activity sessions again in the experiment. Specifically, for message , assume that previously obtained the value of and by eavesdropping, where , the random number , but the probability of successfully forging of the message is actually equivalent to the probability of solving the Elliptical Curve Computational Diffie-Hellman Problem (ECCDHP). It is well known that ECCDHP is a difficult problem in cryptography, so the success probability of an attacker is negligible, so there are
. Finally, we change the simulation of the activity sessions in the experiment. During the session key agreement phase, an attacker may have previously obtained by eavesdropping. If fakes the message and sends it to , then we just need to let win and terminate the simulation. However, it should be noted that is an unknown security parameter, so the probability that can effectively generate this information is negligible. Based on the above, we have
In the final experiment, there is no real password-related information in the session using the query from , so there is no advantage, and the active attack through the query is only
4. Informal Security Analysis
This section shows that our scheme can achieve many security attributes.
4.1. Preventing Stolen Mobile Device Attack
If has got a stolen or lost , it can get the information stored in . First, the adversary wants to correctly guess the doctor’s password and needs to guess the password and verify the security parameters . According to the assumptions about the ability of the adversary given in this paper, can get both identity and biometric , but is a fuzzy verifier , so there are possible password alternatives. To get the only correct password, has to identify it online, and this can be prevented by implementing a number-limiting strategy. On the other hand, may also try to get a unique correct password by . However, , and it is protected by the key , which is generated by for . So, this method cannot be implemented. Therefore, it is found that the above two possible attack methods are not feasible; that is, our protocol can prevent such attack.
4.2. Preventing Replay Attack
Suppose that has eavesdropped all the information , , , , , and in the login phase, the authentication phase, and the session key negotiation phase. Then, replays them on the public channel, but it is intuitive to see that all of the messages we transmit contain the timestamp, which is the time when the message is sent. We use timestamps and random nonce in the protocol to guarantee the freshness of the transmitted information. If there is an adversary attempting to repeatedly send these messages, the existence of this situation will be found by verifying the validity of the timestamp. In addition, it is not feasible for an adversary to bypass the message recipient’s verification of the timestamp because all messages contain a key-protected hash value. Therefore, our protocol can prevent replay attacks.
4.3. Preventing Man-in-the-Middle Attack
It is assumed that is able to intercept the sent messages in the login phase, authentication phase, and key agreement phase and replace those messages with its own messages to perform the attack as a middleman.
Specifically, if wants to modify the message and the key to the parameter is to generate a random number , can randomly select and calculate , , , , and . The message receiver will confirm whether the party is a legitimate one by verifying . Both of the messages and of are protected by a password or a key , so cannot calculate . It can be seen that cannot replace the real message with his fake message and gain the trust of the receiver as an intermediary. For the message sent from to , intercepts the message as an intermediary and replaces it with its own messages. It wants to pass the verification of and then needs to send the correct . To calculate and , it needs the shared key between and , but it cannot get the key. Therefore, it cannot generate the message . Similarly, it does not correctly calculate , , and in the next message , because they are both protected by the keys and . In the same way, cannot generate other valid messages. Although the message is modified and sent to the intended recipient, it cannot be verified by the recipient. In short, our protocol can achieve mutual authentication among all participants. Therefore, the protocol can defend against man-in-the-middle attacks.
4.4. Efficient Unauthorized Login Detection
During protocol execution, unauthorized access should be detected in the login phase, and the session is terminated when the request is rejected. This not only saves unnecessary communication costs and calculation costs but also enables update operations such as password update. In the actual scenario, if the doctor enters an incorrect password, a detection mechanism in our protocol can verify the validity of the information provided by the doctor and provide timely feedback. The protocol is specifically implemented in this way, and we use a fuzzy extractor to verify the validity of the doctor’s biometrics. In the login phase of the protocol, enters , , and on . Then, will calculate and . verifies if holds. If not, the login request is rejected.
Therefore, our protocol can detect unauthorized login by user doctor’s error input or intentional attack by the attacker during the login phase.
4.5. Anonymity and Untraceability
We assume that intercepts all information , , , , , and transmitted on the public channel during the login phase, the authentication phase, and the session key negotiation phase.
It can be seen from all messages that they contain timestamps or nonces and are protected by their own keys or shared keys, thus ensuring confidentiality. Only when knows these secret parameters can obtain the identity information related to , , and . Therefore, our protocol achieves anonymity [32, 33]. On the other hand, we can also find that these messages are dynamic. The pseudoidentity of users is different in each session, and is randomly selected. Therefore, the message fields in each session are different, and the adversary cannot obtain useful information through different sessions, so untraceability is realized.
4.6. Mutual Authentication
In our protocol, only the legal patient processing the correct password and biometrics and the corresponding wearable device can compute and . So can pass the authentication of successfully via checking the correctness of . Similarly, an adversary cannot calculate correct without knowing . Since only knows the secret key , it can compute the valid . Thus, can authenticate by verifying the correctness of . Thus, our protocol achieves mutual authentication between and .
In the communication between and , authenticates via checking the correctness of , since only the legal stores the valid share key . Similarly, authenticates via checking the correctness of because only the valid processing the valid share key can decrypt to obtain , , and . Thus, and accomplish mutual authentication.
4.7. Known Key Security
It is assumed that the adversary has obtained the session key shared by and . However, because our protocol uses timestamps and each session includes a randomly chosen temporary key to guarantee that the session key of the current session is totally different from the previous session key, our protocol accomplishes known key security.
4.8. Perfect Forward Secrecy
In our scheme, has long-term secrets , , and , and when the long-term secrets of are leaked, the previous session key will not be leaked. Because and are randomly selected, it is difficult to calculate by and according to ECCDHP.
4.9. Extensibility
The protocol includes a mobile device or wearable device dynamic addition phase, so it can provide extensibility. Through this phase, we are able to dynamically add mobile devices or wearable devices, which only need to interact with the cloud servers of the security domain to which they belong. The cloud server maintains a table. Therefore, the protocol can provide the security features of extensibility.
4.10. Efficient Password and Biometric Update
Because of the efficient detection mechanism of unauthorized logins, doctors can freely update passwords or biometrics in our protocol, as shown in Section 2.7.
5. Security and Efficiency Comparison
5.1. Security Comparison
The security comparison of our scheme with [34, 35] is shown in Table 2.
Table 2 shows that the schemes in [34, 35] fail to meet all the security features listed in the table, such as inability to defend against MD stolen attacks. Our scheme can satisfy a number of security features, which has been proven in previous security analysis.
5.2. Efficiency Comparison
For efficiency, we mainly pay attention to the login, authentication, and session key agreement phases. The following symbols are used to define various calculations as well as their specific time consumption.
: the time complexity of symmetric encryption and decryption (0.0214385 ms) [35].
: the time complexity of point multiplication operation of an elliptic curve (0.427576 ms) [35].
: the time complexity of computing hash functions (0.0000328 ms) [35].
The efficiency comparison of our scheme with [34, 35] is shown in Table 3.
Our scheme has two cloud servers, and each domain has one cloud server. Different from our scheme in the number of participants, there is only one cloud server in schemes [34, 35]. Since the cloud server has stronger computing power and more resource [36], we only pay attention to the calculation of time consumption of mobile devices and wearable devices. As shown in Table 4, our scheme has obvious performance advantages.
Therefore, our scheme has better performance and meets a variety of common security demands, which is suitable for use in a wearable environment.
6. Conclusion
In practical WHMSs, single-domain authentication schemes can no longer meet the growing number of users and devices and crossdomain authentication schemes are urgently needed. In this paper, we proposed a ticket-based authentication model for multidomain WHMSs. Specifically, a mobile device of one domain can request a ticket from the cloud server of another domain with which wearable devices are registered and remotely access the wearable devices with the ticket. Then, we proposed a crossdomain three-factor authentication scheme based on the above model. Only a doctor who can present all three factors can request a legal ticket which can be used to access the wearable devices. Both the elliptical curve and fuzzy verifier are introduced to avoid lost smart card attack and to strengthen the confidentiality of the protocol. Finally, we presented the security and performance analysis of the proposed scheme. We carried out provable security analysis in a random oracle model and compared its security and efficiency with those of related schemes. The result shows the security and practicability of the proposed scheme.
Data Availability
The article contains data supporting the results of this study.
Conflicts of Interest
The authors claim that there is no conflict of interest.
Authors’ Contributions
All authors made equal contribution to the work.
Acknowledgments
This study was supported by the Research and Development Program for Science and Technology Department of Shaanxi Province (Program No. 2020NY-163), Research and Development Program for Science and Technology of Yulin (Program No. 2019-77-2), Young Elite Scientist Sponsorship Program of the Yulin Association for Science and Technology (Program No. 20190127), National Natural Science Foundation of China (Program No. 61672413), and Scientific Research Program Funded by the Education Department of Shaanxi Province (Program No. 20JY016).