# Provably Secure Crossdomain Multifactor Authentication Protocol for Wearable Health Monitoring Systems

Authors: Hui Zhang; Yuanyuan Qian; Qi Jiang
Journal: Wireless Communications and Mobile Computing
 (2020)

---

## 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.


---

## Body

## 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 Figure1). 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.Figure 1
System model of crossdomain cloud-assisted WHMSs.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 Section2, 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.


## 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 Section2, 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 Figure2), 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.Figure 2
The authentication model for multidomain WHMSs.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 Table1.Table 1
Symbols.
SymbolDescriptionUiThe doctorWDjThe wearable device of patientsMDiThe mobile device ofUiIDi, IDWDjThe identifier ofUi and WDjPWi, BIOiThe password and biometric template ofUiGen⋅, Rep⋅The generation and reproduction algorithm in a fuzzy extractortThe fault tolerance threshold used byRep⋅RTThe registration timestampTThe timestampΔTThe time thresholdh⋅The hash function⊕The exclusive or‖The concatenationAThe adversary


### 2.1. Initialization Phase

At this stage,MCSm and WCSk preshare the key KCSm,k. Each MCSmWCSk pair has a shared key and can be identified based on each other’s identity. A finite cyclic group G generated by a point P of a large prime n on the elliptic curve is selected by MCSm. It selects s as a private key, calculates the public key S=sP, and publishes it. WCSk stores its IDWCSk and the private key KWCSk in the database.


### 2.2. Wearable Device Registration Phase

The holder ofWDj performs the following steps (see Figure 3):
(a)
WDj issues the registration request to WCSk through the secure channel(b)
When receiving the registration request,WCSk selects an identity IDWDj for WDj and calculates the shared key KWCSk−WDj=hKWCSkIDWDjRTWDj. Then, WCSk stores IDWDj,KWCSk−WDj in its database. Finally, the message <IDWDj,KWCSk−WDj> is sent by WCSk to WDj via the secure channel(c)
WDj stores the parameters IDWDj,KWCSk−WDj in its memoryFigure 3
Wearable device registration phase.


### 2.3. Mobile Device Registration Phase

The holder ofMDi (i.e., Ui) performs the following steps (see Figure 4):
(a)
Ui selects IDi and PWi and enters BIOi (e.g., fingerprint) on the mobile device MDi. Then, Ui sends them to MCSm with the identity IDi through a secure channel(b)
Once the identityIDi of Ui is received, MCSm generates a key KMDi for this MDi and calculates temporal certificate TCi=hIDiKMDiRTMDi. MCSm stores IDi,KMDi in its database. Then, TCi is sent to MDi(c)
MDi continues the calculation of GenBIOi=σi,τi, where σi is the biometric key and τi is the reproduction parameter. Then, MDi calculates the fuzzy verifiers ei=hhIDiPWiσimodl and fi=TCi⊕hIDi∣σiPWi and stores the parameters Gen⋅,Rep⋅,τi,h⋅,ei,fi,l in its memoryFigure 4
Mobile device registration phase.


### 2.4. Login Phase

As shown in Figure5, Ui enters IDi, PWi, and BIOi′ (e.g., fingerprint). Then, MDi calculates σi′=RepBIOi′,τi and ei′=hhIDiPWiσimodl and checks if ei′=ei holds. If not, MDi interrupts the request. Otherwise, it selects the current timestamp T1 and calculates TCi′=fi⊕hIDiσi′PWi. It continues to generate a random number b∈Ζn∗ and then computes B=bP, C=bS=Cx,Cy, PIDWDj=Cy⊕IDWDj, PIDi=IDi⊕Cx, and M1=hIDiIDWDjTCi′T1Cx. MDi transmits a message <PIDi,PIDWDj,T1,M1,B> to MCSm.Figure 5
Login and authentication phase.


### 2.5. Authentication Phase

At this stage, the mutual authentication between the participants is realized, as shown in Figure5.
(a)
After receiving the message<PIDi,PIDWDj,T1,M1,B> of MDi, MCSm verifies T1 according to the equation T1′−T1≤ΔT. If the timestamp is valid, it continues to calculate C′=sB=Cx′,Cy′, IDi′=PIDi⊕Cx′, and IDWDj′=PIDWDj⊕Cy′. MCSm obtains the corresponding KMDi according to IDi′ and the table stored in its database and calculates TCi′′=hIDi′KMDiRTMDi and M1′=hIDi′IDWDj′TCi″T1Cx′ and checks if the equation M1=M1′ holds. If so, MDi is considered legal by MCSm. It continues to generate the current timestamp T2 and determines which WCSk to be requested as well as the corresponding share key KCSm,k according to IDWDj′. Then, MCSm calculates M2=hKCSm,kIDi′IDWDj′T2 and M3=IDi′,IDWDj′,IDMCSm,T2KCSm,k and sends <M2,M3,T2,IDMCSm> to WCSk(b)
WCSk receives the message <M2,M3,T2,IDMCSm> sent by MCSm, and WCSk checks the validity of the timestamp T2. If it is valid, WCSk gets the corresponding KCSm,k according to IDMCSm, decrypts M3 to obtain IDi′,IDWDj′,IDMCSm′ with KCSm,k, and then checks the equation IDMCSm′=IDMCSm. If it fails, the session is interrupted. Otherwise, it continues to calculate M2′=hKCSm,kIDi′IDWDj′T2 and verifies if M2′=M2 is true. If true, MCSm is considered legal by WCSk. WCSk obtains the responding key KWCSk−WDj according to IDWDj′, generates the current timestamp T3 and a temporary key KWDj, and calculates TicketWDj=IDi′,KWDj,lifetimeKWCSk−WDj, SKCSm,k=hKCSm,kT2T3, TKWDj=KWDj⊕SKCSm,k, and M4=hKCSm,kKWDjT3IDi′IDWDj′IDMCSmIDWCSkTicketWDj. It sends the message <TicketWDj,TKWDj,T3,M4> to MCSm(c)
After receiving<TicketWDj,TKWDj,T3,M4>, MCSm checks the freshness of T3. If the timestamp is valid, it continues to compute SKCSm,k=hKCSm,kT2T3, KWDj′=TKWDj⊕SKCSm,k, and M4′=hKCSm,kKWDj′T3IDi′IDWDj′IDMCSmIDWCSkTicketWDj and verifies if M4′=M4 holds. If true, WCSk is considered legal by MCSm. MCSm generates the current timestamp T4 and calculates M5=hTCi″IDi′IDWDj′T4CTicketWDj and TTKWDj=KWDj′⊕C. It sends a message <TicketWDj,TTKWDj,T4,M5> to MDi(d)
After<TicketWDj,TTKWDj,T4,M5> is received, MDi checks the freshness of T4 and calculates KWDj″=TTKWDj⊕C and M5′=hTCi′IDiIDWDjT4CTicketWDj. It checks if M5=M5′ is true. If established, MCSm is considered legal by MDi


