A Secure and Efficient User Anonymity-Preserving Three-Factor Authentication Protocol for Large-Scale Distributed Wireless Sensor Networks

Abstract

Critical applications in wireless sensor network (WSN) are real-time based applications. Therefore, users are generally interested in accessing real-time information. This is possible, if the users (called the external parties) are allowed to access the real-time data directly from the sensor nodes inside WSN and not from the base station. The sensory information from nodes are gathered periodically by the base station and so, the gathered information may not be real-time. In order to get the real-time information from the sensor nodes, the user needs to be first authorized to the sensor nodes as well as the base station so that the illegal access to nodes do not happen. In this paper, we propose a novel three-factor user authentication scheme suited for distributed WSNs. Our scheme is light-weight, because it only requires the efficient cryptographic hash function, and symmetric key encryption and decryption operations. Further, our scheme is secure against different known attacks which are proved through the rigorous informal and formal security analysis. In addition, we simulate our scheme for the formal security verification using Automated Validation of Internet Security Protocols and Applications tool. The simulation results clearly demonstrate that our scheme is secure against passive and active adversaries.

1 Introduction

In a distributed wireless sensor network (DWSN) shown in Fig. 1, there is no fixed infrastructure and network topology is not known prior to deployment of the sensor nodes in a target field. Sensor nodes are usually deployed all over the target area randomly. After deployment sensor nodes form an infrastructure-less multi-hop wireless communication between them and data are routed back to the base station (BS). A base station collects sensor readings, performs costly operations on behalf of sensor nodes and manages the network. The base station is assumed to be trustworthy for WSN applications. The transmission between the sensors is done by short range radio communications. The base station is assumed to be computationally well-equipped whereas the sensor nodes are resource-starved.

Fig. 1

A distributed wireless sensor network (DWSN) architecture

Usually, the queries in WSN applications are issued at the point of the base station (BS) of the network. However, for critical applications of WSNs, such as military and healthcare applications, there is always a great need to access the real-time information from the sensors directly inside WSN, because the real-time data from the sensor nodes may no longer be accessed through the BS only. Thus, it is expected that the real-time data can be given access directly to the external parties (users) those who are authorized to access data as and when they demand. As a result, user authentication becomes a very important research area in WSN for providing access to real-time data inside WSN as and when an authorized user demands.

Recently, biometric-based user authentication schemes along with passwords have drawn considerable attention in research [13, 24, 25, 40]. Biometric-based user authentication in WSN becomes inherently more reliable and secure than usual traditional password-based user authentication schemes [24]. We have several advantages of using biometric keys (for example, fingerprints, faces, irises, hand geometry and palm-prints, etc.) over traditional passwords, which are listed below [24]:

• Biometric keys can not be lost or forgotten.

• Biometric keys are very difficult to copy or share.

• Biometric keys are extremely hard to forge or distribute.

• Biometric keys can not be guessed easily.

• Someone’s biometrics is not easy to break than others.

In this paper, we aim to propose a new three-factor user authentication scheme for DWSN. We show that our scheme is efficient and secure as compared to other existing schemes in WSNs.

According to Tan [34], we also extend the security requirements of two-factor authentication schemes to three-factor authentication schemes in WSNs, which are given below:

• Mutual authentication. After run of the protocol, a sensor node should believe that the user is a legitimate registered client. The user also believes that the communicating party is the sensor node which the user intended to login to.

• BS not knowing password and biometric. The BS should not have any information about the registered user’s password and personal biometric. This requirement is extremely required because several users may apply the same password to access different servers in the real-life applications. As a result, if a privileged insider of the registration center (in our scheme, it is the BS) knows the password or biometrics of a user, he/she may impersonate that user for accessing the services from other servers.

• Freedom of password and biometric update. A user should be allowed to change/ update freely and locally his/her password as well as biometric template without contacting the BS. The BS must be totally unaware of the change of the user’s password and biometric template.

• Three-factor security. In the security model for three-factor authentication scheme, an adversary can have full control over the communication channel between the users, the sensor nodes and the BS during the login phase, and the authentication and key agreement phase. In the three-factor security adversary model, the adversary is modeled to have at most two of the following three abilities, but it is not allowed to have all the three abilities. The adversary can extract the information from the lost or stolen smart card, obtain the password, or access the biometric template of a user.

1.1 Threat Model

We consider the threat model for designing our scheme similar to that in [13]. This model assumes the following:

• The base station (the GW-node) is assumed to be trustworthy and it will never be compromised by an adversary (attacker).

• An adversary can eavesdrop on all traffic, inject packets and reply old messages previously delivered.

• Sensors are not equipped with tamper-resistant hardware due to cost constraints. As a result, if an adversary physically captures a sensor from the target field, the adversary will know all the keying materials stored in that sensor’s memory.

• The smart card of a user is not tamper-resistant. Thus, if the smart card of a legal user is lost or stolen by an adversary, he/she will know all the sensitive information stored in that smart card.

• As in [13], we also use the well-known Dolev–Yao threat model in which any two parties communicate over an insecure (public) channel. We adopt the similar threat model in DWSN, where the channel is insecure and also the end-points (users and sensors) cannot in general be trustworthy.

1.2 Our Contributions

Our contributions are listed below:

• We propose a novel secure and efficient user authentication scheme suited for DWSN.

• Our scheme makes use of the user’s password and biometric information along with the non-tamper resistant smart card.

• Our scheme allows the user to change/update his/her password and personal biometric locally without further contacting the BS.

• Our scheme allows efficiently new node addition after initial deployment of the nodes in the target field.

• In our scheme, each deployed sensor node in the target field needs to store only one master key prior to its deployment, which enables our scheme for the minimum storage overhead for the resource-constrained sensor nodes.

• Our scheme is shown to be secure against various known attacks through both informal and formal security analysis.

• Our scheme is also secure against passive and active adversaries, which is shown through the simulation results using the widely-accepted Automated Validation of Internet Security Protocols and Applications (AVISPAs) tool.

• Finally, our scheme is efficient as compared to other existing schemes in the literature.

1.3 Roadmap of the Paper

The rest of the paper is organized as follows. We discuss some basic mathematical preliminaries needed for describing and analyzing our scheme in Sect. 2. In Sect. 3, we discuss the existing works on user authentication for WSNs in the literature. In Sect. 4, we propose a novel scheme for three-factor user authentication in DWSN. In Sect. 5, through the rigorous informal and formal security analysis we show that our scheme has the ability to defend various known attacks. Further, we simulate our scheme for formal security verification using the widely-accepted AVISPA tool in Sect. 6. In Sect. 7, we compare the performance of our scheme with other related existing approaches. Finally, we conclude the paper in Sect. 8.

2 Mathematical Background

In this section, we briefly discuss the properties of a one-way hash function and fuzzy extractor.

2.1 One-Way Hash Function

We define the formal definition of a one-way collision-resistant hash function as follows [14, 30, 33].

Definition 1

(Formal definition of one-way collision resistant hash function) A collision-resistant one-way hash function $h : X \rightarrow Y$, where $X = \{0, 1\}^*$ and $Y = \{0, 1\}^n$, is a deterministic algorithm that takes an input as an arbitrary length binary string $x \in X$ and produces an output $y \in Y$ as a binary string of fixed-length, $n$. If $Adv_{\mathcal {A}}^{HASH} (t_1)$ denotes an adversary (attacker) ${\mathcal {A}}$’s advantage in finding collision, we have

