A Lightweight Three-Factor Authentication and Key Agreement Scheme in Wireless Sensor Networks for Smart Homes.

A wireless sensor network (WSN) is used for a smart home system's backbone that monitors home environment and controls smart home devices to manage lighting, heating, security and surveillance. However, despite its convenience and potential benefits, there are concerns about various security threats that may infringe on privacy and threaten our home life. For protecting WSNs for smart homes from those threats, authentication and key agreement are basic security requirements. There have been a large number of proposed authentication and key agreement scheme for WSNs. In 2017, Jung et al. proposed an efficient and security enhanced anonymous authentication with key agreement scheme by employing biometrics information as the third authentication factor. They claimed that their scheme resists on various security attacks and satisfies basic security requirements. However, we have discovered that Jung et al.'s scheme possesses some security weaknesses. Their scheme cannot guarantee security of the secret key of gateway node and security of session key and protection against user tracking attack, information leakage attack, and user impersonation attack. In this paper, we describe how those security weaknesses occur and propose a lightweight three-factor authentication and key agreement scheme in WSNs for smart homes, as an improved version of Jung et al.'s scheme. We then present a detailed analysis of the security and performance of the proposed scheme and compare the analysis results with other related schemes.

1. Introduction

Wireless sensor networks (WSNs), composed of many low-cost and low-power sensor nodes, have become a popular technology for various applications including Internet of Things (IoT) applications such as health-care, smart homes, smart factoring, and smart city [1]. For example, a smart home is defined as a networking technology to integrate devices and appliances so that many smart home devices with sensors monitor home environments, capture users’ offline activities, and control lighting, windows, doors, heating, security and surveillance, and so on. In the smart home application, internal and external users need to directly access the WSN for real-time control and data acquisition will increase through direct access. According to Zion Market Research [2], the global smart home market was valued at USD 39.68 billion in 2017 and is expected to reach a value of USD 159.68 billion by 2023. The growing market for smart home provides a more comfortable and easier way of life to users while presenting new challenges for preserving privacy. Moreover, due to the inherent characteristics of WSNs, such as resource constraints and the use of wireless medium, they are likely to be exposed to various attacks. In such situations, cryptographic techniques such as encryption and message authentication should be applied to protect user privacy and WSN against various attacks. To apply cryptographic techniques, user authentication and key agreement are basically required.

1.1. Related Works

To improve security of WSNs, many user authentication and key agreement schemes have been proposed in the last decade [3,4,5,6,7,8,9,10,11,12,13,14]. In 2006, based on lightweight operations, such as XOR operations and one-way hash function, Wong et al. [3] proposed a lightweight strong-password authentication scheme for WSNs. However, Das [4] pointed out that Wong et al.’s scheme is vulnerable to same login identity attack, replay attack and stolen-verifier attack. Das then presented a two-factor authenticated key establishment scheme for WSNs as an improved version of Wong et al.’s scheme. Unfortunately, many papers [5,15,16,17,18] have revealed that Das’s scheme is vulnerable to various attacks such as privileged insider, gateway node bypass, smart card loss, and parallel session attacks.

Although many improved versions of Das’s scheme have been proposed to solve the above-mentioned security flaws, they still have some security problems. As one of the improved versions, Vaidya et al. [5] proposed a novel two-factor user authentication scheme with key agreement for WSNs, but in 2014, Kim et al. [6] pointed out that Vaidya et al.’s scheme could not withstand both user impersonation attack and gateway node bypass attack. Kim et al. then proposed a user authentication and key agreement scheme that resisted those attacks. In 2015, Chang et al. [8] found that Kim et al.’s scheme is vulnerable to impersonation, lost smart card, man-in-the-middle attacks and does not provide session key security and user privacy. Chang et al. then presented an enhanced two-factor authentication and key agreement using dynamic identities. However, recently, Park et al. [9] and Jung et al. [13] pointed out that Chang et al.’s scheme has security flaws such as off-line password guessing attack, user impersonation attack, perfect forward secrecy problem, and incorrectness of password change. Park et al. and Jung et al. then proposed improved schemes in 2016 and 2017, respectively. Park et al. proposed a three-factor user authentication and key agreement scheme using ECC (Elliptic Curve Cryptosystem) and Jung et al. proposed an efficient anonymous authentication with key agreement scheme using only lightweight operations. However, we found that Jung et al.’s scheme still has some security weaknesses [19].

On the other hand, user authentication and key agreement schemes based on the concept of IoT have been proposed. In 2014, Turkanović et al. [7] proposed an energy-efficient user authentication scheme with high security and low computational cost using the concept of the IoT. However, Farash et al. [10] found that Turkanović et al.’s scheme has security weaknesses and then proposed an improved scheme. In 2016, Amin et al. [11] claimed that Farash et al.’s scheme has some security problems such as known session-specific temporary information attack, off-line password guessing attack using a stolen-smart card, a new-smart card-issue attack, user impersonation attack, insecurity of the secret key of the gateway node, and insecurity of user anonymity. Amin et al. then proposed an anonymity-preserving three-factor authenticated key exchange scheme for IoT-based WSNs. Unfortunately, recently, Jiang et al. [12] found several security flaws in Amin et al.’s scheme, such as smart card loss attack, known session-specific temporary information attack, and tracking attack. Jiang et al. then proposed a lightweight three-factor authentication and key agreement scheme for Internet-integrated WSNs based on Rabin cryptosystem. Jiang et al.’s scheme provides various security features but this scheme is difficult to implement and deploy in practical applications because of heavyweight decryption of Rabin cryptosystem.

1.2. Research Contributions

As shown in the section on related works, most of the proposed user authentication and key agreement schemes for WSNs fail to provide adequate security protection or still suffer from various security attacks. To overcome these weaknesses, we design a lightweight authentication and key agreement scheme. Our research contributions are as follows.

We analyze the most recent three-factor authentication and key agreement scheme of Jung et al.’s scheme and present its security weaknesses. We show that Jung et al.’s scheme [13] does not provide strong anonymity and the secrecy of the secret key of the gateway node. We also show that Jung et al.’s scheme is vulnerable to a tracing attack, information leakage attack, session key recovery attack, and user impersonation attack.