### 2.6. Session Key Agreement Phase

At this stage, a session key is established betweenMDi and WDj, as shown in Figure 6.
(a)
MDi generates a timestamp T5, selects a random number b and computes B=bP and M6=hKWDj″T5, and transmits a message <TicketWDj,T5,M6,B> to WDj(b)
After accepting<TicketWDj,T5,M6,B>, WDj checks the freshness of the timestamp T5. So it obtains IDi,KWDj,lifetime by decrypting TicketWDj with key KWCSk−WDj and verifies the validity of TicketWDj. It continues to calculate M6′=hKWDjT5 and verifies if the equation M6′=M6 is true. If it fails, the session is interrupted. Otherwise, WDj treats MDi as legitimate. WDj generates the current T6, selects a random number d, and computes D=dP, M7=hKWDjT5T6IDiIDWDjdB, and SKMDi−WDj=hIDiIDWDjT6T5KWDjdB. Eventually, it sends <T6,M7,D> to MDi(c)
After receiving<T6,M7,D>, MDi calculates M7′=hKWDj″T5T6IDiIDWDjbD and then verifies if M7′=M7 holds. If not, the session is interrupted. Conversely, WDj is considered legal by MDi. Finally, it calculates the session key SKMDi−WDj=hIDiIDWDjT6T5KWDjbDFigure 6
Session key agreement phase.


### 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,Ui inputs identity IDi, password PWi0, and biometric BIOi0 on MDi. Then, MDi calculates σi0=RepBIOi0,τi and ei0=hhIDiPWi0σi0modl and checks if ei0=ei 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)
Ui enters a new password PWin and/or BIOin. Then, MDi calculates the relevant parameters GenBIOin=σin,τin, ein=hhIDiPWinσinmodl, and fin=TCi⊕hIDiσinPWin. Finally, Ui updates the original ei,fj,τi to ein,fjn,τin


### 2.8. Dynamic Smart Device Addition Phase

NewWDj and new MDi can be dynamically added at this phase.
(1)
First, add a new wearable device namedWDjnew. In essence, this process looks like the WDj initialization phase, so it just needs to register at WCSk:
(a)
WDjnew issues a registration request to WCSk through a secure channel(b)
After the registration request is received,WCSk selects an identity IDWDjnew for WDjnew and calculates the share key KWCSk−WDjnew=hKWCSkIDWDjnewRTWDjnew, in which RTWDjnew represents the timestamp when registering WDjnew. Then, WCSk stores IDWDjnew,KWCSk−WDjnew,RTWDjnew in its database. Finally, the message <IDWDjnew,KWCSk−WDjnew> is given to WDjnew by WCSk over the secure channel(c)
WDjnew stores the parameters IDWDjnew,KWCSk−WDjnew into their memory(2)
Secondly, add a new mobile device calledMDinew:
(a)
Ui selects IDinew and PWinew and enters BIOinew on the mobile device MDinew. Then, IDinew is sent to MCSm by Ui via a secure channel(b)
After receiving the identityIDinew of Ui, MCSm generates a key KMDinew for this MDinew and calculates TCinew=hIDinewKMDinewRTMDinew, in which RTMDinew represents the registration timestamp of MDinew. MCSm stores IDinew,KMDinew in its database. Then, TCinew is sent to MDinew(c)
After receiving the message,MDinew calculates GenBIOinew=σinew,τinew, where σinew is the biometric key and τinew is the common recovery parameter(d)
After the above process is completed,MDinew continues to calculate einew=hhIDinewPWinewσinewmodl and finew=TCinew⊕hIDinewσinewPWinew and stores the parameters Gen⋅,Rep⋅,τinew,h⋅,einew,finew,l in its memory


## 2.1. Initialization Phase

At this stage,MCSm and WCSk preshare the key KCSm,k. Each MCSmWCSk pair has a shared key and can be identified based on each other’s identity. A finite cyclic group G generated by a point P of a large prime n on the elliptic curve is selected by MCSm. It selects s as a private key, calculates the public key S=sP, and publishes it. WCSk stores its IDWCSk and the private key KWCSk in the database.


## 2.2. Wearable Device Registration Phase

The holder ofWDj performs the following steps (see Figure 3):
(a)
WDj issues the registration request to WCSk through the secure channel(b)
When receiving the registration request,WCSk selects an identity IDWDj for WDj and calculates the shared key KWCSk−WDj=hKWCSkIDWDjRTWDj. Then, WCSk stores IDWDj,KWCSk−WDj in its database. Finally, the message <IDWDj,KWCSk−WDj> is sent by WCSk to WDj via the secure channel(c)
WDj stores the parameters IDWDj,KWCSk−WDj in its memoryFigure 3
Wearable device registration phase.