$$\begin{aligned} Adv_{\mathcal {A}}^{HASH} (t_1)&= Pr [(x, x') \Leftarrow _R {\mathcal {A}}: x \ne x' \, \hbox { and } \, h(x) = h(x')], \end{aligned}$$

where $Pr[E]$ denotes the probability of a random event $E$, and $(x, x') \Leftarrow _R {\mathcal {A}}$ denotes the pair $(x, x')$ is selected randomly by ${\mathcal {A}}$. In this case, the adversary ${\mathcal {A}}$ is allowed to be probabilistic and the probability in the advantage is computed over the random choices made by the adversary ${\mathcal {A}}$ with the execution time $t_1$. We call the hash function $h(\cdot )$ is collision-resistant, if $Adv_{\mathcal {A}}^{HASH} (t_1) \le \epsilon _1$, for any sufficiently small $\epsilon _1 > 0$.

2.2 Fuzzy Extractor

We briefly describe the extraction process of data key from the given biometric of a user using a fuzzy extractor method. It is known that the output of a conventional hash function $h(\cdot )$ is sensitive and it may also return completely different outputs even if there is a little variation in inputs [8]. The biometric information is thus prone to various noises during data acquisition, and as a result, the reproduction of actual biometric is hard in common practice. In order to avoid such problem, a fuzzy extractor [4, 19, 22] is used in the literature, which has the ability to extract a uniformly random string $\sigma$ and a public information $\tau$ from a given biometric template $B$ with the error tolerance $t$. In the reproduction process, the fuzzy extractor recovers the original biometric data key $\sigma$ for a noisy biometric $B^{\prime }$ using the public parameters $\tau$ and $t$. Let ${\mathcal {M}} = \{0, 1\}^{v}$ be a finite $v$-dimensional metric space of biometric data points, $d: {\mathcal {M}} \times {\mathcal {M}} \rightarrow {\mathbb {Z}}^{+}$ a distance function, which can be used to calculate the distance between two points based on the metric chosen, $l$ the number of bits of the output string $b_{i}$, and $t$ the error tolerance, where ${\mathbb {Z}}^{+}$ represents the set of all positive integers.

Definition 2

The fuzzy extractor is a tuple $({\mathcal {M}}, l, t)$, which is defined by the following two algorithms, called $Gen$ and $Rep$:

• Gen: It is a probabilistic algorithm, which takes a biometric information $B_{i} \in {\mathcal {M}}$ as input and outputs a secret data key $\sigma _{i} \in \{0, 1\}^{l}$ and a public reproduction parameter $\tau _{i}$. In other words, $Gen(B_{i}) = \{\sigma _{i}, \tau _{i}\}$.

• Rep: This deterministic algorithm takes a noisy biometric information $B_{i}^{\prime } \in {\mathcal {M}}$ and a public parameter $\tau _{i}$ related to $B_{i}$, and then it reproduces the biometric secret data key $\sigma _{i}$. In other words, $Rep(B_{i}^{\prime }, \tau _{i}) = \sigma _{i}$ provided that $d(B_{i},B_{i}^{\prime }) \le t$.

A detailed description of the fuzzy extractor and the extraction procedure can be found in [4, 19].

3 Related Work

Watro et al. [38] proposed a user authentication in WSNs, which is known as TinyPK. TinyPK uses the RSA algorithm [29] and Diffie-Hellman protocol [18]. As pointed out in [17], TinyPK has a security flaw as follows. On receiving the user’s public key, an attacker can encrypt a session key along with other parameters and then send the encrypted message to the user. Upon receiving the encrypted message, the user is forced to believe that the message has come from the legitimate sensor node. The user then decrypts the receiving encrypted message using his/her private key and also uses the session key for subsequent operations the attacker intends to perform. Wong et al. [39] proposed an efficient password-based user authentication scheme. However, their scheme is vulnerable to many logged in users with the same login-id and stolen-verifier attacks. M. L. Das’s scheme [17] eliminates the flaws of Wong et al.’s scheme. M. L. Das’s scheme is based on passwords. However, that scheme cannot also resist denial-of-service attack and node compromise attack. Some improvements on M. L. Das’s scheme [17] have been further proposed in [23, 26] in order to withstand security flaws found in that scheme.

He et al. [21] later proposed an enhancement on M. L. Das’s scheme [17]. Vaidya et al. [35] showed that M. L. Das’s scheme [17] and Khan–Alghathbar’s scheme [23] have security flaws and they are also vulnerable to various known attacks including stolen smart card attacks. To remedy such security weaknesses found in both schemes [17] and [23], Vaidya et al. suggested an improved two-factor user authentication in WSNs. Fan et al. [20] proposed a simple efficient and Denial-of-Service (DoS) resistant user authentication scheme for two-tiered WSNs. Chen and Shih [6] also pointed out that M. L. Das’s scheme [17] fails to achieve mutual authentication. To overcome such problem, they also proposed a robust mutual authentication protocol for WSNs. Das et al. [16] proposed a novel and efficient password-based user authentication scheme for the hierarchical wireless sensor networks. Their scheme was shown to be secure against various known attacks including the replay and man-in-the-middle attacks with the help of formal security verification [12]. Further, an improved version of Das et al.’s scheme [16] has been proposed in [37] in the literature.

Recently, biometric-based user authentication in WSNs has drawn a considerable research attention. Thus, the biometric-based user authentication in WSN becomes inherently more reliable and secure than usual traditional password-based user authentication schemes. Yuan et al.’s scheme [40] provides better security as compared to that for M. L. Das’s scheme [17] because the former scheme uses biometrics verification along with the password verification of the user. Yuan et al.’s scheme [40] has same drawbacks as in M. L. Das’s scheme [17], which does not resist denial-of-service attack and node compromise attack.

4 The Proposed scheme

In this section, we introduce a novel user authentication scheme suited for distributed wireless sensor networks. For describing and analyzing our scheme, we use the notations listed in Table 1.

Table 1 Notations used in this paper

The various phases of our scheme are described in detail in the following subsections.

4.1 Pre-deployment Phase

The purpose of this phase is to pre-load the keying materials to all sensor nodes prior to their deployment in the target field. This procedure is performed by the (key) setup server (in our scheme, it is the BS) in offline. The following steps are executed in this phase:

• Step PR1: The BS first assigns a unique identity $\textit{ID}_{\textit{SN}_j}$ for each deployed sensor node $\textit{SN}_j$ in the network.

• Step PR2: For each deployed sensor node $\textit{SN}_j$, the BS randomly generates a unique master key $MK_{\textit{SN}_j}$, which is also shared with the BS.

• Step PR3: Finally, the BS loads the following information into the memory of each deployed sensor node $\textit{SN}_j$: (i) its own identity, $\textit{ID}_{\textit{SN}_j}$ and (ii) its own master key $MK_{\textit{SN}_j}$.

Note that the BS knows the identities and master keys of all deployed sensor nodes. The BS is considered as trustworthy and thus, the BS will not reveal the keys to any adversary.

4.2 Post-deployment Phase

As soon as the sensor nodes $\textit{SN}_j$ are loaded with their keying materials in Sect. 4.1, they can be deployed in the target field. As describe in [9], after deployment each sensor node $\textit{SN}_j$ can broadcast a HELLO message containing its own identifier $\textit{ID}_{\textit{SN}_j}$ to the nodes in its communication range. Every node also receives HELLO message from its neighbor nodes. If $d$ is the average number of neighbor nodes of each sensor node $\textit{SN}_j$, it then prepares a list of its all $d$ neighbor nodes as $\textit{NL}_{\textit{SN}_j} =\{\textit{SN}_{j_1}, \textit{SN}_{j_2}, \ldots , \textit{SN}_{j_d} \}$. Once each sensor node $\textit{SN}_j$ finds its neighbors, they can communication each other with their neighbors and then to the BS via a multi-hop wireless communication path.

4.3 Registration Phase

In this phase, a legal user $U_i$ registers with the BS for accessing the real-time data from a particular sensor node $\textit{SN}_j$ inside DWSN. It consists of the following steps:

• Step R1: $U_i$ first inputs his/her chosen identity $\textit{ID}_i$, password $PW_i$, and then imprints the biometric $B_i$ at the sensor of a specific device. $U_i$ then generates a 1,024-bit random number $K$, which is kept secret to $U_i$ only. $U_i$ uses the fuzzy extractor function $Gen(\cdot )$ on input $B_i$ to produce the biometric data key $\sigma _i$ and the public parameter $\tau _i$ as $Gen(B_i) = (\sigma _i, \tau _i)$, where $\sigma _i$ is kept secret to $U_i$ only.

• Step R2: $U_i$ computes the masked password $\textit{RPW}_i$ as $RPW_i = h(\textit{ID}_i || K || \textit{PW}_i)$ and sends the registration request $\langle \textit{ID}_i, \textit{RPW}_i\rangle$ to the BS via a secure channel.

• Step R3: After receiving the request, the BS generates a 1,024-bit secret number $X_s$, which is only known to the BS. The BS computes $r_i = h(\textit{ID}_i || X_s)$, and issues a smart card, say $SC_i$ to the user $U_i$ containing the information $\{ r_i, h(\cdot ) \}$ via a secure channel.

• Step R4: After receiving the smart card $SC_i$ from the BS, the user $U_i$ computes

  $$\begin{aligned} e_i&= h(\textit{ID}_i || \sigma _i) \oplus K, \\ f_i&= h(\textit{ID}_i || RPW_i || \sigma _i), \, \hbox {and} \\ r_i^*&= r_i \oplus h(\textit{ID}_i || K) \\&= h(\textit{ID}_i || X_s) \oplus h(\textit{ID}_i || K). \end{aligned}$$

  Finally, $U_i$ replaces $r_i$ with $r_i^*$ in the smart card $SC_i$ and also stores the information $\{e_i, f_i, \tau _i, Gen(\cdot ),$ $Rep(\cdot ), t \}$ in the memory of $SC_i$.

The summary of the registration phase of our scheme is given in Table 2.

Table 2 Registration phase of our scheme

4.4 Login Phase

In this phase, if the user $U_i$ wants to access the real-time data from the sensor nodes inside DWSN, the following steps need to be executed:

• Step L1: The user $U_i$ first inserts his/her smart card $SC_i$ into the card reader of a specific terminal, and then inputs identity $\textit{ID}_i$, password $PW_i$, and also imprints the biometric $B_i^*$ at the sensor.

• Step L2: $SC_i$ computes

  $$\begin{aligned} \sigma _i^*&= Rep(B_i^*, \tau _i), \\ K^*&= h(\textit{ID}_i || \sigma _i^*) \oplus e_i, \\ \textit{RPW}_i^*&= h(\textit{ID}_i || K^* || PW_i), \\ f_i^*&= h(\textit{ID}_i || \textit{RPW}_i^* || \sigma _i^*). \end{aligned}$$

  $SC_i$ then checks the condition whether $f_i^* = f_i$. If it holds, it ensures that the user $U_i$ passes successfully both password and biometric verification. Otherwise, this phase is terminated immediately.

• Step L3: $SC_i$ further computes $M_1 = r_i^* \oplus h(\textit{ID}_i || K^*)$ $= h(\textit{ID}_i || X_s)$ and generates a random nonce $\textit{RN}_{U_i}$. $U_i$ selects a sensor-login node, say $\textit{SN}_j$ from which he/she wants to access the real-time data. $SC_i$ then computes

  $$\begin{aligned} M_2&= M_1 \oplus \textit{RN}_{U_i} \\&= h(\textit{ID}_i || X_s) \oplus \textit{RN}_{U_i},\\ M_3&= h(\textit{ID}_i || \textit{ID}_{\textit{SN}_j} || M_1 || \textit{RN}_{U_i} || T_1), \end{aligned}$$

  where $T_1$ is the current timestamp of $SC_i$’s system. $SC_i$ finally sends the login request $\langle \textit{ID}_{\textit{SN}_j}, M_2, M_3, T_1 \rangle$ to the BS via a public channel.

The login phase of our scheme is summarized in Table 3.

Table 3 Login phase of our scheme

4.5 Authentication and Key Agreement Phase

In this phase, the BS authenticates the user $U_i$ and also a sensor node $\textit{SN}_j$ authenticates $U_i$ before $U_i$ is given access to the real-time data from $\textit{SN}_j$ inside DWSN. At the end of successful mutual authentication, both the user $U_i$ and the sensor node $\textit{SN}_j$ establish a common session key between them. After receiving the login request $\langle \textit{ID}_{\textit{SN}_j}, M_2, M_3, T_1 \rangle$ from the user $U_i$ by the BS via a public channel, the following steps are executed:

• Step A1: The BS first checks the validity of $T_1$ in the message as follows. If the login request is received at time $T_2$, the BS checks the condition $|T_1 - T_2| < \varDelta T$, where $\varDelta T$ is the interval of the expected time for the transmission delay in DWSN. If it holds, the BS further checks $\textit{ID}_{\textit{SN}_j}$ of the sensor node $\textit{SN}_j$ from which the user $U_i$ is looking for accessing the real-time data. If it is valid, the BS computes

  $$\begin{aligned} M_4&= h(\textit{ID}_i || X_s),\\ M_5&= M_2 \oplus M_4 \\&= h(\textit{ID}_i || X_s) \oplus \textit{RN}_{U_i} \oplus h(\textit{ID}_i || X_s)\\&= \textit{RN}_{U_i}, \\ M_6&= h(\textit{ID}_i || \textit{ID}_{\textit{SN}_j} || M_4 || M_5 || T_1). \end{aligned}$$

  The BS then checks the condition $M_6 = M_3$. If it holds, the BS authenticates the user $U_i$ as a valid user and proceeds to next step. Otherwise, this phase is terminated immediately.

• Step A2: The BS computes $M_7 = E_{MK_{\textit{SN}_j}}[\textit{ID}_i, \textit{ID}_{\textit{SN}_j}, M_5, h(M_4), T_1, T_3]$ using the master key $MK_{\textit{SN}_j}$ of the sensor-login node $\textit{SN}_j$, and $T_3$ is the current timestamp of the BS. Finally, the BS sends the authentication request $\langle \textit{ID}_{\textit{SN}_j}, M_7 \rangle$ to the sensor-login node $\textit{SN}_j$ via a public channel.

• Step A3: Suppose the authentication request $\langle \textit{ID}_{\textit{SN}_j}, M_7 \rangle$ is received by the sensor $\textit{SN}_j$ at time $T_4$. $\textit{SN}_j$ decrypts $M_7$ using its own master key $MK_{\textit{SN}_j}$ in order to retrieve the information $\textit{ID}_i,$ $\textit{ID}_{\textit{SN}_j}, M_5, h(M_4), T_1,$ and $T_3$. $\textit{SN}_j$ then checks the validity of $\textit{ID}_{\textit{SN}_j}$, and also checks the condition $|T_3 - T_4| < \varDelta T$. If these conditions hold, the message is treated as a valid message and $U_i$ is considered as a valid user by $\textit{SN}_j$. Otherwise, this phase is terminated immediately.

• Step A4: $\textit{SN}_j$ generates a random nonce $\textit{RN}_{\textit{SN}_j}$. Further, $\textit{SN}_j$ computes the session key $SK_{ij}$ shared between the user $U_i$ and the sensor node $\textit{SN}_j$ as $SK_{ij} =$ $h(\textit{ID}_i || \textit{ID}_{\textit{SN}_j} || h(M_4) || M_5 || \textit{RN}_{\textit{SN}_j} || T_1 || T_5)$, where $T_5$ is the current timestamp of the sensor $\textit{SN}_j$. $\textit{SN}_j$ also computes

  $$\begin{aligned} M_8&= h(SK_{ij}), \\ M_9&= M_5 \oplus \textit{RN}_{\textit{SN}_j} \oplus \textit{ID}_i \\&= \textit{RN}_{U_i} \oplus \textit{RN}_{\textit{SN}_j} \oplus \textit{ID}_i. \end{aligned}$$

  $\textit{SN}_j$ then sends the authentication reply $\langle M_8, M_9, T_5 \rangle$ to the user $U_i$ via a public channel.

• Step A5: After receiving the authentication reply from $\textit{SN}_j$ in Step A4, the smart card $SC_i$ of the user $U_i$ first checks the validity of the timestamp $T_5$ attached with the message by the condition $|T_5 - T_6| < \varDelta T$, where $T_6$ is the time when the message is received by $SC_i$. If it is valid, $SC_i$ then computes

  $$\begin{aligned} M_{10}&= M_9 \oplus \textit{RN}_{U_i} \oplus \textit{ID}_i \\&= \textit{RN}_{\textit{SN}_j}, \\ SK_{ij}'&= h(\textit{ID}_i || \textit{ID}_{\textit{SN}_j} || h(M_1) || \textit{RN}_{U_i} || M_{10} || T_1 || T_5), \\ M_{11}&= h(SK_{ij}'). \end{aligned}$$

  $SC_i$ checks the condition $M_{11} = M_8$. If this verification passes, $U_i$ treats the sensor node $\textit{SN}_j$ as a legitimate sensor node. Otherwise, this phase is terminated immediately. Note that $SK_{ij} = SK_{ij}'$. Finally, $\textit{SN}_j$ stores $SK_{ij}$ and $SC_i (U_i)$ stores $SK_{ij}'$ as the secret session key shared between them for their future secure communication.

This phase is summarized in Table 4.

Table 4 Authentication and key agreement phase of our scheme

4.6 Password and Biometric Update Phase

In this phase, we describe the procedure of updating old password and biometric by a legal user $U_i$ locally without contacting the BS. This phase involves the following steps:

• Step PB1: $U_i$ first inserts his/her smart card $SC_i$ into the card reader of a specific terminal, and then inputs his/her identity $\textit{ID}_i$, old password $PW_i^{old}$ and also imprints the biometric $B_i^{old}$ at the sensor. $SC_i$ then computes

  $$\begin{aligned} \sigma _i^{old}&= Rep(B_i^{old}, \tau _i), \\ K^*&= h(\textit{ID}_i || \sigma _i^{old}) \oplus e_i, \\ \textit{RPW}_i^{old}&= h(\textit{ID}_i || K^* || PW_i^{old}), \\ f_i^{old}&= h(\textit{ID}_i || \textit{RPW}_i^{old} || \sigma _i^{old}). \end{aligned}$$

  If the condition $f_i^{old} = f_i$ is met, $SC_i$ then asks the user $U_i$ to input his/her chosen new password and biometric. Otherwise, this phase is terminated immediately.

• Step PB2: $U_i$ enters his/her new password $PW_i^{new}$ and imprints the new biometric $B_i^{new}$ at the sensor. $SC_i$ then computes

  $$\begin{aligned} (\sigma _i^{new}, \tau _i^{new})&= Gen(B_i^{new}), \\ e_i^{new}&= h(\textit{ID}_i || \sigma _i^{new}) \oplus h(\textit{ID}_i || K^*), \\ \textit{RPW}_i^{new}&= h(\textit{ID}_i || K^* || PW_i^{new}), \\ f_i^{new}&= h(\textit{ID}_i || \textit{RPW}_i^{new} || \sigma _i^{new}). \end{aligned}$$

  Finally, $SC_i$ updates $e_i, f_i,$ and $\tau _i$ with $e_i^{new}, f_i^{new},$ and $\tau _i^{new}$, respectively, in its memory.

4.7 Dynamic Node Addition Phase

Sometimes some deployed sensor nodes become faulty because these are power exhausted or compromised by an attacker. In either case, there is a need to deploy some fresh sensor nodes to the target field in order to continue the services in DWSN. This phase is very simple and executed in offline by the BS. For a new deployed sensor node $\textit{SN}_j^{new}$ in the target field, the BS assigns a unique identity $\textit{ID}_{\textit{SN}_j^{new}}$ and also generates a unique master key $MK_{\textit{SN}_j^{new}}$ randomly, which is different from all the master keys of deployed sensor nodes. Finally, the BS pre-loads $\textit{ID}_{\textit{SN}_j^{new}}$ and $MK_{\textit{SN}_j^{new}}$ in the memory of $\textit{SN}_j^{new}$ prior to its deployment in the target field. The BS also needs to inform the user $U_i$ about the addition of the new sensor node $\textit{SN}_j^{new}$ in the network so that $U_i$ can later access the real-time data from that node.

5 Security Analysis of the Proposed Scheme

In this section, through both informal and formal security analysis, we show that our scheme protects various known attacks.

5.1 Informal Security Analysis

The following subsections show that our scheme has the ability to tolerate various known attacks.

5.1.1 Stolen Smart Card Attack

Suppose the smart card $SC_i$ of a legal user $U_i$ is lost or stolen. Then an adversary can easily extract all the sensitive information $e_i, f_i,$ and $r_i^*$ from the lost/stolen smart card $SC_i$, where $e_i = h(\textit{ID}_i || \sigma _i) \oplus K$, $f_i = h(\textit{ID}_i || \textit{RPW}_i || \sigma _i)$, $r_i^* = r_i \oplus K$ $h(\textit{ID}_i || X_s) \oplus h(\textit{ID}_i || K)$, $K$ being a 1,024-bit secret number known to the user $U_i$ only, since the smart card in our scheme is not tamper-resistant. Note that $\textit{ID}_i$, $K$, $PW_i$ and $\sigma _i$ are unknown to the adversary. Due to collision-resistant property of the one-way hash function $h(\cdot )$, it is computationally infeasible to derive the password $PW_i$ and the biometric secret data key $\sigma _i$ (consequently, the biometric $B_i$) of the user $U_i$, and also the secret information $X_s$ of the BS. Thus, our scheme has the ability to prevent the stolen smart card attack.

5.1.2 Password and Biometric Change Attack

Assume that an adversary acquires the smart card $SC_i$ of a legal user $U_i$. Note that to update the new password and biometric, the adversary needs to know $\textit{ID}_i$ and $K$. Without these information, it is computationally infeasible task to compute $e_i^{new}$ $= h(\textit{ID}_i || \sigma _i^{new}) \oplus K$, $\textit{RPW}_i^{new}$ $= h(\textit{ID}_i || K || PW_i^{new})$, and $f_i^{new} =$ $h(\textit{ID}_i ||$ $\textit{RPW}_i^{new} || \sigma _i^{new})$, where $(\sigma _i^{new}, \tau _i^{new}) = Gen(B_i^{new})$, even if the adversary supplies his/her chosen password $PW_i^{new}$ and imprints a new biometric $B_i^{new}$ at the sensor. Due to collision-resistant property of $h(\cdot )$, the adversary has no feasible way to update password and biometric of the user $U_i$.

5.1.3 Replay Attack

In this attack, an adversary tries to pretend to be a valid/authorized user by logging to the BS by sending the messages which were previously delivered by a legal user $U_i$. Let the adversary intercept the login request $\langle \textit{ID}_{\textit{SN}_j}, M_2, M_3, T_1 \rangle$ during the login phase, where $M_1 = r_i^* \oplus h(\textit{ID}_i || K)$ $= h(\textit{ID}_i || X_s)$, $M_2 = h(\textit{ID}_i || X_s) \oplus \textit{RN}_{U_i}$, and $M_3 = h(\textit{ID}_i || \textit{ID}_{\textit{SN}_j} || M_1 || \textit{RN}_{U_i} || T_1)$. Assume that the adversary replies this login request to the BS. The BS can easily check the validity of this login request by means of checking the validity of $T_1$, the timestamp of $U_i$’s smart card, $SC_i$. If the verification fails, it ensures this login request is a replay one, and the BS will immediately reject it. As a result, our scheme protects the replay attack.

5.1.4 Man-in-the-Middle Attack

Suppose an adversary eavesdrops a valid login request $\langle \textit{ID}_{\textit{SN}_j}, M_2, M_3, T_1 \rangle$ during the login phase. In order to change $M_2$ and $M_3$, the adversary needs to know $M_1 = h(\textit{ID}_i || X_s)$ and $\textit{ID}_i$. Since both $\textit{ID}_i$ and $X_s$ are protected by a collision-resistant hash function $h(\cdot )$, it is a computationally infeasible task for the adversary to change $M_2$ and $M_3$ as $M_2' = h(\textit{ID}_i || X_s) \oplus \textit{RN}_{U_i}'$ and $M_3' = h(\textit{ID}_i || \textit{ID}_{\textit{SN}_j} || h(\textit{ID}_i || X_s) ||$ $\textit{RN}_{U_i}' || T_1')$, where $T_1'$ is the current timestamp of the adversary’s system, and $\textit{RN}_{U_i}'$ is the random nonce generated by the adversary. This clearly shows that the adversary does not have any ability to change or modify the login request $\langle \textit{ID}_{\textit{SN}_j}, M_2, M_3, T_1 \rangle$ to a fake login request $\langle \textit{ID}_{\textit{SN}_j}, M_2', M_3', T_1' \rangle$, and hence, our scheme prevents the man-in-the-middle attack.

5.1.5 Denial-of-Service Attack

In our scheme, the BS sends the authentication request $\langle \textit{ID}_{\textit{SN}_j}, M_7 \rangle$ to a sensor-login node $\textit{SN}_j$. In reply, $\textit{SN}_j$ sends the authentication reply $\langle M_8, M_9, T_5 \rangle$ to the user $U_i$. If an adversary blocks the messages from reaching $\textit{SN}_j$ and $U_i$, both $\textit{SN}_j$ and $U_i$ will know about malicious dropping of such control messages. On the other hand, if the adversary does the malicious flooding of the authentication requests to the sensor node $\textit{SN}_j$, it needs to perform only one symmetric decryption and two hash operations. Due to the computational efficiency of such operations, checking the authenticity of the malicious authentication requests does not occupy too much energy, memory as well as computational resources. Thus, we say that our scheme has also the ability to resist the denial-of-service attack.

5.1.6 Many Logged-in Users with the Same Login-ID Attack

In our scheme, the hash value of a user’s password $PW_i$ is embedded with his/her personal biometric data key $\sigma _i$ and the random number $K$ of $U_i$. As a result, even if two users $U_i$ and $U_j$ have the same password, say $PW$, the hash values $f_i = h(\textit{ID}_i || \textit{RPW}_i || \sigma _i)$ and $f_j = h(\textit{ID}_j || \textit{RPW}_j || \sigma _j)$ are also distinct, where $\textit{RPW}_i = h(\textit{ID}_i || K_1 || PW)$, $\textit{RPW}_j = h(\textit{ID}_j || K_2 || PW)$, $Gen(B_i) = (\sigma _i, \tau _i)$ and $Gen(B_j)$ $= (\sigma _j, \tau _j)$. Here $\textit{ID}_i$ and $\textit{ID}_j$ are the identities of $U_i$ and $U_j$ respectively, $K_1$ and $K_2$ are the secret random numbers of $U_i$ and $U_j$ respectively, and $B_i$ and $B_j$ are the biometrics of $U_i$ and $U_j$ respectively. Further, even if the password $PW$ is same for both $U_i$ and $U_j$, in order to login to the BS (network) they need to pass biometric verification. Hence, our scheme prevents the many logged-in users with the same login-id attack.

5.1.7 Privileged-Insider Attack

During the registration phase, an insider being an attacker at the BS may try to derive $PW_i$ and the biometric data key $\sigma _i$ of a legal user $U_i$. However, note that in our scheme the user $U_i$ sends the registration request $\langle \textit{ID}_i, \textit{RPW}_i \rangle$ to the BS securely, where $\textit{RPW}_i = h(\textit{ID}_i || K || PW_i)$. Since the 1,024-bit secret number $K$ and the password $PW_i$ are unknown to the insider attacker, it is a computationally infeasible to derive the password $PW_i$ due to the collision-resistant property of the one-way hash function $h(\cdot )$.

We also assume that a legal user $U_i$ is a malicious attacker. $U_i$ can extract the information $\{ e_i, f_i, r_i^*, \tau _i, Gen(\cdot ), Rep(\cdot ), t\}$ from his/her smart card. Then using his/her $\textit{ID}_i$ and $B_i$, $U_i$ can compute $\sigma _i =$ $Rep(B_i, \tau _i)$, $K =$ $h(\textit{ID}_i || \sigma _i) \oplus e_i$, and $h(\textit{ID}_i || X_s) =$ $r_i^* \oplus h(\textit{ID}_i || K)$. It can be noted that the BS’s master secret key $X_s$ can not be extracted within polynomial time from $h(\textit{ID}_i || X_s)$, since the probability of guessing $X_s$ is $\frac{1}{2^{k}}$, which is negligible, where $k$ is the bit-length of $X_s$ (in our scheme, $k = 1{,}024$). Hence, the proposed scheme is secure against privileged-insider attacker.

5.1.8 Protection of User Anonymity

Suppose an attacker intercepts the login request $\langle \textit{ID}_{\textit{SN}_j}, M_2, M_3, T_1 \rangle$ during the login phase, and the authentication request $\langle \textit{ID}_{\textit{SN}_j}, M_7 \rangle$ and the authentication reply $\langle M_8, M_9, T_5 \rangle$ during the authentication and key agreement phase. Note that these values are protected by the one-way collision-resistant hash function $h(\cdot )$ and also determined by two random nonces $\textit{RN}_{U_i}$ and $\textit{RN}_{\textit{SN}_j}$, and two timestamps $T_1$ and $T_5$. Due to this, these messages are different in each protocol run and as a result, the attacker does not have any ability to link two login messages of a particular user $U_i$. Hence, our scheme preserves the user anonymity property.

5.1.9 Session Key Security

Suppose an attacker intercepts the login request $\langle \textit{ID}_{\textit{SN}_j}, M_2, M_3, T_1 \rangle$ during the login phase, and the authentication request $\langle \textit{ID}_{\textit{SN}_j}, M_7 \rangle$ and the authentication reply $\langle M_8, M_9, T_5 \rangle$ during the authentication and key agreement phase. The secret session key $SK_{ij} =$ $h(\textit{ID}_i || \textit{ID}_{\textit{SN}_j} || h(M_4) || M_5 || \textit{RN}_{\textit{SN}_j} || T_1 || T_5)$ is embedded with $\textit{ID}_i$, $M_4 = h(\textit{ID}_i || X_S)$, $\textit{RN}_{U_i}$ and $\textit{RN}_{\textit{SN}_j}$, and also protected by the one-way hash function $h(\cdot )$. In order to compute $SK_{ij}$, an adversary needs to know $\textit{ID}_i$, $X_s$, $\textit{RN}_{U_i}$, and $\textit{RN}_{\textit{SN}_j}$. Due to the collision-resistant one-way property of $h(\cdot )$, it is a computationally infeasible problem for the attacker to derive $SK_{ij}$. Thus, our scheme provides the session key security.

5.1.10 Stolen-Verifier Attack

One of the interesting characteristics of our proposed scheme is that our scheme does not store any verifier/password table for verification. The insider of the network can not get/steal user’s password and biometrics because the BS and sensor nodes do not maintain any password/verifier table in order to validate user’s login request. Our scheme is then resilient against the stolen-verifier attack.

5.1.11 Three-Factor Security

As described in [34], in the three-factor security model the goals of adversary, who has learned at most two components of the triple $\{$password, smart card, biometric$\}$, are to mount an impersonation attack (as a legal user or the BS) in order to obtain the last component or to compromise the user anonymity. Note that our scheme preserves the user anonymity property which is shown in Sect. 5.1.8. Even if the user’s smart card is stolen, the adversary can not know $\textit{ID}_i$, $X_s$, $PW_i$, $\sigma _i$, which is evident from Sect. 5.1.1. In order to impersonate the adversary does not have any ability to modify the login request or authentication request/reply due to the collision-resistant property of $h(\cdot )$. Therefore, our scheme satisfies the three-factor security property.

5.1.12 Resilience Against Node Capture Attack

We measure the resilience against node capture attack of a user authentication scheme in WSN by estimating the fraction of total secure communications that are compromised by a capture of $c$ nodes not including the communication in which the compromised nodes are directly involved [16]. In other words, we need to find out the effect of $c$ sensor nodes being compromised on the rest of the network. For example, for any non-compromised sensor node $\textit{SN}_j$, we need to compute the probability that the adversary can decrypt the secure communication between a sensor-login node $\textit{SN}_j$ and a legal user $U_i$, when $c$ sensor nodes are already compromised in the network? If we denote this probability by $P_e(c)$, we call such a scheme is perfectly secure or unconditionally secure against node capture attack when $P_e(c) = 0$. Assume that an adversary physically captures a sensor node, say $\textit{SN}_j$ randomly in the target field from which the user $U_i$ accesses the real-time data from $\textit{SN}_j$. Since the sensor nodes are not equipped with tamper-resistant hardware, the adversary can easily compromise all the secret information including the captured sensor node’s master key and session key shared with the user $U_i$. The session key is generated using the random nonce $\textit{RN}_{U_i}$ and the timestamps of the user $U_i$ and the sensor node $\textit{SN}_j$, and thus each established session key between a user and a sensor node is distinct throughout the network. Also, each sensor node is loaded with a unique random master key prior to its deployment in the target field. As a result, the adversary has the ability to compromise the master key of that captured sensor node only. However, other non-compromised sensor nodes can still communicate securely with the actual real-time data to their corresponding legitimate users. The compromise of a sensor node does not reveal any other information about other sensor nodes and users in order to compromise any other secure communication between the users and the non-compromised nodes in the network. In other words, we have $P_e(c) = 0$. Hence, our scheme is unconditionally secure against node capture attack.

5.2 Formal Security Analysis

In this section, we show that our scheme is secure against an adversary using the formal security analysis under the random oracle model. We use the proof of the formal security by the method of contradiction as in [7]. We follow the similar analysis as in [11, 14, 15, 27, 28]. Note that one can also prove the formal security in the standard model. However, in this paper, we have performed the formal security analysis under the generic group model of cryptography.

In order to use the method of contradiction proof [7] for our formal security analysis, we assume that there exists the following oracle for an adversary:

• $Reveal:$ This oracle will unconditionally output the input string $x$ from the corresponding hash value $y = h(x)$.

Theorem 1

Under the assumption that a one-way hash function $h(\cdot )$ closely behaves like an oracle, our scheme is provably secure against an adversary for deriving the identity $\textit{ID}_i$ of a legal user $U_i$ and the secret information $X_s$ of the BS.

Proof

We follow the proof of this theorem similar to that in [11, 14, 15, 27, 28]. We need to construct an adversary ${\mathcal {A}}$ who will have the ability to derive the identity $\textit{ID}_i$ of a legal user $U_i$ and the secret information $X_s$ of the BS. The adversary ${\mathcal {A}}$ uses the $Reveal$ oracle in the experiment $EXP1_{\mathcal {A},UAS}^{HASH}$ provided in Algorithm 1 for our proposed secure and efficient user anonymity-preserving three-factor authentication scheme, say UAS. The success probability of $EXP1_{\mathcal {A},UAS}^{HASH}$ is defined by $Succ1$ $= |Pr[EXP1_{\mathcal {A},UAS}^{HASH} =1] - 1|$. The advantage function for this experiment becomes $Adv1$ $(et_1, q_{R}) = max_{\mathcal {A}}\{Succ1\}$, where the maximum is taken over all ${\mathcal {A}}$ with execution time $et_1$, and the number of queries $q_{R}$ made to the $Reveal$ oracle. Our scheme is provably secure against the adversary ${\mathcal {A}}$ for deriving the identity $\textit{ID}_i$ of a legal user $U_i$ and the secret information $X_s$ of the BS, if $Adv1 \le \epsilon$, for any sufficiently small $\epsilon > 0$. Consider the experiment $EXP1_{\mathcal {A},UAS}^{HASH}$ provided in Algorithm 1. According to this experiment, if the adversary ${\mathcal {A}}$ has the ability to invert a one-way hash function $h(\cdot )$, he/she can successfully derive the identity $\textit{ID}_i$ of a legal user $U_i$ and the secret information $X_s$ of the BS and win the game. However, by Definition 1, it is a computationally hard problem to invert $h(\cdot )$ due to collision-resistant property, that is, $Adv^{HASH}_{\mathcal {A}} (t) \le \epsilon _1$, for any sufficiently small $\epsilon _1 > 0$. As a result, $Adv1$ $(et_1, q_{R}) \le \epsilon$, since it is dependent on $Adv^{HASH}_{\mathcal {A}} (t)$. Hence, our scheme is provably secure against an adversary for deriving the identity $\textit{ID}_i$ of a legal user $U_i$ and the secret information $X_s$ of the BS. $\square$

Theorem 2

Under the assumption that a one-way hash function $h(\cdot )$ closely behaves like an oracle, our scheme is provably secure against an adversary for deriving the password $PW_i$ and the biometric data key $\sigma _i$ of a legal user $U_i$, and the secret information $X_s$ of the BS, even if the smart card $SC_i$ of $U_i$ is lost or stolen.

Proof

We follow the proof of this theorem similar to that in Theorem 1. We assume that the smart card $SC_i$ of a legal user $U_i$ is stolen or lost. An adversary ${\mathcal {A}}$ thus knows all the sensitive information stored in that smart card according to our threat model provided in Sect. 1.1. We construct the adversary ${\mathcal {A}}$ who will have the ability to derive the password $PW_i$ and the biometric key $\sigma _i$ of a legal user $U_i$, and the secret information $X_s$ of the BS. The adversary ${\mathcal {A}}$ uses the oracle $Reveal$ in the experiment $EXP2_{\mathcal {A},UAS}^{HASH}$ provided in Algorithm 2 for our proposed scheme, UAS. The success probability of $EXP2_{\mathcal {A},UAS}^{HASH}$ is given by $Succ2$ $= |Pr[EXP2_{\mathcal {A},UAS}^{HASH} =1] - 1|$. The advantage function for this experiment then becomes $Adv2$ $(et_2, q_{R}) = max_{\mathcal {A}}\{Succ2\}$, where the maximum is taken over all ${\mathcal {A}}$ with execution time $et_2$, and the number of queries $q_{R}$ made to the $Reveal$ oracle. Our scheme is called provably secure against the adversary ${\mathcal {A}}$ for deriving the the password $PW_i$ and the biometric data key $\sigma _i$ of a legal user $U_i$, and the secret information $X_s$ of the BS, if $Adv2 \le \epsilon$, for any sufficiently small $\epsilon > 0$. According to the experiment given in Algorithm 2, the adversary ${\mathcal {A}}$ can derive successfully $PW_i$, $\sigma _i$ and $X_s$, if he/she can invert a one-way hash function $h(\cdot )$ and in that case, he/she will win the game. However, by Definition 1, it is a computationally hard problem to invert $h(\cdot )$ due to collision-resistant property, that is, $Adv^{HASH}_{\mathcal {A}} (t) \le \epsilon _1$, for any sufficiently small $\epsilon _1 > 0$. We then have, $Adv2$ $(et_2, q_{R}) \le \epsilon$, since it is dependent on $Adv^{HASH}_{\mathcal {A}} (t)$. As a result, our scheme is also provably secure against an adversary for deriving $PW_i$, $\sigma _i$ and $X_s$. $\square$

6 Simulation for Formal Security Verification of the Proposed Scheme Using AVISPA Tool

In this section, we evaluate our scheme for the formal security verification using the widely-accepted AVISPA tool.

AVISPA is known as a push-button tool for the automated validation of Internet security-sensitive protocols and applications. AVISPA provides a modular and expressive formal language for specifying protocols and their security properties, and integrates different back-ends that implement a variety of state-of-the-art automatic analysis techniques [1]. We use the widely-accepted AVISPA tool for our formal security verification [5, 10, 11, 13, 14]. AVISPA implements four back-ends and abstraction-based methods that are integrated through the high level protocol specific language, known as HLPSL [36]. A static analysis is performed to check the executability of the protocol. The protocol along with the intruder actions are compiled into an intermediate format (IF). IF is the start point for the four automated protocol analysis techniques, which is a lower-level language than HLPSL and is read directly by the back-ends to the AVISPA tool. The first back-end, known as the On-the-fly Model-Checker (OFMC), does several symbolic techniques to explore the state space in a demand-driven way [3]. The second back-end, known as the CL-AtSe (Constraint-Logic-based Attack Searcher), provides a translation from any security protocol specification written as transition relation in intermediate format into a set of constraints which are effectively used to find whether there are attacks on protocols. The third back-end, known as the SAT-based Model-Checker (SATMC), builds a propositional formula which is then fed to a state-of-the-art SAT solver and any model found is translated back into an attack. Finally, the fourth back-end, known as TA4SP (Tree Automata based on Automatic Approximations for the Analysis of Security Protocols), approximates the intruder knowledge by using regular tree languages.

The output format (OF) of AVISPA is generated by using one of the four back-ends explained above. When the analysis of a protocol has been successful (by finding an attack or not), the output describes precisely what is the result, and under what conditions it has been obtained. In OF, there are the following sections.

• The first printed section SUMMARY indicates that whether the tested protocol is safe, unsafe, or whether the analysis is inconclusive.

• The second section, called DETAILS either explains under what condition the tested protocol is declared safe, or what conditions have been used for finding an attack, or finally why the analysis was inconclusive.

• Other sections such as PROTOCOL, GOAL and BACKEND are the name of the protocol, the goal of the analysis and the name of the back-end used, respectively.

• Finally, after some comments and statistics, the trace of an attack (if any) is also printed in the standard Alice-Bob format.

Fig. 2

Role specification in HLPSL for the user $U_i$ of our scheme

The basic types available in HLPSL are [1]:

• agent: Values of type agent represent principal names. The intruder is always assumed to have the special identifier $i$.

• public_key: These values represent agents’ public keys in a public-key cryptosystem. For example, given a public (respectively private) key $pk$, its inverse private (respectively public) key is obtained by $inv\_pk$.

• symmetric_key: Variables of this type represent keys for a symmetric-key cryptosystem.

• text: In HLPSL, text values are often used as nonces. These values can be used for messages. If $Na$ is of type text (fresh), then $Na'$ will be a fresh value which the intruder cannot guess.

• nat: The nat type represents the natural numbers in non-message contexts.

• const: This type represents constants.

• hash_func: The base type hash_func represents cryptographic hash functions. The base type function also represents functions on the space of messages. It is assumed that the intruder cannot invert hash functions (in essence, that they are one-way).

• bool: Boolean values are useful for modeling, for instance, binary flags.

The space of legal messages are defined as the closure of the basic types. For a given message Msg and encryption key key, we denote $\{Msg\}\_key$ as the symmetric/ public-key encryption. The associative “$\cdot$” operator is used for concatenations.

The “played_by A” declaration indicates that the agent named in variable $A$ will play in the role. A knowledge declaration (generally in the top-level Environment role) is used to specify the intruder’s initial knowledge. Immediate reaction transitions have the form $X =|> Y$, which relate an event $X$ and an action $Y$. This means that whenever we take a transition that is labeled in such a way as to make the event predicate $X$ true, we must immediately (that is, simultaneously) execute action $Y$. If a variable $V$ remains permanently secret, it is expressed by the goal secrecy_of V. If $V$ is ever obtained or derived by the intruder, a security violation will result.

6.1 Specifying our Scheme

We have implemented our proposed scheme in HLPSL language. In our implementation, we have three basic roles: alice, bs and bob, which represent the three participants: the user $U_i$, the base station BS and the sensor node $\textit{SN}_j$, respectively. We have further specified the session and environment in our implementation.

Fig. 3

Role specification in HLPSL for the BS of our scheme

Fig. 4

Role specification in HLPSL for the sensor node $\textit{SN}_j$ of our scheme

Fig. 5

Role specification in HLPSL for the session of our scheme

In Fig. 2, we have specified the role specification for the user $U_i$ of our scheme in HLPSL. During the registration phase, the user $U_i$ sends the registration request $\langle \textit{ID}_i, \textit{RPW}_i\rangle$ to the BS via a secure channel using the $Snd (\, )$ operation. Note that the type declaration $channel \,(dy)$ indicates that the channel is for the Dolev–Yao threat model. After that $U_i$ receives the smart card containing the information $\{r_i, h(\cdot )\}$ via a secure channel from the BS using the $Rcv (\, )$ operation. During the login phase, $U_i$ sends the login message $\langle \textit{ID}_{\textit{SN}_j}, M_2, M_3, T_1 \rangle$ to the BS. In HLPSL, secret(Xs, subs2, BS) declares that the secret information $X_s$ of the BS is permanently kept secret to the BS only characterized by the protocol id subs2. By the declaration witness(A, B, id, E), we mean it is for a (weak) authentication property of $A$ by $B$ on $E$, which declares that agent $A$ is witness for the information $E$; this goal will be identified by the constant $id$ in the goal section. This means that the agent named in variable $B$ has freshly generated the value $E$ for the agent named in variable $A$. The $id$ term is a new constant that identifies the message term upon which the goal should authenticate. On the other hand, request(B, A, id, E) indicates for a strong authentication property of $A$ by $B$ on $E$, declares that agent $B$ requests a check of the value $E$; this goal will be identified by the constant $id$ in the goal section. This formalizes $A$’s acceptance of the value $E$ as having generated for him/her by the agent named in $B$. During the authentication and key agreement phase, $U_i$ waits for the authentication reply $\langle M_8, M_9, T_5 \rangle$ from the sensor node $\textit{SN}_j$. authentication_on alice_server_rnui declares that $U_i$ $(SC_i)$ generates a random nonce $\textit{RN}_{U_i}$, where $\textit{RN}_{U_i}$ is only known to $U_i$. When the BS receives $\textit{RN}_{U_i}$ from other messages from $U_i$, the BS performs a strong authentication for $U_i$ based on $\textit{RN}_{U_i}$. In a similar way, the role specifications of the BS and the sensor node $\textit{SN}_j$ along with all the exchanged messages are shown in Figs. 3 and 4, respectively.

Fig. 6

Role specification in HLPSL for the goal and environment of our scheme

In Figs. 5 and 6, we have implemented the specifications in HLPSL language for the role of session and environment of our scheme, respectively. In the session segment, all the basic roles: alice, server and bob are instanced with concrete arguments. The top-level role (Environment) is always defined in HLPSL. This role contains global constants and a composition of one or more sessions, where the intruder may play some roles as legitimate user. The intruder, which is always denoted by $i$, also participates in the execution of protocol as a concrete session.

6.2 Analysis of Results

We have chosen the OFMC backend for an execution test and a bounded number of sessions model checking [3] for our simulation. For the replay attack checking, OFMC checks whether the legitimate agents can execute the specified protocol by performing a search of a passive intruder. After that this back-end provides the intruder the knowledge of some normal sessions between the legitimate agents. For the Dolev–Yao model check, this back-end also checks whether there is any man-in-the-middle attack possible by the intruder. We have simulated our scheme using the AVISPA web tool [2]. The simulation result for the formal security verification of our scheme using OFMC is shown in Fig. 7. In this figure, the first printed section, called the SUMMARY, indicates whether the protocol is safe, unsafe, or whether the analysis is inconclusive. It is clear that our scheme is safe from the printed SUMMARY section. DETAILS section explains under what condition the protocol is declared safe, or what conditions have been used for finding an attack, or finally why the analysis was inconclusive. It is also noted that our scheme is declared as safe, and no attack is found in our scheme. As a result, the result in this figure ensures that our scheme is secure against passive and active attacks including the replay and man-in-the-middle attacks.

Fig. 7

The result of the analysis using OFMC of our scheme

7 Performance Comparison with Related Schemes

In this section, we compare the performance of our scheme with other related existing schemes.

In Table 5, we have compared the functionalities of our scheme with other related schemes, such as Watro et al.’s scheme [38], Wong et al.’s scheme [39], M. L. Das’s scheme [17], Yuan et al.’s scheme [40], He et al.’s scheme [21], Vaidya et al.’s scheme [35], Fan et al.’s scheme [20] and Chen-Shih’s scheme [6]. From this table, it is clear that our scheme is superior with respect to all the functionality provided by our scheme such as preventing denial-of-service attack, supporting password and biometric update phase, mutual authentication and key agreement, non-repudiation because of employing the biometric of a user, user anonymity, three-factor security as well as formal security analysis and verification, when compared those functionalities with other related schemes.

Table 5 Functionality comparison between our scheme and other schemes

In Table 6, we have compared the computation cost of our scheme with other schemes during the registration phase, login phase, and authentication and key agreement phase. We have used the following notations for computing the computational costs of our scheme and other schemes: $t_{pu}$: public-key computation, $t_{pr}$: private-key computation, $t_h$: hash computation (SHA-1 [31]), $t_{enc}$: symmetric encryption (AES encryption [32]), $t_{dec}$: symmetric decryption (AES decryption [32]), $t_{fe}$: time for executing a fuzzy extractor function ($Gen(\cdot )$ and $Rep(\cdot )$). Note that during the registration phase, in our scheme a user $U_i$ and the BS require the computation costs $3t_h+t_{fe}$ and $t_h$, respectively, whereas no computation cost is involved during this phase for a resource-constrained sensor node $\textit{SN}_j$. During the login phase and the authentication and key agreement phase of our scheme, the computation costs for $U_i$, BS and $\textit{SN}_j$ are $7t_h + t_{fe}$, $2t_h+t_{enc}$ and $2t_h+t_{dec}$, respectively. Since the fuzzy extractor method is efficient, $U_i$ and the BS do not require much computation costs. On the other hand, due to efficiency of one-way hash function $h(\cdot )$ and symmetric encryption/decryption, the sensor node $\textit{SN}_j$ does not require much computation cost and as a result, our scheme is very suited for the resource-constrained sensor nodes.

The communication costs in terms of the number of exchanged messages and bits for a successful user authentication for our scheme and the other schemes are shown in Table 7. We have used the number of bits required for the following fields for computation of communication costs between our scheme and other schemes. The identifiers of sensor node, base station (GW-node) and user are each $16$ bits. The random nonce is $32$ bits. The timestamp field is $32$ bits. The public key encryption and decryption using RSA in Watro et al.’s scheme require each 1,024 bits. The AES encryption and decryption require each $128$ bits. If we use SHA-1 as the one-way hash function, the message digest is $160$ bits. From Table 7, it is clear that a successful user authentication process in our scheme requires $736$ bits, while Watro et al.’s scheme, Wong et al.’s scheme, M. L. Das’s scheme, Yuan et al.’s scheme, He et al.’s scheme, Vaidya et al.’s scheme, Fan et al.’s scheme and Chen-Shih’s scheme require 3,072, $608$, $704$, $704$, $736$, $944$, 1,232 and $944$ bits, respectively. Though our scheme requires little more communication overhead than Wong et al.’s scheme, M. L. Das’s scheme and Yuan et al.’s scheme, these schemes are insecure against some known attacks, which are discussed in Sect. 3.

Table 6 Comparison of computation costs in different phases between our scheme and other schemes

Table 7 Comparison of communication costs between our scheme and other schemes

Finally, we have compared the energy cost required for a sensor node among our scheme and other schemes in Table 8. Note that a sensor node’s energy cost is mainly due to both computation and communication costs involved in the schemes. For Watro et al.’s scheme, a sensor node consumes battery due to nonce validation, checksum generation and verification, two public-key operations and then response to the user’s query. In Wong et al.’s scheme, a sensor node consumes battery for a lookup table query, three hash operations for parameters generation and then waiting for the GW-node’s response before responding to the user’s query. In both M. L. Das’s scheme and Yuan et al.’s scheme, a sensor node consumes battery due to timestamp validation and one hash operation for parameter generation and finally for responding to the user’s query. In He et al.’s scheme, a sensor node consumes battery due to timestamp validation, one hash function for parameter generation and response to the user’s query. In Vaidya et al.’s scheme, battery consumption for a sensor node comes due to timestamp validation, one hash function for parameter generation, another hash function for parameter verification, and then response to the user’s query and waiting for the GW-node’s response. Fan et al’s scheme requires battery consumption for a sensor node due to one hash function for random-nonce validation, another hash function for session key generation and then response to the user’s query. Chen-Shih’s scheme involves battery consumption for a sensor node due to time-stamp validation, one hash function for parameter generation and response to the user’s query. Finally, in our scheme, a sensor node consumes battery due to one symmetric decryption, timestamp validation, two hash operations for session key generation and validation and response to the user’s query. Due to efficient hash and symmetric-key operations, a sensor node’s energy cost in our scheme is comparable with that for the other schemes.

Table 8 Comparison of sensor node’s energy cost between our scheme and other schemes

8 Conclusion

In this paper, we have addressed the user authentication problem by introducing a novel three-factor scheme for the resource-constrained DWSN. Our scheme supports efficiently updating password and biometric change phase without contacting the BS and dynamic node addition phase, which are considered as crucial factors in this area. Our scheme is shown to be secure against possible known attacks, which is evident through both informal and formal security analysis and verification. In addition, our scheme is very suited for resource-constrained sensor nodes due to the computation and communication efficiency as compared to those for other related schemes proposed in the literature. Overall, higher security along with low communication and computation costs make our scheme appropriate for practical WSN applications.