We introduce a system model suitable for smart homes based on WSNs. Under this model, we propose a lightweight three-factor authentication and key agreement scheme as an improved version of Jung et al.’s scheme. The proposed scheme not only satisfies various security requirements but also uses lightweight operations, such as XOR and hash functions, which are very suitable for the resource constrained WSNs.

We formally prove the security of the proposed scheme using both random oracle model and BAN (Burrows-Abadi-Needham) logic. We then verify the proposed scheme on popular and robust security verification tool, AVISPA (Automated Validation of Internet Security Protocols and Applications).

Through informal security analysis, we show that the proposed scheme can satisfy the required security properties and withstand various attacks. We then compare it with other related schemes in terms of security features.

Through a performance evaluation, we compare the performance of the proposed scheme with other related schemes in terms of their computational cost and communication cost.

The remaining parts of this paper are as follows: Section 2 briefly reviews Jung et al.’s scheme; Section 3 demonstrates the security weaknesses of Jung et al.’s scheme; the details of the proposed scheme is illustrated in Section 4; Section 5 and Section 6 give the formal and informal security analysis of the proposed scheme, respectively; Section 7 shows the performance evaluation of the proposed scheme; Section 8 concludes the paper.

1.3. Preliminary

A conventional hash function may return different outputs even if there is little variation in the inputs because its output is sensitive [20]. On the other hand, since biometric information is prone to various noises during data acquisition, it is difficult to re-product actual biometric in common practice. A fuzzy extractor method has been used to solve these problems [20,21,22,23]. The fuzzy extractor can extract a uniformly-random string and a public information from the biometric template with a given error tolerance t. In other words, even if the input changes slightly, the fuzzy extractor could output the same random string with the help of the public information. The fuzzy extractor consists of the following two algorithms.

: Given a biometric template as an input, this probabilistic algorithm outputs a secret biometric key and a helper string .

: Given a noisy biometric and a helper string as inputs, this deterministic algorithm reproduces the biometric key .

2. Review of Jung et al.’s Scheme

In this section, we briefly review Jung et al.’s anonymous authentication with key agreement scheme in WSNs [13]. Jung et al.’s scheme consists of four phases: user registration, login, authentication, and password change. We describe the first three phases related to the security weaknesses in detail. Table 1 shows the notations used in Jung et al.’s scheme.

Table 1

Notations for Jung et al.’s scheme.

Notation	Description	Notation	Description
U_i	Remote user	u	Random number of U_i
S_j	Sensor node	R	Random number
GWN	Gateway node	K	Secret key generated by the GWN
ID_i,PW_i	Identity and password of U_i	K_S	Session key
Bio_i	Biometric information of U_i	f(v,k)	Pseudo-random function of variable v with key k
TID_i	Temporary identity of U_i’s next login	h(·),H(·)	One-way hash function and biohash function
SID_j	Identity of S_j	T,ΔT	Timestamp and the transmission delay time

Before a sensor node is deployed, it keeps and in its storage, where .

2.1. Registration Phase

In the registration phase, sends a request message for registration to then issues a smart card for . All messages in this phase are transmitted through a secure channel.

chooses , and a random number u and imprints his/her biometrics . computes and and sends a registration request to .

Upon receiving the registration request, computes and . then issues a smart card by storing in its memory and sends the smart card to .

Upon receiving the smart card, computes and additionally stores it into the smart card.

2.2. Login Phase

In the login phase, sends the service request to using his/her smart card, identity, password, and biometric information.

inserts own smart card into a terminal, enters and , and imprints .

The smart card computes , and . The smart card then checks whether matches with the received . If it does not hold, the smart card terminates this phase. Otherwise, the smart card confirms the legitimacy of and computes and .

The smart card sends the login request to through a public channel.

2.3. Authentication Phase

The authentication phase begins when receives the login request from . In this phase, , and authenticate each other and establish a session key .

checks the validity of and computes and . then checks whether matches with the received . If it does not hold, it terminates this phase. Otherwise, believes that is authentic and proceeds with the next step.

chooses a random number R and computes and . then sends the message to through a public channel.

Upon receiving the message, checks the validity of and computes and . checks whether matches with the received . If it does not hold, terminates this phase. Otherwise, believes the is authentic.

computes and . finally sends the message to through a public channel.

Upon receiving the message, checks the validity of and computes and . then checks whether matches with the received . If it does not hold, terminates this phase. Otherwise, believes that is authentic and proceeds with the next step.

computes and and sends the message to through a public channel.

Upon receiving the message, checks the validity of and computes and . then checks whether matches with the received . If it does not hold, this phase is terminated. Otherwise, believes that is authentic and successfully ends the authentication phase.

3. Security Weaknesses of Jung et al.’s Scheme

In this section, we show that Jung et al.’s scheme [13] has security weaknesses.

3.1. Tracing Attack

As the concern for privacy increases in our lives, user anonymity has become a vital security requirement in various applications including WSN applications. For example, the personalized services in smart home applications (e.g., home energy management system) provide users with better convenience, but breach of privacy has been a serious concern [24]. In general, the preservation of identity privacy in the context of an authentication protocol requires not only anonymity but also untraceability [25]. Although untraceability is not a necessary condition of anonymity, strong anonymity with untraceability is required for fully protecting user privacy. In Jung et al.’s scheme, every time uses the fixed values and to login the WSN thus anyone can trace according to these strings constantly. Therefore, Jung et al.’s scheme is prone to user tracing attack and fails to provide untraceability.

3.2. Insecurity of the Secret Key of the Gateway Node

In Jung et al.’s scheme, the secret key K of is used to compute critical parameters of users’ smart cards and secret keys of all sensor nodes. The security of Jung et al.’s scheme thus depends on the security of the secret key K. Unfortunately, any authorized user can easily extract K using his/her identity, password, biometrics and values stored in the smart card. Assume that an authorized user retrieves the information from his/her smart card, where , , , and . As the smart card calculates at the login phase, then computes , , and . Based on and , computes , where . Since he or she now knows the secret key , can impersonate and launch the following attacks.

3.3. Information Leakage Attack