## 2.3. Mobile Device Registration Phase

The holder ofMDi (i.e., Ui) performs the following steps (see Figure 4):
(a)
Ui selects IDi and PWi and enters BIOi (e.g., fingerprint) on the mobile device MDi. Then, Ui sends them to MCSm with the identity IDi through a secure channel(b)
Once the identityIDi of Ui is received, MCSm generates a key KMDi for this MDi and calculates temporal certificate TCi=hIDiKMDiRTMDi. MCSm stores IDi,KMDi in its database. Then, TCi is sent to MDi(c)
MDi continues the calculation of GenBIOi=σi,τi, where σi is the biometric key and τi is the reproduction parameter. Then, MDi calculates the fuzzy verifiers ei=hhIDiPWiσimodl and fi=TCi⊕hIDi∣σiPWi and stores the parameters Gen⋅,Rep⋅,τi,h⋅,ei,fi,l in its memoryFigure 4
Mobile device registration phase.


## 2.4. Login Phase

As shown in Figure5, Ui enters IDi, PWi, and BIOi′ (e.g., fingerprint). Then, MDi calculates σi′=RepBIOi′,τi and ei′=hhIDiPWiσimodl and checks if ei′=ei holds. If not, MDi interrupts the request. Otherwise, it selects the current timestamp T1 and calculates TCi′=fi⊕hIDiσi′PWi. It continues to generate a random number b∈Ζn∗ and then computes B=bP, C=bS=Cx,Cy, PIDWDj=Cy⊕IDWDj, PIDi=IDi⊕Cx, and M1=hIDiIDWDjTCi′T1Cx. MDi transmits a message <PIDi,PIDWDj,T1,M1,B> to MCSm.Figure 5
Login and authentication phase.


## 2.5. Authentication Phase

At this stage, the mutual authentication between the participants is realized, as shown in Figure5.
(a)
After receiving the message<PIDi,PIDWDj,T1,M1,B> of MDi, MCSm verifies T1 according to the equation T1′−T1≤ΔT. If the timestamp is valid, it continues to calculate C′=sB=Cx′,Cy′, IDi′=PIDi⊕Cx′, and IDWDj′=PIDWDj⊕Cy′. MCSm obtains the corresponding KMDi according to IDi′ and the table stored in its database and calculates TCi′′=hIDi′KMDiRTMDi and M1′=hIDi′IDWDj′TCi″T1Cx′ and checks if the equation M1=M1′ holds. If so, MDi is considered legal by MCSm. It continues to generate the current timestamp T2 and determines which WCSk to be requested as well as the corresponding share key KCSm,k according to IDWDj′. Then, MCSm calculates M2=hKCSm,kIDi′IDWDj′T2 and M3=IDi′,IDWDj′,IDMCSm,T2KCSm,k and sends <M2,M3,T2,IDMCSm> to WCSk(b)
WCSk receives the message <M2,M3,T2,IDMCSm> sent by MCSm, and WCSk checks the validity of the timestamp T2. If it is valid, WCSk gets the corresponding KCSm,k according to IDMCSm, decrypts M3 to obtain IDi′,IDWDj′,IDMCSm′ with KCSm,k, and then checks the equation IDMCSm′=IDMCSm. If it fails, the session is interrupted. Otherwise, it continues to calculate M2′=hKCSm,kIDi′IDWDj′T2 and verifies if M2′=M2 is true. If true, MCSm is considered legal by WCSk. WCSk obtains the responding key KWCSk−WDj according to IDWDj′, generates the current timestamp T3 and a temporary key KWDj, and calculates TicketWDj=IDi′,KWDj,lifetimeKWCSk−WDj, SKCSm,k=hKCSm,kT2T3, TKWDj=KWDj⊕SKCSm,k, and M4=hKCSm,kKWDjT3IDi′IDWDj′IDMCSmIDWCSkTicketWDj. It sends the message <TicketWDj,TKWDj,T3,M4> to MCSm(c)
After receiving<TicketWDj,TKWDj,T3,M4>, MCSm checks the freshness of T3. If the timestamp is valid, it continues to compute SKCSm,k=hKCSm,kT2T3, KWDj′=TKWDj⊕SKCSm,k, and M4′=hKCSm,kKWDj′T3IDi′IDWDj′IDMCSmIDWCSkTicketWDj and verifies if M4′=M4 holds. If true, WCSk is considered legal by MCSm. MCSm generates the current timestamp T4 and calculates M5=hTCi″IDi′IDWDj′T4CTicketWDj and TTKWDj=KWDj′⊕C. It sends a message <TicketWDj,TTKWDj,T4,M5> to MDi(d)
After<TicketWDj,TTKWDj,T4,M5> is received, MDi checks the freshness of T4 and calculates KWDj″=TTKWDj⊕C and M5′=hTCi′IDiIDWDjT4CTicketWDj. It checks if M5=M5′ is true. If established, MCSm is considered legal by MDi


## 2.6. Session Key Agreement Phase