We described how an authorized user can know in Section 3.2. After getting , who acts as an adversary can achieve secret information required for authentication and key agreement as follows:

intercepts the user ’s login message , where , , and .

computes and .

then computes .

Thus, can obtain all secret values and need to login the WSN and launch session key recovery attack and user impersonation attack.

3.4. Session Key Compromise

We assume that can obtain the secret information by intercepting the ’s login message and also can intercept the last message of the authentication phase. After getting the secret information in Section 3.3 and , can successfully launch a session key recovery attack as follows:

intercepts the last message sent from , where and .

computes .

discovers the session key between the user , , and the sensor node by computing .

Thus, according to the above procedure, an adversary can successfully construct the session key between , , and .

3.5. User Impersonation Attack

Once an adversary achieves the ’s secret key K and secret information , and as described in Section 3.2 and Section 3.3, respectively, can also impersonate a user in Jung et al.’s scheme without the target user’s identity , password , and biometric information as follows:

computes and , where is the current time stamp used by . Of course, since and are the fixed values, it is possible to use the previously intercepted one.

sends the login message .

At , user authentication is successfully performed and calculates the session key after receiving the last message as described in Section 3.4.

It is clear from the above discussion that can masquerade as a valid user to login to the WSN without , and . Thus, Jung et al.’s scheme is vulnerable to the user impersonation attack.

4. Proposed Scheme for Smart Homes

In this section, we propose a three-factor authentication and key agreement scheme in WSNs for smart homes in which we find the aforementioned security weaknesses found in Jung et al.’s scheme. Figure 1 illustrates a system model of WSNs for a smart home monitoring and control system. The system model includes three types of entities: a user (), a home gateway node (), and sensor nodes (). After registration and mutual authentication with the help of , can access the WSN to monitor and control smart home.

Figure 1

An example of smart home monitoring and control system based on WSNs.

The proposed scheme consists of five phases: system setup, user registration, login, authentication, and password change. We use the additional notation for the proposed scheme listed in Table 2.

Table 2

Notations used for the proposed scheme.

Notation	Description	Notation	Description
HG	Home Gateway	SC_i	Smart card for U_i
TID_i	Temporary identity of U_i	SK	Session key
PIDil	One-time pseudonym of U_i for the l-th login	GEN(·)	Fuzzy generator function
K_U	Secret key generated by the HG for users	REP(·)	Fuzzy reproduction function
K_S	Secret key generated by the HG for sensor nodes

4.1. System Setup Phase

This phase is executed by home gateway () in an off-line mode before deployment of sensor nodes in a target field.

generates randomly two master secrets and for all users and all sensor nodes, respectively, which are only known to .

selects a unique identity and computes for each sensor node .

Finally, each sensor node is deployed in the target field after storing and into its memory in a secure manner.

4.2. User Registration Phase

The user registration phase begins when a user sends a request message for registration to over a secure channel. Figure 2 illustrates the user registration phase for the proposed scheme. This phase is described below.

Figure 2

User registration phase for the proposed scheme.

selects the desired identity and password and imprints his/her biometrics . generates a random secret number and computes , and . then sends a registration request to over a secure channel.

Upon receiving the user’s registration request, randomly selects a unique one-time pseudonym for . computes , , , and . issues a smart card for after saving in it. then sends to over a secure channel and stores into its memory.

After receiving the smart card , computes and saves , , , and in . Finally, contains .

4.3. Login Phase

The login phase is executed when wants to gain access to the WSN using his/her , and . Figure 3 illustrates the login and authentication phases for the proposed scheme. This phase contains the following steps.

Figure 3

Login and authentication phases for the proposed scheme.

inserts own , inputs his/her and , and imprints his/her biometrics into a terminal (i.e., a smart card reader or a smartphone embedded with ).

computes , , , , and . checks whether matches with the stored . If it matches ensures that has provided correct and . then selects a random number and computes and .

Finally, sends a login request to over a public channel.

4.4. Authentication Phase

The authentication phase begins when receives the login request from . For achieving mutual authentication and session key agreement, this phase executes in several steps as followings.

checks the validity of the timestamp and searches using . computes , , , and . Then, compares with the received value . If this condition is not satisfied, terminates this phase. Otherwise, believes that is a legitimate user. then chooses an appropriate sensor node for the user’s needs and computes , , and . sends the message to over a public channel.

Upon receiving the message from , checks the validity of the timestamp and compute and . then compares with the received value . If this condition is not satisfied, terminates this phase since fails to prove to be a legitimate home gateway. Otherwise, believes that is authentic. then selects a random number and computes , , , and . sends the message to over a public channel.

Upon receiving the message from , checks the validity of the timestamp and computes , , , and . compares with the received value . If this condition is not satisfied, terminates this phase. Otherwise, believes that is a legitimate sensor node. then randomly selects another unique one-time pseudonym for ’s next login session and computes , , , and . Finally, sends the message to over a public channel and updates stored in its memory to for .

Upon receiving the message from , checks the validity of the timestamp and computes , , , and . then compares with the received value . If this condition is not verified, terminates this phase since fails to prove to be a legitimate home gateway. Otherwise, believes that is authentic and updates in to for the next session.

4.5. Password Change Phase

The password change phase begins when wants to change the original password to a new password . Figure 4 illustrates this phase for the proposed scheme. This phase contains the following steps.

Figure 4

Password change phase for the proposed scheme.

inserts own , inputs his/her , , and a new password and imprints his/her biometrics into a terminal.

computes , , , , , and . then compares with the stored . If this condition is not satisfied, terminates this phase. Otherwise, performs the next step.

computes , , and . replaces the stored values and with the newly computed values and , respectively. Finally, contains , where ℓ is the index of the next login.

5. Formal Security Analysis of the Proposed Scheme

In this section, we formally analyze the security of the proposed scheme in three ways. First of all, in Section 5.1, we conduct a formal security proof in the random oracle model since the proposed scheme heavily depends on the security of a one-way hash function. Through the rigorous formal poof using the random oracle, we show that the proposed scheme is probabilistically secure against an adversary both to protect the long-term secret information of the user and home gateway and to protect the session key shared between the user and sensor node. In Section 5.2, we then perform the logical verification using BAN logic [26] to confirm the correctness that the authenticated participants share the session key securely in the proposed scheme. In Section 5.3, we automatically validate the proposed scheme using AVISPA tool [27,28] to ensure that the proposed scheme is secure against active and passive attacks (i.e., replay and man-in-the-middle attacks) defined in the simulation tool.

5.1. Security Proof Using Random Oracle Model

Through a formal proof using the random oracle model, we show that the proposed scheme is secure against an adversary. We follow the formal security proof of the proposed scheme similar to that in [13,22] and consider the method of contradiction proof. Based on the random oracle model, the following Theorems 1 and 2 show that the proposed scheme can resist various security attacks. For this purpose, we assume that there exists the following random oracle as illustrated in Definition 1.

Reveal: Given a hash value y=h(x), this random oracle unconditionally outputs the input x.

Under the assumption that a one-way hash function h(·) behaves like an oracle, the proposed scheme is probably secure against an adversary

For the proof, we assume that an adversary is able to derive the identity , the password , and the biometric key of a legal user , and the secret key of the . We also assume that the adversary has the lost/stolen smart card of the user and can extract all the sensitive information stored in the using the power analysis attack [29,30,31]. For this,  uses the oracle to run an experimental algorithm shown in Algorithm 1 for the proposed three-factor authentication and key agreement (). We define the success probability for as , where is the probability of an event E. The advantage function for this experiment becomes in which the maximum is taken over all with execution time and the number of queries made to the oracle. According to the attack experiment described in Algorithm 1, if the adversary has the ability to invert the one-way hash function , then can directly obtain ’s , and and ’s , and win the game. However, it is computationally infeasible problem to invert , i.e., , for any sufficiently small . Then, we have , since depends on . Therefore, the proposed scheme is provably secure against the adversary for deriving , and , even if the smart card is lost/stolen by .  □

Extract the information from using the power analysis attack [29,30,31].

Call the oracle. Let

Compute

Call the oracle. Let

if () then

Compute

Intercept the login request message

Call the oracle. Let

if () and () and () and then

Call the oracle. Let

Call the oracle. Let

Call the oracle. Let

Compute

if () then

Accept , and as the correct identity , password , biometric key of

the user , and as the correct secret key of .

return 1

else

return 0

end if

else

return 0

end if

else

return 0

end if

Under the assumption that a one-way hash function h(·) behaves like an oracle, the proposed scheme is probably secure against an adversary

The proof of this theorem is similar to that in Theorem 1. We assume that an adversary is able to derive the session key shared between a legal user and a sensor node . For this, uses the oracle to run an experimental algorithm shown in Algorithm 2 for the proposed three-factor authentication and key agreement (). We define the success probability for as . The advantage function for this experiment becomes in which the maximum is taken over all with execution time and the number of queries made to the oracle. According to the attack experiment described in Algorithm 2, if the adversary has the ability to invert the one-way hash function , then can easily derive and win the game. However, it is computationally infeasible problem to invert , i.e., , for any sufficiently small . Then, we have , since is also dependent on . Therefore, the proposed scheme is provably secure against the adversary for deriving .  □

Intercept the login request message during the login phase.

Call the oracle. Let

if () and () then

Compute

Compute

if () then

Intercept the message during the authentication phase.

Call the oracle. Let

if () and () then

Compute

if () then

Accept as the correct session key shared between and .

return 1

else

return 0

end if

else

return 0

end if

else

return 0

end if

else

return 0

end if

5.2. Security Verification using BAN Logic

In this section, we use BAN logic to verify the legitimacy of the session key shared between participants who communicate in the proposed scheme. Table 3 and Table 4 illustrate notations and rules used in BAN logic, respectively.

Table 3

Notations in BAN logic.

Notation	Description	Notation	Description
P|≡X	P believes X	#(X)	X is fresh
P◃X	P sees X	P↔KQ	K is the shared key between P and Q
P|∼X	P said X	〈X〉_Y	X combined with the formula Y
P⇒X	P has jurisdiction over X	(X)_K	X hashed under the key K

Table 4

Rules in BAN logic.

Rule	Description
P|≡P↔KQ,P◃〈X〉_KP|≡Q|∼X	[Rule 1: Message-meaning rule] if P believes that the K is shared with Q and P sees X combined with K, then P believes Q said X
P|≡#(X),P|≡Q|∼XP|≡Q|≡X	[Rule 2: Nonce-verification rule] if P believes that X is fresh and P believes Q said X, then P believes that Q believes X
P|≡#(X)P|≡#(X,Y)	[Rule 3: Freshness-conjuncation rule] if P believes that X is fresh, then P believes that (X,Y) is fresh
P|≡Q|⇒X,P|≡Q|≡XP|≡X	[Rule 4: Jurisdiction rule] if P believes that X has jurisdiction over X and P believes that Q believes X, then P also believes X

To ensure the security of the proposed scheme under BAN logic, the proposed scheme needs to satisfy the following goals.

Goal 1:

Goal 2:

Goal 3:

Goal 4:

We first transfer all transmitted messages into idealized form as follows.

: :

: :

: :

: :

We secondly define some assumptions as initiative premises as follows.

:

:

:

:

:

:

:

:

:

:

We then prove the proposed scheme achieves the security goals based on the idealized form of the messages, assumptions, and BAN logic rules.

According to , we get

:

According to and Rule 1, we get

:

According to and Rule 3, we get

:

According to , and Rule 2, we get

:

According to , we get

:

According to and Rule 1, we get

:

According to and Rule 3, we get

:

According to , and Rule 2, we get

:

According to , we get

:

According to and Rule 1, we get

:

According to and Rule 3, we get

:

According to , and Rule 2, we get

:

According to , we get

:

According to and Rule 1, we get

:

According to and Rule 3, we get

:

According to , and Rule 2, we get

:

As and combining , we get

: (Goal 1)

and combining , we get

: (Goal 3)

According to and Rule 4, we get

: (Goal 2)

According to and Rule 4, we get

:

Therefore, the above logic proves that the proposed scheme achieves Goals 1–4 successfully. In other words, the proposed scheme achieves mutual authentication and the session key is securely shared between parties.