At this stage, a session key is established betweenMDi and WDj, as shown in Figure 6.
(a)
MDi generates a timestamp T5, selects a random number b and computes B=bP and M6=hKWDj″T5, and transmits a message <TicketWDj,T5,M6,B> to WDj(b)
After accepting<TicketWDj,T5,M6,B>, WDj checks the freshness of the timestamp T5. So it obtains IDi,KWDj,lifetime by decrypting TicketWDj with key KWCSk−WDj and verifies the validity of TicketWDj. It continues to calculate M6′=hKWDjT5 and verifies if the equation M6′=M6 is true. If it fails, the session is interrupted. Otherwise, WDj treats MDi as legitimate. WDj generates the current T6, selects a random number d, and computes D=dP, M7=hKWDjT5T6IDiIDWDjdB, and SKMDi−WDj=hIDiIDWDjT6T5KWDjdB. Eventually, it sends <T6,M7,D> to MDi(c)
After receiving<T6,M7,D>, MDi calculates M7′=hKWDj″T5T6IDiIDWDjbD and then verifies if M7′=M7 holds. If not, the session is interrupted. Conversely, WDj is considered legal by MDi. Finally, it calculates the session key SKMDi−WDj=hIDiIDWDjT6T5KWDjbDFigure 6
Session key agreement phase.


## 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,Ui inputs identity IDi, password PWi0, and biometric BIOi0 on MDi. Then, MDi calculates σi0=RepBIOi0,τi and ei0=hhIDiPWi0σi0modl and checks if ei0=ei 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)
Ui enters a new password PWin and/or BIOin. Then, MDi calculates the relevant parameters GenBIOin=σin,τin, ein=hhIDiPWinσinmodl, and fin=TCi⊕hIDiσinPWin. Finally, Ui updates the original ei,fj,τi to ein,fjn,τin


## 2.8. Dynamic Smart Device Addition Phase

NewWDj and new MDi can be dynamically added at this phase.
(1)
First, add a new wearable device namedWDjnew. In essence, this process looks like the WDj initialization phase, so it just needs to register at WCSk:
(a)
WDjnew issues a registration request to WCSk through a secure channel(b)
After the registration request is received,WCSk selects an identity IDWDjnew for WDjnew and calculates the share key KWCSk−WDjnew=hKWCSkIDWDjnewRTWDjnew, in which RTWDjnew represents the timestamp when registering WDjnew. Then, WCSk stores IDWDjnew,KWCSk−WDjnew,RTWDjnew in its database. Finally, the message <IDWDjnew,KWCSk−WDjnew> is given to WDjnew by WCSk over the secure channel(c)
WDjnew stores the parameters IDWDjnew,KWCSk−WDjnew into their memory(2)
Secondly, add a new mobile device calledMDinew:
(a)
Ui selects IDinew and PWinew and enters BIOinew on the mobile device MDinew. Then, IDinew is sent to MCSm by Ui via a secure channel(b)
After receiving the identityIDinew of Ui, MCSm generates a key KMDinew for this MDinew and calculates TCinew=hIDinewKMDinewRTMDinew, in which RTMDinew represents the registration timestamp of MDinew. MCSm stores IDinew,KMDinew in its database. Then, TCinew is sent to MDinew(c)
After receiving the message,MDinew calculates GenBIOinew=σinew,τinew, where σinew is the biometric key and τinew is the common recovery parameter(d)
After the above process is completed,MDinew continues to calculate einew=hhIDinewPWinewσinewmodl and finew=TCinew⊕hIDinewσinewPWinew and stores the parameters Gen⋅,Rep⋅,τinew,h⋅,einew,finew,l 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,A 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 A can offline exhaust all elements of the Cartesian product Did×Dpw during the polynomial time, where Dpw and Did 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 A. However, it does not have the ability to obtain all authentication factors at the same time. The three cases are as follows:
(a)
A can get the doctor’s passwords and MDs(b)
A can get passwords and biometrics(c)
A can get MDs and biometricsHypothesis 5.
The adversaryA 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 ΠUi represent the ith session instance of the participant U, 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 ID of the former is the partner ID of the latter and vice versa, and (4) no other instance accepts the same session ID as both instances.Freshness. An instance is said to be “fresh” if and only if (1) the attacker did not send a Reveal 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:ExecuteΠMCSm,ΠMDi,ΠWCSk,ΠWDj. This query simulates passive eavesdropping attacks of A. For this query, the public-transmitted content of authentication instances executed between all participants will be obtained by A.SendΠUi,m. This oracle query simulates an active attack, and A sends the modified message to the instance ΠUi on behalf of another party. After the instance ΠUi receives the message, A will get a response message generated by the participant ΠUi. ΠUi can be a wearable device, a mobile device, and a cloud server in both domains.RevealΠUi. When the instance ΠUi 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 ⊥.CorruptΠUi. Through this query, A 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.TestΠUi. It can determine the security of the session key owned by the instance ΠUi. 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, A 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.A can only perform the Test query to fresh instances, and there are no restrictions on other queries. It is necessary for A to judge that the bit used by the simulator is 0 or 1 after the Test query. If it can guess the correct result, the attacker is considered to have succeeded in the semantic security of the protocol P and defined this successful event as Succ. The size of the dictionary space is D, and the advantage of the attacker to make this attack is defined as AdvP,DakeA=2PrSucc−1. An authentication protocol is called semantically secure, if and only if for all probability polynomial time attackers, they have the advantage AdvP,DakeA which is larger than kqsend/D that can be ignored, where qsend is the number of active attacks by A.


### 3.3. Security Proof