5.3. Security Verification Using AVISPA

We simulate the proposed scheme using the AVISPA software, a widely accepted tool for automatically validating the security features of the protocols. We describe the implementation of the proposed scheme using HLPSL (High-Level Protocols Specification Language) and then present the simulation results.

5.3.1. HLPSL Specification of the Proposed Scheme

We now briefly discuss the simulation process of the proposed scheme for the roles of the participants, , and , the session, the goal, and the environment. Table 5, Table 6 and Table 7 present the roles of , and in HLPSL language, respectively. Table 8 presents the session, environment, and goal roles in the HLPSL language. In the implementation, the following seven secrecy goals and two authentication properties were verified.

Table 5

Role specification of in HLPSL.

1: role user(Ui, HG, Sj: agent, SKey1: symmetric_key, SKey2: symmetric_key,

H, GEN, REP: hash_func, Snd, Rcv: channel(dy))

2: played_by Ui

3: def=

4:    local State: nat, IDi, PWi, Bioi, BBi, Pari, TIDi, HPWi, HIDi, PID1i, Si, Ai, Bi, Ci, C1i, C2i, Di, RRi, RRj, Ri,

T1, T4: text, Mi, Muig, SKij, P2i, Mg, Mgui: message,

5:    Inc: hash_func

6:    const user_gateway, gateway_user, sensor_user, subs1, subs2, subs3, subs4, subs5, subs6, subs7: protocol_id

7:    init State :=0

8:    transition

9:       1. State = 0 ∧ Rcv(start) =|>

10:       State’ := 1 ∧ IDi’ := new() ∧ PWi’ := new() ∧ Si’ := new() ∧ BBi’ := GEN(Bioi) ∧ Pari’ := GEN(Bioi)

∧ HPWi’ := H(PWi’.BBi’) ∧ TIDi’ := H(IDi’.Si’) ∧ Snd(TIDi’.HPWi’_SKey1) ∧ secret(IDi,PWi, subs1, Ui)

11:       2. State = 1 ∧ Rcv({Ai’.Bi’.C1i’}_SKey1) =|>

12:       State’ := 2 ∧ Ri’ := new() ∧ T1’ := new() ∧ BBi’ := GEN(Bioi) ∧ Di’ := xor(ui,H(IDi.BBi’)) ∧ TIDi’ := H(IDi.ui)

∧ HPWi’ := h(PWi.BBi’) ∧ Ai’ := xor(HIDi, H(HPWi’.TIDi’)) ∧ Bi’ := H(HPWi’.HIDi)

∧ PID1i’ := xor(C1i’, H(TIDi’.HIDi)) ∧ RRi’ := H(TIDi’.PID1i’.Ri’) ∧ Mi’ := xor(Ri’, H(TIDi’.HIDi.T1’))

∧ Muig’ := H(TIDi’.HIDi.PID1i’.RRi’.T1’)

∧ Snd(PID1i’.Mi’.Muig’.T1’) ∧ secret({TIDi,HIDi}, subs2, {Ui, HG}) ∧ witness(Ui, HG, user_gateway, RRi’)

13:       3. State = 2 ∧ Rcv(P2i’.Mg’.Mgui’.T4’) =|>

14:       State’ := 3 ∧ RRj’ := xor(Mg’, H(PID1i.HIDi)) ∧ SKij’ := H(RRi.RRj’)

∧ secret({RRi,RRj}, subs3, {Ui, HG, Sj}) ∧ secret({SKij}, subs4, {Ui, HG, Sj})

15: end role

Table 6

Role specification of in HLPSL.

1: role gateway(Ui, HG, Sj: agent, SKey1: symmetric_key, SKey2: symmetric_key,

H, GEN, REP: hash_func, Snd, Rcv: channel(dy))

2: played_by HG

3: def=

4:    local State: nat, Ku, Ks, TIDi, HPWi, PID1i, PID2i, HIDi, Ai, Bi, C1i, C2i, SIDj, Xsj, RRi, RRj, Ri, Rj,

T1, T2, T3, T4: text, Mi, Muig, Mg, Mg2, Mgsj, Mgui, Mj, Msjg, SKij, P2i: message,

5:    Inc: hash_fun

6:    const user_gateway, gateway_user, sensor_user, subs1, subs2, subs3, subs4, subs5, subs6, subs7: protocol_id

7:    init State :=0

8:   transition

9:       1. State = 0 ∧ Rcv({TIDi’.HPWi’}_SKey1) =|>

10:       State’ := 1 ∧ PID1i’ := new() ∧ HIDi’ := H(TIDi’.Ku) ∧ Ai’ := xor(HIDi’, H(HPWi’.TIDi’))

∧ Bi’ := H(HPWi’.HIDi’) ∧ C1i’ := xor(PID1i’, H(TIDi’.HIDi’)) ∧ Snd({Ai’.Bi’.C1i’}_SKey1)

∧ SIDj’ := new() ∧ Xsj’ := H(SIDj’.Ks)

∧ Snd({SIDj’.Xsj’}_SKey2) ∧ secret(Ku, subs5, HG) ∧ secret(Ks, subs6, HG) ∧ secret(Xsj, subs7, HG, Sj)

11:       2. State = 1 ∧ Rcv(PID1i’.Mi’.Muig’.T1’) =|>

12:       State’ := 2 ∧ HIDi’ := H(TIDi.Ku) ∧ Ri’ := xor(Mi’, H(TIDi.HIDi’.T1’)) ∧ RRi’ := H(TIDi.PID1i.Ri’)

∧ T2’ := new() ∧ Xsj’ := H(SIDj.Ks) ∧ Mg2’ := xor(RRi’, H(Xsj’.T2’)) ∧ Mgsj’ := H(PID1i’.SIDj.Xsj’.RRi’.T2’)

∧ Snd(PID1i’.Mg2’.Mgsj’.T2’)

13:       3. State = 2 ∧ Rcv(Mj’.Msjg’.T3’) =|>

14:       State’ := 3 ∧ Rj’ := xor(Mj’, H(Xsj.T3’)) ∧ RRj’ := H(SIDj.Rj’) ∧ SKij’ := H(RRi.RRj’) ∧ PID2i’ := new()

∧ T4’ := new() ∧ C2i’ := xor(PID2i’, H(TIDi.HIDi)) ∧ P2i’ := xor(C2i’, H(HIDi.T4’))

∧ Mg’ := xor(RRj’, H(PID1i.HIDi)) ∧ Mgui’ := H(PID1i.HIDi.C2i’.RRj’.SKij’.T4’)

∧ Snd(P2i’.Mg’.Mgui’.T4’)

15: end role

Table 7

Role specification of in HLPSL.

1: role sensor(Ui, HG, Sj: agent, SKey1: symmetric_key, SKey2: symmetric_key,

H, GEN, REP: hash_func, Snd, Rcv: channel(dy))

2: played_by Sj

3: def=

4:    local State: nat, PID1i, SIDj, Xsj, RRi, RRj, Rj, T2, T3: text, Mg2, Mgsj, Mgui, Mj, Msjg, SKij: message,

5:    Inc: hash_func

6:    const user_gateway, gateway_sensor, sensor_user, subs1, subs2, subs3, subs4, subs5, subs6, subs7: protocol_id

7:    init State :=0

8:    transition

9:       1. State = 0 ∧ Rcv({SIDj’.Xsj’}_SKey2) =|>

10:       State’ := 1 ∧ T3’ := new()

11:       2. State = 1 ∧ Rcv(PID1i’.Mg2’.Mgsj’.T2’) =|>

12:       State’ := 2 ∧ RRi’ := xor(Mg2’, H(Xsj.T2’)) ∧ Rj’ := new() ∧ T3’ := new() ∧ RRj’ := H(SIDj.Rj’)

∧ Mj’ := xor(Rj’, H(Xsj.T3’)) ∧ SKij’ := H(RRi’.RRj’) ∧ Msjg’ := H(PID1i’.SIDj.Xsj.Rj’.SKij’.T3’)

∧ Snd(Mj’.Msjg’.T3’) ∧ witness(Sj, HG, gateway_sensor, RRj’)

13: end role

Table 8

Specification of the session, environment, and goal in HLPSL.

1: role session(Ui, HG, Sj:agent, SKey1: symmetric_key, SKey2: symmetric_key,

H, GEN, REP: hash_func)

2: def=

3:    local SI, SJ, RI, RJ, PI, PJ: channel(dy)

4:    composition

5:       user(Ui, HG, Sj, SKey1, SKey2, H, GEN, REP, SI, RI)

6:       ∧ gateway(Ui, HG, Sj, SKey1, SKey2, H, GEN, REP, SJ, RJ)

7:       ∧ sensor(Ui, HG, Sj, SKey1, SKey2, H, GEN, REP, PI, PJ)

8: end role

1: role environment()

2: def=

3:    const ui, hg, sj: agent, skey1 : symmetric_key, skey2 : symmetric_key, h, gen, rep: hash_func,

4:          idi, bioi, sidj, pwi, ai, bi, ci, t1, t2, t3, t4, rri, rrj, skij, mi, mj, mg, mg2, muig, mgui, mgsj, msjg: text,

5:          user_gateway_rri, gateway_sensor_rrj, sensor_user,

6:          subs1, subs2, subs3, subs4, subs5, subs6, subs7: protocol_id

7:    intruder_knowledge = ui, hg, sj, h, gen, rep, mi, muig, mg2, mgsj, mj, msjg, mg, mgui

8:    composition

9:       session(hg, ui, sj, skey1, skey2, h, gen, rep)

10:       ∧ session(ui, hg, sj, skey1, skey2, h, gen, rep)

11:       ∧ session(sj, ui, hg, skey1, skey2, h, gen, rep)

12: end role

1: goal

2:    secrecy_of subs1 secrecy_of subs2 secrecy_of subs3 secrecy_of subs4

3:    secrecy_of subs5 secrecy_of subs6 secrecy_of subs7

4:    authentication_on user_gateway_rri authentication_on gateway_sensor_rrj 5: end goal

environment()

Goal 1: The secrecy_of subs1 represents that are kept secret to () only.

Goal 2: The secrecy_of subs2 represents that are kept secret to () only.

Goal 3: The secrecy_of subs3 represents that are kept secret to () only.

Goal 4: The secrecy_of subs4 represents the negotiated session key is only known to ().

Goal 5: The secrecy_of subs5 represents that the secret key of is permanently kept secret, known to only ().

Goal 6: The secrecy_of subs6 represents that the secret key of is permanently kept secret, known to only ().

Goal 7: The secrecy_of subs7 represents that the shared secret is only known to ().

Authentication Property 1: The authentication_on user_gateway_rri represents that generates . If securely receives through a message, it authenticates .

Authentication Property 2: The authentication_on gateway_sensor_rrj represents that generates . If securely receives through a message, it authenticates .

5.3.2. Simulation Results

We execute the HLPSL specifications using SPAN (Security Protocol ANimator for AVISPA) [32]. Figure 5a,b show the simulation results based on OFMC (On-the-Fly-Model-Checker) and CL-AtSe (Constraint-Logic-based Attack Searcher) models, respectively. From these results, we find that the proposed scheme is SAFE under OFMC and CL-AtSe against active and passive attacks. Therefore, we demonstrate that the proposed scheme is secure.

Figure 5

Simulation results of the proposed scheme using AVISPA tool: (a) OFMC model, (b) CL-AtSe model.

6. Implication of Security Analysis

We further describe the implication of our security analysis with regard to security properties of the proposed scheme. Saying, we show how the proposed scheme satisfies the security requirements for user authentication and session key agreement and resists various kinds of known attacks. We then compare the security of the proposed scheme with other related schemes.

6.1. Security Properties

6.1.1. Mutual Authentication

In steps (1) and (4) of Section 4.4, and authenticate each other by verifying the correctness of and . An adversary cannot generate legal and without knowing . Even if the adversary obtains of and stored values, the adversary cannot derive the correct without having the corresponding ’s , and . As a result, the proposed scheme can achieve mutual authentication between and .