Theorem 1.
Suppose thatP is the proposed authentication protocol, Ep is an elliptic curve group, and A is a PPT adversary. AdvP,DakeA is the advantage for A to break the semantic security of the protocol P. A can execute at most qsend send queries and qexe queries of different instances in the longest time t, so we have
(1)AdvP,DakeA≤qsendD.Proof.
We use a series of mixed experimentsEx0,Ex1,Ex2,⋯,Ex7 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 AdviA be the advantage of the attacker in Exi and Δi denote the degree of distinction between Exi and Exi+1.
Ex0. This is a scheme under the random oracle model. According to the definition of the advantage of the previous attacker, we have
(2)AdvP,DakeA=Adv0A.
Ex1. In the hybrid experiment, we maintain a hash table H list to simulate all random oracles. When s is a string and wants to query Hs, the oracle first searches the H list for the corresponding record s,value. If found, the value corresponding to the record is returned. Conversely, the oracle produces a random bit string b∈0,1l, returns the value to the interrogator, and stores the record s,b in the hash table. Since the random oracle is perfectly simulated in polynomial time, the attacker cannot distinguish Ex0 from Ex1.
(3)Δ0=∣Adv1A−Adv0A∣≤neglκ.
Ex2. 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
(4)Δ1=∣Adv2A−Adv1A∣≤neglκ.
Ex3. 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 <M1,M2,M4,M5,M6,M7>. Ex2 and Ex3 are indistinguishable from A unless they provide valid information to end the game. Specifically, for the authentication message M1=hIDiIDWDjTCi′T1Cx, where TCi=hIDiKMDiRTMDi or TCi′=fi⊕hIDiσi′PWi in the case that no corruption request is made, σi′,PWi cannot be obtained or the key KMDi is unknown to the attacker, and the valid information M1 cannot be calculated, so the attacker has a negligible probability of success. So
(5)Δ2=∣Adv3A−Adv2A∣≤neglκ.
Ex4. Simulation of the active session has been changed in the experiment. For a SendMCSm,B,M1 query, if A does not corrupt the MD, while M1 is the valid verification message generated by A, then we only need to let A achieve the final victory of the game and stop the simulation game. If such events occur, the attacker can get the random number b when knowing B,P and generate the random number C, in which B=bP, b∈Ζn∗, and C=bS=Cx,Cy and the message M1 contains Cx. The probability of successful construction of the message M1 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
(6)Δ3=∣Adv4A−Adv3A∣≤neglκ.
Ex5. We continue to change the simulation of the active sessions during the experiment. If the attacker sends a RevealWCSk query to the WCS, it will get the session key SKCSm,k=hKCSm,kT2T3 between the WCS and the MCS and can also calculate the temporary key KWDj. However, in order to generate valid verification information M4, A needs to generate a valid TicketWDj. It is able for A to know the identity of TicketWDj and specify the lifetime according to the general rules, but A cannot get the key shared by WCS and WD in advance. If A can guess and get a valid TicketWDj, 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
(7)Δ4=∣Adv5A−Adv4A∣≤neglκ.
Ex6. We change the simulation rules of the activity sessions again in the experiment. Specifically, for message M5, assume that A previously obtained the value of S and B by eavesdropping, where B=bP, the random number b∈Ζn∗, but the probability of successfully forging bsP of the message M5 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
(8)Δ5=∣Adv6A−Adv5A∣≤neglκ.
Ex7. Finally, we change the simulation of the activity sessions in the experiment. During the session key agreement phase, an attacker may have previously obtained TicketWDj by eavesdropping. If A fakes the message <TicketWDj,T5,M6,B> and sends it to WDj, then we just need to let A win and terminate the simulation. However, it should be noted that KWDj is an unknown security parameter, so the probability that A can effectively generate this information is negligible. Based on the above, we have
(9)Δ6=∣Adv7A−Adv6A∣≤neglκ.
In the final experiment, there is no real password-related information in the session using theExecute query from A, so there is no advantage, and the active attack through the Send query is only
(10)AdvP,DakeA≤qsendD.


## 3.1. Adversary Model

We give the security model in this paper. It is assumed that the cryptographic primitives used are secure. That is,A 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 A can offline exhaust all elements of the Cartesian product Did×Dpw during the polynomial time, where Dpw and Did 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 A. However, it does not have the ability to obtain all authentication factors at the same time. The three cases are as follows:
(a)
A can get the doctor’s passwords and MDs(b)
A can get passwords and biometrics(c)
A can get MDs and biometricsHypothesis 5.
The adversaryA 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 ΠUi represent the ith session instance of the participant U, 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 ID of the former is the partner ID of the latter and vice versa, and (4) no other instance accepts the same session ID as both instances.Freshness. An instance is said to be “fresh” if and only if (1) the attacker did not send a Reveal 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:ExecuteΠMCSm,ΠMDi,ΠWCSk,ΠWDj. This query simulates passive eavesdropping attacks of A. For this query, the public-transmitted content of authentication instances executed between all participants will be obtained by A.SendΠUi,m. This oracle query simulates an active attack, and A sends the modified message to the instance ΠUi on behalf of another party. After the instance ΠUi receives the message, A will get a response message generated by the participant ΠUi. ΠUi can be a wearable device, a mobile device, and a cloud server in both domains.RevealΠUi. When the instance ΠUi 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 ⊥.CorruptΠUi. Through this query, A 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.TestΠUi. It can determine the security of the session key owned by the instance ΠUi. 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, A 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.A can only perform the Test query to fresh instances, and there are no restrictions on other queries. It is necessary for A to judge that the bit used by the simulator is 0 or 1 after the Test query. If it can guess the correct result, the attacker is considered to have succeeded in the semantic security of the protocol P and defined this successful event as Succ. The size of the dictionary space is D, and the advantage of the attacker to make this attack is defined as AdvP,DakeA=2PrSucc−1. An authentication protocol is called semantically secure, if and only if for all probability polynomial time attackers, they have the advantage AdvP,DakeA which is larger than kqsend/D that can be ignored, where qsend is the number of active attacks by A.


## 3.3. Security Proof

Theorem 1.
Suppose thatP is the proposed authentication protocol, Ep is an elliptic curve group, and A is a PPT adversary. AdvP,DakeA is the advantage for A to break the semantic security of the protocol P. A can execute at most qsend send queries and qexe queries of different instances in the longest time t, so we have
(1)AdvP,DakeA≤qsendD.Proof.
We use a series of mixed experimentsEx0,Ex1,Ex2,⋯,Ex7 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 AdviA be the advantage of the attacker in Exi and Δi denote the degree of distinction between Exi and Exi+1.
Ex0. This is a scheme under the random oracle model. According to the definition of the advantage of the previous attacker, we have
(2)AdvP,DakeA=Adv0A.
Ex1. In the hybrid experiment, we maintain a hash table H list to simulate all random oracles. When s is a string and wants to query Hs, the oracle first searches the H list for the corresponding record s,value. If found, the value corresponding to the record is returned. Conversely, the oracle produces a random bit string b∈0,1l, returns the value to the interrogator, and stores the record s,b in the hash table. Since the random oracle is perfectly simulated in polynomial time, the attacker cannot distinguish Ex0 from Ex1.
(3)Δ0=∣Adv1A−Adv0A∣≤neglκ.
Ex2. 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
(4)Δ1=∣Adv2A−Adv1A∣≤neglκ.
Ex3. 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 <M1,M2,M4,M5,M6,M7>. Ex2 and Ex3 are indistinguishable from A unless they provide valid information to end the game. Specifically, for the authentication message M1=hIDiIDWDjTCi′T1Cx, where TCi=hIDiKMDiRTMDi or TCi′=fi⊕hIDiσi′PWi in the case that no corruption request is made, σi′,PWi cannot be obtained or the key KMDi is unknown to the attacker, and the valid information M1 cannot be calculated, so the attacker has a negligible probability of success. So
(5)Δ2=∣Adv3A−Adv2A∣≤neglκ.
Ex4. Simulation of the active session has been changed in the experiment. For a SendMCSm,B,M1 query, if A does not corrupt the MD, while M1 is the valid verification message generated by A, then we only need to let A achieve the final victory of the game and stop the simulation game. If such events occur, the attacker can get the random number b when knowing B,P and generate the random number C, in which B=bP, b∈Ζn∗, and C=bS=Cx,Cy and the message M1 contains Cx. The probability of successful construction of the message M1 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
(6)Δ3=∣Adv4A−Adv3A∣≤neglκ.
Ex5. We continue to change the simulation of the active sessions during the experiment. If the attacker sends a RevealWCSk query to the WCS, it will get the session key SKCSm,k=hKCSm,kT2T3 between the WCS and the MCS and can also calculate the temporary key KWDj. However, in order to generate valid verification information M4, A needs to generate a valid TicketWDj. It is able for A to know the identity of TicketWDj and specify the lifetime according to the general rules, but A cannot get the key shared by WCS and WD in advance. If A can guess and get a valid TicketWDj, 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
(7)Δ4=∣Adv5A−Adv4A∣≤neglκ.
Ex6. We change the simulation rules of the activity sessions again in the experiment. Specifically, for message M5, assume that A previously obtained the value of S and B by eavesdropping, where B=bP, the random number b∈Ζn∗, but the probability of successfully forging bsP of the message M5 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
(8)Δ5=∣Adv6A−Adv5A∣≤neglκ.
Ex7. Finally, we change the simulation of the activity sessions in the experiment. During the session key agreement phase, an attacker may have previously obtained TicketWDj by eavesdropping. If A fakes the message <TicketWDj,T5,M6,B> and sends it to WDj, then we just need to let A win and terminate the simulation. However, it should be noted that KWDj is an unknown security parameter, so the probability that A can effectively generate this information is negligible. Based on the above, we have
(9)Δ6=∣Adv7A−Adv6A∣≤neglκ.
In the final experiment, there is no real password-related information in the session using theExecute query from A, so there is no advantage, and the active attack through the Send query is only
(10)AdvP,DakeA≤qsendD.


## 4. Informal Security Analysis

This section shows that our scheme can achieve many security attributes.


### 4.1. Preventing Stolen Mobile Device Attack