In steps (2) and (3) of Section 4.4, and authenticate each other by verifying the correctness of and . An adversary cannot generate legal and without knowing their shared secret information . As a result, the proposed scheme can achieve mutual authentication between and .

6.1.2. Session Key Agreement

In the login and authentication phases, the session key is established between and for protecting future communication. In the proposed scheme, the secrecy of is dependent on the secrecy of the random values and . These values are carefully protected by the secret keys shared between and and between and , respectively. Even if an adversary obtains for the ℓ-th session, he/she cannot compute any of the past and future session keys by using this disclosed because is protected by and the random values and including one-time psuedonym are different in each session. As a result, the proposed scheme achieves both session key agreement and known key security.

6.1.3. User Anonymity with Untraceability

As we mentioned in Section 3.1, for fully protecting user privacy, strong anonymity with untraceability is required. In the proposed scheme, the ’s actual identity is not transmitted during all phases, including the registration phase. Therefore, even if an adversary eavesdrops on all communication messages, it is not possible to obtain directly from the messages. In addition, even if the adversary gets , it cannot retrieve from because is masked with and is protected by only known to . Similarly, even if the adversary gets , it cannot retrieve from without knowing a secret key, , which is only known to .

Furthermore, and in the login request message are computed with random values and and uses an one-time pseudonym every session. In other words, all values in the login request message are different in sessions. Therefore, any adversary cannot trace the different sessions of the same user from exchanged messages via public channels and the proposed scheme achieves the feature of strong anonymity with untraceability.

6.1.4. Resisting Stolen Smart Card Attack

In the proposed scheme, ’s smart card contains where , , and . Even if is stolen by an adversary and all contained values in it are retrieved by the adversary through side-channel attacks such as power analysis attack [29,30,31], the adversary cannot guess , , and including , , and by using , , , and and also cannot guess from without knowing , and because it is impossible to know these key values. Without knowing ’s real identity , password , and biometric , the adversary cannot impersonate as the user. As a result, the proposed scheme can resist the stolen smart card attack.

6.1.5. Resisting Offline Guessing Attack

An adversary may attempt to guess ’s identity , password and biometric key by extracting the values stored in the smart card . However, the adversary cannot derive using only without knowing the ’s biometric . The adversary also cannot derive and from and , respectively, without knowing the random value . Therefore, the adversary cannot guess the correct , , and without knowing and due to the collision-resistant property of the one-way hash function . As a result, the proposed scheme can resist the offline guessing attack.

6.1.6. Resisting Privileged Insider Attack

In practice, users tend to use same password to register across different systems. If a privileged insider obtain the user’s password, he/she can use it to access other systems by impersonating as this user. In the proposed scheme, submits the hashed password instead of the plaintext of real password during the registration phase. is also masked by ’s secret biometric key . Therefore, an insider cannot obtain ’s real password and the proposed scheme can resist the privileged insider attack.

6.1.7. Resisting Stolen-Verifier Attack

To succeed in the stolen-verifier attack, an adversary should obtain the verification information (e.g., the plaintexts of passwords, hashed passwords, biometric key data, or hashed biometric key data) stored in the server. However, in the proposed scheme, the server maintains only which is both password-independent and biometric-key-independent information. Therefore, the proposed scheme can resist the stolen-verifier attack.

6.1.8. Resisting Known Session-Specific Temporary Information Attack

In the proposed scheme, both randomly selected values and , from and , respectively, are always masked by the secret values and . Even if an adversary knows and , he/she cannot compute without knowing ’s temporary identity and one-time pseudonym and ’s identity . Moreover, as we described, the adversary has no way to compute and . As a result, in the proposed scheme, a leakage of the session-specific temporary information and does not affect the security of the established session key.

6.1.9. Resisting User Impersonation Attack

To impersonate a user , an adversary should obtain the values in and intercepts the messages exchanged in the previous sessions. In the proposed scheme, even if the adversary succeeded the above things, the adversary cannot produce a legal login request without knowing all the authentication factors, i.e., , , and including and . As we mentioned above, it is impossible for an adversary to obtain , and . Therefore, the proposed scheme can resist the user impersonation attack.

6.1.10. Resisting Sensor Node Impersonation and Node Capture Attacks

To impersonate a sensor node , an adversary should intercept the messages exchanged in the previous sessions. However, in the proposed scheme, the adversary cannot produce a legal message without knowing because the adversary does not know the ’s secret key even if he/she obtains .

Even if the adversary captures a sensor node and obtains stored in , the adversary’s further attacks using the compromised sensor node only affect communications related to that node. Since each sensor node has a different key , the adversary cannot derive other non-compromised sensor nodes’ keys without knowing and thus the further attacks will not affect other communications. As a result, the proposed scheme can resist both sensor node impersonation attack and node capture attack.

6.2. Comparison of Security Features

We compare the security features of the proposed scheme with other related three-factor authentication and key agreement schemes [9,11,12,13]. Table 9 shows the comparison results. From Table 9, we can see that first three related schemes do not guarantee all security features, in especial, untraceability required for strong anonymity. The proposed scheme and Jiang et al.’s scheme achieves more ideal security features and resist most of attacks. However, Jiang et al.’s scheme is expensive to implement and deploy in practical applications due to the low performance of Rabin cryptosystem. As shown in Section 7, Jiang et al.’s scheme is five times slower than the proposed scheme in total running time.

Table 9

Security feature comparison of the proposed scheme with other related three-factor authentication and key agreement schemes.

Security Feature	Amin et al. [11]	Park et al. [9]	Jung et al. [13]	Jiang et al. [12]	Proposed Scheme
Mutual authentication	O	O	O	O	O
Session key security	O	O	X	O	O
User anonymity	O	O	O	O	O
Untraceability	X	X	X	O	O
Resistance to
Stolen smart card attack	X	O	X	O	O
Offline guessing attack	O	O	O	O	O
Privileged insider attack	O	O	O	O	O
Stolen-verifier attack	O	X	O	O	O
Known session-specific	X	O	O	O	O
temporary information attack
User impersonation attack	O	O	X	O	O
Sensor node	O	O	O	O	O
impersonation attack

O: The scheme can provide the security feature or resist the attack; X: The scheme cannot provide the security feature or resist the attack.