IfA has got a stolen or lost MDi, it can get the information Gen⋅,Rep⋅,τi,h⋅,ei,fi,l stored in MDi. First, the adversary A wants to correctly guess the doctor’s password PWi and needs to guess the password and verify the security parameters ei=hhIDiPWiσi′modl. According to the assumptions about the ability of the adversary given in this paper, A can get both identity IDi and biometric BIOi, but ei is a fuzzy verifier 24<l<28, so there are Did/l possible password alternatives. To get the only correct password, A has to identify it online, and this can be prevented by implementing a number-limiting strategy. On the other hand, A may also try to get a unique correct password by fi=TCi⊕hIDiσiPWi. However, TCi=hIDiKMDiRTMDi, and it is protected by the key KMDi, which is generated by MCSm for MDi. 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 thatA has eavesdropped all the information <PIDi,PIDWDj,T1,M1,B>, <M2,M3,T2,IDMCSm>, <TicketWDj,TKWDj,T3,M4>, <TicketWDj,TTKWDj,T4,M5,C>, <TicketWDj,T5,M6,B>, and <T6,M7,D> in the login phase, the authentication phase, and the session key negotiation phase. Then, A 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 thatA 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, ifA wants to modify the message <PIDi,PIDWDj,T1,M1,B> and the key to the parameter M1,B is to generate a random number b∈Ζn∗, A can randomly select b∈Ζn∗ and calculate B=bP, C=bS=Cx,Cy, PIDi=IDi⊕Cx, PIDWDj=IDWDj⊕Cy, and M1=hIDiIDWDjTCi′T1Cx. The message receiver will confirm whether the party is a legitimate one by verifying M1=M1′. Both of the messages TCi=fi⊕hIDiσiPWi and TCi=hIDiKMDiRTMDi of M1 are protected by a password or a key KMDi, so A cannot calculate TCi. It can be seen that A cannot replace the real message M1 with his fake message and gain the trust of the receiver as an intermediary. For the message <M2,M3,T2,IDMCSm> sent from MCSm to WCSk, A intercepts the message as an intermediary and replaces it with its own messages. It wants to pass the verification of WCSk and then needs to send the correct <M2,M3>. To calculate M2=hKCSm,kIDi′IDWDj′T2 and M3=IDi′,IDWDj′,IDMCSm,T2KCSm,k, it needs the shared key KCSm,k between WCSk and MCSm, but it cannot get the key. Therefore, it cannot generate the message <M2,M3>. Similarly, it does not correctly calculate TicketWDj, TKWDj, and M4 in the next message <TicketWDj,TKWDj,T3,M4>, because they are both protected by the keys KWCSk−WDj and KCSm,k. In the same way, A 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,Ui enters IDi, PWi, and BIOi′ on MDi. Then, MDi will calculate σi′=RepBIOi′,τi and ei=hhIDiPWiσi′modl. MDi verifies if ei′=ei 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 thatA intercepts all information <PIDi,PIDWDj,T1,M1,B>, <M2,M3,T2,IDMCSm>, <TicketWDj,TKWDj,T3,M4>, <TicketWDj,TTKWDj,T4,M5,C>, <TicketWDj,T5,M6,B>, and <T6,M7,D> 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 whenA knows these secret parameters can A obtain the identity information related to Ui, MDi, and WDj. Therefore, our protocol achieves anonymity [32, 33]. On the other hand, we can also find that these messages are dynamic. The pseudoidentity PIDi of users is different in each session, and b∈Ζn∗ 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 computeTCi′=fi⊕hIDiσi′PWi and M1=hIDiIDWDjTCi′T1Cx. So MDi can pass the authentication of MCSm successfully via checking the correctness of M1. Similarly, an adversary cannot calculate correct M5′=hTCi′IDiIDWDjT4CTicketWDj without knowing TC″. Since only MCSm knows the secret key s, it can compute the valid TC″. Thus, MDi can authenticate MCSm by verifying the correctness of M5. Thus, our protocol achieves mutual authentication between MDi and MCSm.In the communication betweenMCSm and WCSk, WCSk authenticates MCSm via checking the correctness of M2′=hKCSm,kIDi′IDWDj′T2, since only the legal MCSm stores the valid share key KCSm,k. Similarly, MCSm authenticates WCSk via checking the correctness of M4′=hKCSm,kKWDj′T3IDi′IDWDj′IDMCSmIDWCSkTicketWDj because only the valid WCSk processing the valid share key KCSm,k can decrypt M3 to obtain IDi′, IDWDj′, and IDMCSm′. Thus, MCSm and WCSk accomplish mutual authentication.


### 4.7. Known Key Security

It is assumed that the adversaryA has obtained the session key SKMDi−WDj=hIDiIDWDjT6T5KWDjbdP shared by MDi and WDj. However, because our protocol uses timestamps and each session includes a randomly chosen temporary key KWDj 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,Ui has long-term secrets PWi, BIOi, and ei=hhIDiPWiσi′modl, and when the long-term secrets of Ui are leaked, the previous session key SKMDi−WDj=hIDiIDWDjT6T5KWDjbdP will not be leaked. Because b and d are randomly selected, it is difficult to calculate bdP by bP and dP 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 Section2.7.


## 4.1. Preventing Stolen Mobile Device Attack

IfA has got a stolen or lost MDi, it can get the information Gen⋅,Rep⋅,τi,h⋅,ei,fi,l stored in MDi. First, the adversary A wants to correctly guess the doctor’s password PWi and needs to guess the password and verify the security parameters ei=hhIDiPWiσi′modl. According to the assumptions about the ability of the adversary given in this paper, A can get both identity IDi and biometric BIOi, but ei is a fuzzy verifier 24<l<28, so there are Did/l possible password alternatives. To get the only correct password, A has to identify it online, and this can be prevented by implementing a number-limiting strategy. On the other hand, A may also try to get a unique correct password by fi=TCi⊕hIDiσiPWi. However, TCi=hIDiKMDiRTMDi, and it is protected by the key KMDi, which is generated by MCSm for MDi. 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 thatA has eavesdropped all the information <PIDi,PIDWDj,T1,M1,B>, <M2,M3,T2,IDMCSm>, <TicketWDj,TKWDj,T3,M4>, <TicketWDj,TTKWDj,T4,M5,C>, <TicketWDj,T5,M6,B>, and <T6,M7,D> in the login phase, the authentication phase, and the session key negotiation phase. Then, A 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 thatA 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, ifA wants to modify the message <PIDi,PIDWDj,T1,M1,B> and the key to the parameter M1,B is to generate a random number b∈Ζn∗, A can randomly select b∈Ζn∗ and calculate B=bP, C=bS=Cx,Cy, PIDi=IDi⊕Cx, PIDWDj=IDWDj⊕Cy, and M1=hIDiIDWDjTCi′T1Cx. The message receiver will confirm whether the party is a legitimate one by verifying M1=M1′. Both of the messages TCi=fi⊕hIDiσiPWi and TCi=hIDiKMDiRTMDi of M1 are protected by a password or a key KMDi, so A cannot calculate TCi. It can be seen that A cannot replace the real message M1 with his fake message and gain the trust of the receiver as an intermediary. For the message <M2,M3,T2,IDMCSm> sent from MCSm to WCSk, A intercepts the message as an intermediary and replaces it with its own messages. It wants to pass the verification of WCSk and then needs to send the correct <M2,M3>. To calculate M2=hKCSm,kIDi′IDWDj′T2 and M3=IDi′,IDWDj′,IDMCSm,T2KCSm,k, it needs the shared key KCSm,k between WCSk and MCSm, but it cannot get the key. Therefore, it cannot generate the message <M2,M3>. Similarly, it does not correctly calculate TicketWDj, TKWDj, and M4 in the next message <TicketWDj,TKWDj,T3,M4>, because they are both protected by the keys KWCSk−WDj and KCSm,k. In the same way, A 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,Ui enters IDi, PWi, and BIOi′ on MDi. Then, MDi will calculate σi′=RepBIOi′,τi and ei=hhIDiPWiσi′modl. MDi verifies if ei′=ei 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 thatA intercepts all information <PIDi,PIDWDj,T1,M1,B>, <M2,M3,T2,IDMCSm>, <TicketWDj,TKWDj,T3,M4>, <TicketWDj,TTKWDj,T4,M5,C>, <TicketWDj,T5,M6,B>, and <T6,M7,D> 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 whenA knows these secret parameters can A obtain the identity information related to Ui, MDi, and WDj. Therefore, our protocol achieves anonymity [32, 33]. On the other hand, we can also find that these messages are dynamic. The pseudoidentity PIDi of users is different in each session, and b∈Ζn∗ 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 computeTCi′=fi⊕hIDiσi′PWi and M1=hIDiIDWDjTCi′T1Cx. So MDi can pass the authentication of MCSm successfully via checking the correctness of M1. Similarly, an adversary cannot calculate correct M5′=hTCi′IDiIDWDjT4CTicketWDj without knowing TC″. Since only MCSm knows the secret key s, it can compute the valid TC″. Thus, MDi can authenticate MCSm by verifying the correctness of M5. Thus, our protocol achieves mutual authentication between MDi and MCSm.In the communication betweenMCSm and WCSk, WCSk authenticates MCSm via checking the correctness of M2′=hKCSm,kIDi′IDWDj′T2, since only the legal MCSm stores the valid share key KCSm,k. Similarly, MCSm authenticates WCSk via checking the correctness of M4′=hKCSm,kKWDj′T3IDi′IDWDj′IDMCSmIDWCSkTicketWDj because only the valid WCSk processing the valid share key KCSm,k can decrypt M3 to obtain IDi′, IDWDj′, and IDMCSm′. Thus, MCSm and WCSk accomplish mutual authentication.