7. Performance Analysis of the Proposed Scheme

We analyze the performance of the proposed scheme and compare it with other related schemes in terms of computational cost and communication cost.

7.1. Computational Cost Analysis

For computational cost analysis, we compare the computation cost of the proposed scheme with the four related schemes [9,11,12,13]. We only focus on comparing the login and authentication phases because the registration and password change phases are not performed frequently. Since the time for executing of a bitwise XOR operation is negligible, we do not consider XOR operations for computational cost analysis. To facilitate analysis, we use the following notations.

: time for executing a one-way hash function

: time for executing a biohash function

: time for executing a fuzzy extractor

: time for executing an ECC point multiplication

: time for a modular exponentiation

Wang et al. [33] implemented several operations on three kinds of common PCs and measured their execution time by using C/C++ library MIRACL. According to the experimental results in Wang et al.’s research [33], we assume that the executing time for the cryptographic one-way hash function (SHA-1), ECC point multiplication (ECC sect163r1 [34]), and modular exponentiation () on common PCs (Intel T5870 2.00 GHz, Intel, Santa Clara, CA, US) are 2.58 µs, 1.226 ms, and 2.573 ms, respectively. Moreover, the execution time for the fuzzy extractor operation is almost the same as the ECC point multiplication [35] and it is also assumed that according to [36]. We consider possible real sensor devices with 8-bit ATmega128L micorocontroller (i.e., MICAz of Crossbow Technology). According to the experimental results on those sensor nodes [37,38], we assume that the executing time for the cryptographic one-way hash function (SHA-1) and ECC point multiplication (ECC sect163r1 [34]) are 3.6 ms and 114 ms, respectively.

In Table 10, we summarize the computational cost and running time of the proposed scheme and of the related schemes for user, gateway node, and sensor node. The total running time of the proposed scheme for the login and authentication phases is ms. It shows that the proposed scheme is almost 10 times more efficient than and Park et al. scheme [9]. The proposed scheme also has a higher security level than both Amin et al.’s scheme [11] and Jung et al.’s scheme [13] as shown in Table 9 and it is as efficient as them. Although Jiang et al.’s scheme [12] has similar security level with the proposed scheme, the proposed scheme is slightly efficient and easily implemented than Jiang’s et al.’s scheme since the proposed scheme uses only lightweight operations such as XOR and hash functions not complex public-key cryptographic operations. Therefore, the proposed scheme can achieve all security features in Table 9 without deteriorating efficiency in terms of the computational cost.

Table 10

Comparison of computation costs for the login and authentication phases of the proposed scheme and other related schemes.

Entity	Amin et al. [11]	Park et al. [9]	Jung et al. [13]	Jiang et al. [12]	Proposed Scheme
User	T_B+12T_H	T_F+2T_P+10T_H	T_B+8T_H	T_B+T_M+8T_H	T_F+13T_H
Gateway node	15T_H	11T_H	9T_H	T_M+12T_H	15T_H
Sensor node	5TH′	2TP′+4TH′	4TH′	5TH′	6TH′
Total cost	T_B+27T_H+5TH′	T_F+2T_P+2TP′	T_B+17T_H+4TH′	T_B+2T_M	T_F+28T_H+6TH′
		+21T_H+4TH′		+20T_H+5TH′
Total running time	≈19.3 ms	≈246.1 ms	≈15.7 ms	≈24.4 ms	≈22.9 ms

7.2. Communication Cost Analysis

We also analyze the communication cost of the proposed scheme for login and authentication phases and compare it with that of the related schemes [9,11,12,13]. For communication cost analysis, we evaluate the communication cost in terms of the size of message in bits and the number of values in a message. We assume that the lengths of the identity, password, random number, and output of the hash function are each 128 bits. We also assume that the lengths of modulo n for rabin cryptosystem used in [12] and prime p for ECC used in [9] are each 1024 bits.

The communication cost of user, gateway node, and sensor node of the proposed scheme and related schemes are summarized in Table 11. The total communication cost of the proposed scheme is 1920 bits. From comparison in Table 11, the proposed scheme require lower communication cost than the above related schemes expect Jung et al.’s scheme. Although the proposed scheme is slightly less efficient than Jung et al.’s scheme in terms of communication cost, the difference (512 bits) is not significant since the proposed scheme has a higher security level as shown in Table 9.

Table 11

Comparison of communication costs for the login and authentication phases of the proposed scheme and other related schemes: the size of message in bits (the number of values in a message).

Communication	Amin et al. [11]	Park et al. [9]	Jung et al. [13]	Jiang et al. [12]	Proposed Scheme
User→Gateway node	768 bits (6)	1536 bits (5)	512 bits (4)	1408 bits (4)	512 bits (4)
Gateway node→Sensor node	640 bits (5)	1408 bits (4)	512 bits (4)	640 bits (5)	512 bits (4)
Sensor node→Gateway node	384 bits (3)	1280 bits (3)	256 bits (2)	384 bits (3)	384 bits (3)
Gateway node→User	384 bits (3)	1408 bits (4)	384 bits (3)	256 bits (2)	512 bits (4)
Total	2176 bits	5632 bits	1664 bits	2688 bits	1920 bits

8. Conclusions

In this paper, we have identified the security weaknesses in the recent three-factor authentication and key agreement scheme. Then, we have introduced the system model for smart homes based on WSNs. Based on this model, we have proposed a secure and lightweight three-factor authentication and key agreement scheme using the smart card, password, and biometrics. We have presented security proof using random oracle model and BAN logic. Afterwards, we have performed the security verification using AVISPA. Through formal and informal security analysis, we have demonstrated the proposed scheme fulfills the desirable security requirements and resists against various attacks. We have also evaluated the performance of the proposed scheme with regard to the computational and communication overheads. Finally, we have presented the comparative analysis of the proposed scheme with other related schemes, which justify that the proposed scheme has advantages in terms of efficiency and security.

In the future work, we expect to evaluate the performance of the proposed scheme by implementing and conducting experiments on actual devices (e.g., smart phones and sensor motes) for smart homes based on WSNs. Based on the experimental results, it will be possible to further examine the effectiveness of the proposed scheme.