## 4.7. Known Key Security

It is assumed that the adversaryA has obtained the session key SKMDi−WDj=hIDiIDWDjT6T5KWDjbdP shared by MDi and WDj. However, because our protocol uses timestamps and each session includes a randomly chosen temporary key KWDj 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,Ui has long-term secrets PWi, BIOi, and ei=hhIDiPWiσi′modl, and when the long-term secrets of Ui are leaked, the previous session key SKMDi−WDj=hIDiIDWDjT6T5KWDjbdP will not be leaked. Because b and d are randomly selected, it is difficult to calculate bdP by bP and dP 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 Section2.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
Comparison of security attributes.
SchemesThe scheme in [34]The scheme in [35]Our schemePreventing stolen mobile device attack✕✕✓Preventing replay attack✓✓✓Preventing man-in-the-middle attack✓✓✓Efficient unauthorized login detection✓✓✓Anonymity and untraceability✓✓✓Mutual authentication✕✓✓Known key security✓✓✓Perfect forward secrecy✓✓✓Extensibility✓✓✓Efficient password and biometric update✓✓✓Table2 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.Ts: the time complexity of symmetric encryption and decryption (0.0214385 ms) [35].Tp: the time complexity of point multiplication operation of an elliptic curve (0.427576 ms) [35].Th: 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.Table 3
Efficiency comparison.
SchemesOur schemeThe scheme in [34]The scheme in [35]MDiUi8Th+Tp5Th+2Tp5Th+3TpMCSmCS6Th+3Tp+Ts2Th+3Tp4Th+TpWDj3Th+Ts2Th+2Tp4Th+TpWCSk3Th+2Ts——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.Table 4
Time-cost comparison (ms).
SchemesOur schemeThe scheme in [34]The scheme in [35]MDiUi0.42783840.85531601.2828920MCSmCS1.30436331.28279360.4277072WDj0.02153690.85521760.4277072WCSk0.0429754——Therefore, our scheme has better performance and meets a variety of common security demands, which is suitable for use in a wearable environment.


## 5.1. Security Comparison

The security comparison of our scheme with [34, 35] is shown in Table 2.Table 2
Comparison of security attributes.
SchemesThe scheme in [34]The scheme in [35]Our schemePreventing stolen mobile device attack✕✕✓Preventing replay attack✓✓✓Preventing man-in-the-middle attack✓✓✓Efficient unauthorized login detection✓✓✓Anonymity and untraceability✓✓✓Mutual authentication✕✓✓Known key security✓✓✓Perfect forward secrecy✓✓✓Extensibility✓✓✓Efficient password and biometric update✓✓✓Table2 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.Ts: the time complexity of symmetric encryption and decryption (0.0214385 ms) [35].Tp: the time complexity of point multiplication operation of an elliptic curve (0.427576 ms) [35].Th: 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.Table 3
Efficiency comparison.
SchemesOur schemeThe scheme in [34]The scheme in [35]MDiUi8Th+Tp5Th+2Tp5Th+3TpMCSmCS6Th+3Tp+Ts2Th+3Tp4Th+TpWDj3Th+Ts2Th+2Tp4Th+TpWCSk3Th+2Ts——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.Table 4
Time-cost comparison (ms).
SchemesOur schemeThe scheme in [34]The scheme in [35]MDiUi0.42783840.85531601.2828920MCSmCS1.30436331.28279360.4277072WDj0.02153690.85521760.4277072WCSk0.0429754——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.



---

*Source: 8818704-2020-09-24.xml*