Security enhanced user authentication protocol for wireless sensor networks using elliptic curves cryptography.

Wireless sensor networks (WSNs) consist of sensors, gateways and users. Sensors are widely distributed to monitor various conditions, such as temperature, sound, speed and pressure but they have limited computational ability and energy. To reduce the resource use of sensors and enhance the security of WSNs, various user authentication protocols have been proposed. In 2011, Yeh et al. first proposed a user authentication protocol based on elliptic curve cryptography (ECC) for WSNs. However, it turned out that Yeh et al.'s protocol does not provide mutual authentication, perfect forward secrecy, and key agreement between the user and sensor. Later in 2013, Shi et al. proposed a new user authentication protocol that improves both security and efficiency of Yeh et al.'s protocol. However, Shi et al.'s improvement introduces other security weaknesses. In this paper, we show that Shi et al.'s improved protocol is vulnerable to session key attack, stolen smart card attack, and sensor energy exhausting attack. In addition, we propose a new, security-enhanced user authentication protocol using ECC for WSNs.

Introduction

Wireless sensor networks (WSNs) provide a feasible real-time monitoring system. Wireless sensors can be easily deployed in various environments such as military surveillance, forest fire detection, health care and wildlife monitoring. WSNs basically consist of users, sensors and gateways whose communication security is a significant concern in real-world applications [1]. Users and gateways have sufficient resources to be used in the system, but sensors are different. Sensors have limited computational ability, low battery, low bandwidth, and a small amount of memory. Therefore, in WSNs, it is important to reduce the use of sensors to extend their lifespans [2-4].

Various user authentication protocols have been proposed for securing WSNs while minimizing the use of sensors. In 2004, Watro et al. proposed a user authentication protocol employing the RSA and Diffie-Hellman algorithms [5]. In 2006, Wong et al. proposed an efficient dynamic user authentication protocol using a hash function [6]. However, Tseng et al. demonstrated that Wong et al.'s authentication protocol is vulnerable to stolen-verifier attack, replay attack and forgery attack [7,8]. Later in 2009, Das proposed a two-factor user authentication protocol using smart cards. Das showed how to design an authentication protocol where only the user who is in possession of both the smart card and the password can pass the verification of the gateway [8]. However, several security-related flaws in Das's protocol have been disclosed by later studies as summarized below:

He et al. demonstrated that Das's protocol is vulnerable to insider attacks and impersonation attacks, and that it does not allow users to change their passwords freely. He et al. proposed an improved two-factor protocol [9] which can resist insider and impersonation attacks.

Khan and Alghathbar showed that Das's protocol fails to provide mutual authentication between the gateway and the sensor, and due to this failure, it is not secure against a gateway bypassing attack and a privileged-insider attack [10].

Chen et al. also pointed out that Das's protocol does not achieve mutual authentication between the gateway and the sensor, and proposed a robust authentication protocol that provides the property of mutual authentication [11].

In 2011, Yeh et al. [2] revealed that Chen et al.'s protocol has difficulty in updating users' passwords and is vulnerable to an insider attack. As an improvement of Chen et al.'s protocol, Yeh et al. presented the first user authentication protocol that uses elliptic curve cryptography (ECC) in WSN environments. However, Han [12] showed that Yeh et al.'s protocol has still some security weaknesses: it does not provide perfect forward secrecy and fails to achieve mutual authentication and key agreement between the user and the sensor. To address these problems with Yeh et al.'s protocol, Shi et al. [3] have recently proposed a new smart-card-based user authentication protocol using ECC for WSNs. Shi et al.'s protocol performs more efficiently, both in terms of computation and communication costs, and provides better security than Yeh et al.'s protocol. However, we found that Shi et al.'s improvement is not secure enough yet and their protocol is susceptible to session key attacks, stolen smart card attacks, and sensor energy exhausting attacks. In addition to reporting the security weaknesses, we also show how to enhance the security of Shi et al.'s protocol with no significant increase in communication and computation costs. We analyze and verify the security of the proposed protocol using non-monotonic cryptographic logic (Rubin logic).

Throughout the paper, we make the following assumptions on the capabilities of the probabilistic polynomial-time adversary in order to properly capture security requirements of two-factor authentication protocols using smart cards in wireless sensor networks.

has the complete control of all message exchanges between the protocol participants: a user, a sensor and the gateway. That is, can eavesdrop, insert, modify, intercept, and delete messages exchanged among the three parties at will.

is able to (1) extract the sensitive information on the smart card of a user through a power analysis attack [13,14] or (2) find out the user's password possibly via shoulder-surfing or by employing a malicious card reader. However, it is assumed that is unable to compromise both the two factors: the information on the smart card and the password of the user; it is clear that there is no way to prevent from impersonating the user if both factors are compromised.

Overview of Elliptic Curves Cryptography

In 1985, Neal Koblitz and Victor S. Miller proposed the use of elliptic curves in cryptography. After various studies on ECC, it has been widely used since the early 21st century. ECC is a type of public-key cryptography and based on the algebraic structure of elliptic curves over finite fields. Elliptic curves are also used in several integer factorization algorithms. ECC provides the important benefit of a smaller key size, despite which it is able to maintain the same degree of security as other types of public-key cryptography, such as RSA, DH and DSA. Therefore, ECC is especially useful for wireless devices, which typically have limited CPU capacity, power and network connectivity. Table 1 shows the NIST guidelines on choosing key sizes in ECC and other public key cryptography [15].

Table 1.

ECC key sizes compared with other PKC schemes.

Security (bits)	ECC	RSA/DH/DSA	MIPS-Years to Attack	Protection Lifetime
80	160	1,024	1012	until 2010
112	224	2,048	1024	until 2030
128	256	3,072	1028	beyond 2031
192	384	7,680	1047	beyond 2031
256	512	15,360	1066	beyond 2031

ECC has three related mathematical problems: the Elliptic Curve Discrete Logarithm Problem (ECDLP), Elliptic Curve Computational Diffie-Hellman Problem (ECCDHP), and Elliptic Curve Decisional Diffie-Hellman Problem (ECDDHP). No polynomial time algorithm can solve the ECDLP, ECCDHP and ECDDHP with non-negligible probability.

Let p > 3 be a large prime and choose two field elements a, b ∈ F satisfying 4a3 + 27b2 ≠ 0 mod p to define the equation of a non-supersingular elliptic curve E: y2 = x3 + ax + b mod p over F. Choose a generator point P = (xP, yP) whose order is a large prime number q over E(F). In the same way, a subgroup G of the elliptic curve group E(F) with order q is constructed. Then, the three mathematical problems in ECC are defined at various study [16-18] as follows.

ECDLP: Given a point element Q in G, find an integer x ∈ such that Q = xP, where xP indicates that the point P is added to itself x times by the elliptic curves operation.

ECCDHP: For a, b ∈ , given two point elements aP, bP in G, compute abP in G.

ECDDHP: For a, b, c ∈ , given three point elements aP, bP and cP in G, decide whether cP = abP.

Review of Shi et al.'s Protocol

In Shi et al.'s protocol [3], the gateway is a trusted node that holds two sufficiently large master keys, x and y. Before starting the system, the gateway and the sensors share a long-term secret key SK = h(ID‖y). Shi et al.'s protocol consists of four phases; user registration phase, login phase, authentication phase, and password update phase. For convenience, the notations used throughout this paper are summarized in Table 2.

Table 2.

Notations.

Symbol	Description
p, q	Two large prime numbers
FP	A finite field
E	An elliptic curve defined on finite field FP with large order
G	The group of elliptic curve points on E
IDU	The identity of user U
IDSn	The identity of sensor Sn
pwU	The user U's password
GW	The gateway of WSN
x, y	The master keys of GW
h(·)	A secure one-way hash function
‖	A string concatenation operation
⊕	A bitwise XOR operation

Registration Phase

In this phase, the user U securely submits its identity ID and password pw to the gateway GW. Then, GW issues U a smart card containing the user authentication information, as shown in Figure 1.

Figure 1.

The registration phase of Shi et al.'s protocol.

Login and Authentication Phases

In the login and authentication phases, when U enters ID and pw into a smart card terminal, the smart card must validate the legitimacy of U. Then, U, S and GW authenticate with each other. This protocol uses 4 messages (M1, M2, M3, M4) for mutual authentication, as described in Figure 2. Lastly, U and S share the session key sk. After the authentication phase, U and S communicate with each other using the session key sk.

Figure 2.

The login and authentication phases of Shi et al.'s protocol.

Password Update Phase

In the password update phase, U enters the identity ID, the old password pw, and the new password . Then, the smart card updates the password after first checking the correctness of the old password, as shown in Figure 3.

Figure 3.

The password update phase of Shi et al.'s protocol.

Security Weaknesses in Shi et al.'s Protocol

This section shows that Shi et al.'s protocol is vulnerable to a session key attack, a stolen smart card attack, and a sensor energy exhausting attack.

Session Key Attack

In Shi et al.'s protocol, the user U and the sensor S have to perform the login and authentication phases when they want to share a session key which will be used for protecting their subsequent communication. A problem occurs if U shares its session key with an attacker, not with the intended sensor S. In the protocol, the gateway GW and the user U check each other's legitimacy using the authenticators α and δ, respectively. However, α and δ do not include information about the sensor S with which U intends to establish a session key. The attacker exploits this design flaw in mounting a session key attack. The attack is depicted in Figure 4 and its description follows.

Figure 4.

A session key attack on Shi et al.'s protocol.

When U inputs ID and pw, and sends M1 to sensor S, the attacker intercepts M1 and sends it to sensor S which was previously stolen by the attacker. Upon receiving M1, the stolen sensor S will generate the message A2 and send it to the gateway GW. However, the attacker replaces ID contained in A2 with ID to make GW believe that ID wants to communicate with sensor S, not with S. After receiving A2, the gateway GW generates A3 without noticing any discrepancy and sends it to sensor S. Lastly, the attacker sends the user U the message A4 generated by S using the message A from GW. Because there is no information about the sensor S in A4 and M4, the user U undoubtedly shares the session key with the attacker while thinking that it has shared the key with the sensor S.

Stolen Smart Card Attack

Kocher et al. and Messerges et al. pointed out that the confidential information stored in smart cards could be extracted by physically monitoring its power consumption [13,14]. Therefore, it is fair to say that if a user loses his or her smart card, all information in the smart card may be revealed to the attacker.

In Shi et al.'s protocol, the smart card stores various information for user login and authentication. The smart card for the user ID includes bU and h(·). Using these information and ID, an attacker can guess U's password pw. If ID is used in public communication, the attacker can obtain or steal it without difficulty. Figure 5 describes a stolen smart card attack against Shi et al.'s protocol.

Figure 5.

A stolen smart card attack on Shi et al.'s protocol.

The attacker can obtain information from the smart card using attacks such as simple power analysis (SPA) and differential power analysis (DPA). This information includes b and h(·). Recall that B = h(ID ⊕ h(pw ⊕ b)). Using B as a password verifier, the attacker can easily find out the password pw by mounting an offline password guessing attack (also known as an offline dictionary attack) [19-22] if the password pw is not long enough. After successfully mounting the password guessing attack, the attacker can login and authenticate with the sensor S and the gateway GW using the identity ID and the password pw.

Sensor Energy Exhausting Attack

The computational cost of a sensor is a critical consideration in the design of WSNs as it increases the consumption of the battery power of the sensor. Often it is economically advantageous to discard a sensor rather than recharge it. For this reason, the battery power of a sensor is usually important in wireless devices, with its lifetime determining the sensor lifetime. Previous work have suggested several types of energy exhausting attacks. Buttyan et al. [23] investigated the reliability of transport protocols for WSNs. Brownfield et al. [24] researched the battery depletion effect through the reduction of sleep cycles. Khouzani et al. [25,26] investigated malware attacks in battery-constrained wireless networks. As shown by the previous researches, WSNs need to eliminate unnecessary computational costs of sensors so that the effects of an energy exhausting attack on sensors can be minimized.

In Shi et al.'s protocol, the sensor performs various cryptographic operations such as one-way hash function evaluations, scalar-point multiplications, random number generations, and map-to-point hash function evaluations. Scalar-point multiplications are much more expensive than hash function evaluations. The computational costs of generating a random number and evaluating a map-to-point hash function are about half the cost of performing a scalar-point multiplication. A sensor consumes a large amount of energy to perform a scalar-point multiplication and very little to perform a hash function evaluation [27-29].

Figure 6 shows the possibility of a sensor energy exhaustion attack. The attacker can keep sending malicious messages, A1, A2, A3, generated to consume the battery power of the sensor. The attacker can do so because the sensor only checks the freshness of the timestamp in M1. For each of these fake messages, the sensor checks the freshness of the timestamp and proceeds to perform the subsequent cryptographic operations, thereby consuming large amounts of energy. Accordingly, it is necessary to modify the protocol so that the sensor can check if the message M1 is from a legitimate user, not from an imposter.

Figure 6.

A sensor energy exhausting attack on Shi et al.'s protocol.

The Proposed Protocol

Like Shi et al.'s protocol, our proposed protocol is divided into three phases: the user registration phase, login and authentication phase, and password update phase. Before the protocol is ever executed, the gateway generates two master keys, x and y, and shares a long-term secret key SK = h(ID ‖ y) with the sensor S. In describing the protocol, we use the same notations as in Table 2 unless stated otherwise.

For a user U, this phase is performed only once when U registers itself with the gateway GW. Figure 7 illustrates how the phase works, and its description follows:

Figure 7.

The registration phase.

The user U chooses its identity ID and password pw freely, generates a random number b, and computes . U sends ID and to GW via a secure channel.

The gateway GW computes: Then, GW issues U a smart card loaded with {A(·)}.

Lastly, U inputs the random number b into the smart card.

Login and Authentication Phase

This phase is carried out whenever U wants to gain access to the WSN. During the phase, U establishes a session key with the sensor S while being authenticated by the gateway GW. The phase proceeds as follows (see also Figure 8):

Figure 8.

The login and authentication phase.

U inserts its smart card into the card reader and inputs its identity ID and password pw. Then, the smart card computes: and checks if B is equal to . If not equal, the smart card aborts the protocol. Otherwise, it retrieves the current timestamp T, chooses a random number r ∈ , and computes: After the computations, the smart card sends the message M1 = 〈ID〉 to the sensor S.

Upon receiving M1 from U, the sensor S retrieves the current timestamp T′ and verifies the freshness of U's timestamp T by checking that: where ΔT is the maximum allowed time difference between T and T′. If T is not fresh, S rejects U's request and aborts the protocol. Otherwise, S checks if ω is equal to the hash value h(ID‖h(IDs‖h(x ⊕ y)) ‖ T). If they are not equal, S aborts the protocol. Otherwise, S generates a random number r ∈ retrieves the current timestamp T, and computes: Then, S sends the message M2 = 〈ID〉 to the gateway GW.

After receiving M2, GW retrieves the current timestamp T″ and verifies the freshness of the timestamp T by checking that T″ − T ≤ ΔT. If T is not fresh, GW aborts the protocol. Otherwise, GW computes X′ = h(ID‖x) × X and checks if α equals h(ID‖ID‖X‖X′‖T‖ω) and β equals h(SK‖ID‖X‖T‖α‖ω‖ID‖Y‖T). If either of the checks fails, GW aborts the protocol. Otherwise, GW retrieves the current timestamp T and computes: Then, GW sends M3 = 〈T〉 to the sensor S.

Having received M3, S retrieves the current timestamp T‴ and checks if T‴ − T ≤ ΔT and γ = h(SK‖ID‖X‖T‖α‖ID‖Y‖T‖T) Only if both the checks hold, S retrieves the new timestamp and computes: Then, S sends M4 = 〈Y, T, , δ, τ〉 to the user U.

With M4 in hand, U retrieves the current timestamp T⁗, computes K = r × Y, and checks if (1) T⁗− T′ ≤ ΔT; (2) δ = h(ID‖X‖X′ ‖T‖ID‖Y‖T); and (3) . If any of the checks fail, U aborts the protocol. Otherwise, U computes:

Our protocol allows users to freely update their passwords. The password update phase works as follows (see also Figure 9):

Figure 9.

The password update phase.

The user U inserts its smart card into a smart card reader and enters the identity ID, the old password pw, and the new password pw′.

The smart card computes , , and and checks if B′ is equal to B. If they are not the same, the password update phase stops. Otherwise, the smart card computes: and replaces A and W with A′ and W′, respectively.

Performance Comparison

Table 3 compares our improved protocol with Yeh et al.'s protocol [2] and Shi et al.'s protocol [3] in terms of the computational costs required by the protocols. The efficiency comparison is based on theoretical analysis and experimental results [3,27-29].

Table 3.

Efficiency comparison.

Protocol	Computational Cost
	User	Sensor	Gateway
Yeh et al.'s protocol	2M +1R+1A+4H	2M +1R +1A+ 1P +1H	3M +1R+1P + 1H
Shi et al.'s protocol	3M +5H	2M +3H	1M +4H
Our protocol	3M +7H	2M +4H	1M +4H

Notations used in Table 3 are described as follows:

The computational costs of generating a random point and evaluating a map-to-point hash function are about half the cost of performing a scalar-point multiplication. Hash function evaluations and point addition operations are often ignored in cost estimates since they are much faster than scalar-point multiplications. If we ignore hash function evaluations, the computational costs described in Table 3 can be estimated as in Table 4.

Table 4.

Estimated efficiency comparison.

Protocol	Computational Cost
	User	Sensor	Gateway
Yeh et al.'s protocol	2.5M	3M	3M
Shi et al.'s protocol	3M	2M	1M
Our protocol	3M	2M	1M

As shown in Tables 3 and 4, our proposed protocol and Shi et al.'s protocol are more efficient than Yeh et al.'s protocol, in terms of the computational costs of the sensor and the gateway. In WSNs, it is important to minimize the energy consumption of the sensor node. In this sense, it is fair to say that our protocol and Shi et al.'s protocol are better suited for WSNs than Yeh et al.'s protocol. The performance of our proposed protocol is similar to that of Shi et al.'s protocol. But, as we demonstrated in Section 4, Shi et al.'s protocol is vulnerable to a session key attack, a stolen smart card attack, and a sensor energy exhausting attack. Consequently, we can say that our protocol enhances the security of Shi et al.'s protocol while maintaining the efficiency of the protocol.

Security Analysis and Verification

In this section, we first provide a heuristic security analysis for the proposed protocol and then formally verify the security analysis by using Rubin logic.

Heuristic Security Analysis

Stolen-Verifier Attack

In WSNs, an attacker may attempt to mount a stolen-verifier attack if the gateway stores a password verifier [30] and then, impersonate a legal user using the verifier stolen from the gateway. However, in our protocol, the gateway does not store a password verifier of any kind but stores only the master secret keys x and y which are used in computing:

Insider Attack

An insider attack occurs when the gateway manager or system administrator can access a user's secret (e.g., user password) and then impersonate the user. However, in our protocol, the user U does not send a plain password to the gateway, but sends only the password-derived hash value . Since b is a sufficiently high-entropy random number, the gateway cannot learn the password pw from the hash value . In addition, the gateway does not manage any table for storing user passwords or their verifiers (e.g., an ID/password table) Therefore, an insider attack is not possible against our protocol.

Replay Attack

In our protocol, each of the protocol messages (M1, M2, M3 and M4) accompanies at least one of the authenticators (α, β, γ, δ, τ and ω) which are generated using a timestamp (T or T) as part of the hash input. The protocol participants (U, S and GW) verify the authenticity of incoming messages by checking the freshness of the timestamps and the legitimacy of the authenticators. But, an attacker cannot compute any of the authenticators for a fresh timestamp without knowing an appropriate secret. Therefore, our proposed protocol is secure against replay attacks.

Man-in-the-Middle Attack

It is impossible for an attacker to mount a man-in-the-middle attack against our proposed protocol. In a typical man-in-the-middle attack, an attacker intercepts the messages being exchanged between the communicating parties and instead, sends arbitrary messages for its own benefit impersonating one of them to the other. But, our protocol allow the parties to authenticate all the protocol messages with the authenticators α, β, γ, δ, τ and ω, and therefore, is secure against man-in-the-middle attacks.

Gateway Impersonation Attack

An attacker cannot impersonate the gateway because it cannot forge the message:

To generate γ or δ, one needs to know either SK or h(ID‖x). However, h(ID‖x) is the secret shared only between the user and the gateway while SK is the secret shared between the sensor and the gateway. Therefore, it is impossible for an attacker to mount a gateway impersonation attack.

User Impersonation Attack

It is impossible for an attacker to impersonate the user as it cannot forge the message:

The attacker should know X′ to compute α and should know h(x ⊕ y) to compute ω. But, the attacker knows neither X′ nor h(x ⊕ y) and therefore, cannot mount a user impersonation attack.

Sensor Impersonation Attack

An attacker cannot impersonate the sensor because it can forge the messages M2 = 〈ID〉 and M4 = 〈Y, T〉. The attacker cannot compute β without knowing SK and cannot compute δ without knowing the secret h(ID‖x). But, the attacker knows neither SK nor x and therefore, cannot mount a sensor impersonation attack.

Mutual Authentication

Mutual authentication is an important security property that an authentication protocol should achieve [31,32]. Our proposed protocol provides mutual authentication among the three parties: the user, the sensor and the gateway.

The gateway authenticates the user using α in M2.

The gateway authenticates the sensor using β in M2.

The sensor authenticates the gateway using γ in M3.

The user authenticates the gateway using δ in M4.

The user and the sensor authenticate each other via δ from the gateway.

This means that our protocol achieves mutual authentication.

Perfect Forward Secrecy

Perfect forward secrecy means that a session key derived from a set of long-term keys will not be compromised even if one of the long-term keys is compromised in the future. The proposed protocol uses the session key sk = h(X‖Y‖r × X) for the sensor and sk = h(X‖Y‖r × Y) for the user. Even though h(ID‖x) and x are compromised, an attacker cannot know r or r. Under the assumption that the ECCDHP problem is hard, the attacker cannot compute r from r × X and r from r × Y. Therefore, our protocol provides perfect forward secrecy.

Key Agreement

The proposed protocol provides key agreement between the user and the sensor. To the session-key computation, the user contributes its random number r while the sensor contributes its random number r. It is straightforward to verify that K and K are equal:

Since K = K, it is clear that the user and the sensor compute session keys of the same value:

Session Key Attack

In our protocol:

α is combined with two identities ID and ID, which indicates that the user U wants to communicate with the sensor S,

δ is also combined with ID and ID, which indicates that the gateway has authenticated both the user ID and the sensor ID.

But, no attacker can compute α and δ, and therefore, can share a session key with the user.

Stolen Smart Card Attack

In Shi et al.'s protocol, the attacker can obtain b and B from the smart card and thus can use B = h(ID ⊕ h(pw ⊕ b)) as the password verifier in its offline dictionary attack. However, in our protocol, B is computed as . Even if the attacker obtains b and B from the smart card, it cannot use B as a password verifier since it does not know the hash value h(x ⊕ y). Therefore, no attacker can mount an offline dictionary attack against our protocol.

Sensor Energy Exhausting Attack

In Shi et al.'s protocol, the sensor has to generate a random number and execute a scalar-point multiplication whenever it receives the message M1 from the user. Random number generations and scalar-point multiplications are expensive and exhaust a large amount of the sensor's energy. This makes Shi et al.'s protocol vulnerable to a sensor energy exhausting attack. However, in our protocol, the sensor first checks the validity of ω = h(ID‖h(ID‖h(x ⊕ y))‖T) before generating a random number and performing a scalar-point multiplication. Checking the validity of ω only requires one hash function evaluation. Therefore, our proposed protocol is secure against a sensor energy exhausting attack.

Table 5 summarizes and compares the security of our protocol, Yeh et al.'s protocol, and Shi et al.'s protocol.

Table 5.

Security comparison.

Attack and Security Property	Yeh et al.'s Protocol	Shi et al.'s Protocol	Our Protocol
Stolen-verifier attack	Secure	Secure	Secure
Insider attack	Secure	Secure	Secure
Replay attack	Secure	Secure	Secure
Man-in-the-middle attack	Secure	Secure	Secure
Gateway impersonation attack	Secure	Secure	Secure
User impersonation attack	Secure	Secure	Secure
Sensor impersonation attack	Insecure	Secure	Secure
Mutual authentication	No	Yes	Yes
Perfect forward secrecy	No	Yes	Yes
Key agreement between user and sensor	No	Yes	Yes
Session key attack	Insecure	Insecure	Secure
Stolen smart card attack	Insecure	Insecure	Secure
Sensor energy exhausting attack	Insecure	Insecure	Secure

Rubin Logic Verification

We analyze the proposed protocol using Rubin logic which can be applicable in analyzing an authentication protocol. Rubin logic integrates protocol analysis with specification and uses the notions of global sets, local sets, and actions. As the protocol run is progressed, the possession and belief sets (specified by local sets) are modified for each principal by inference rules (specified by global sets) and actions [33,34]. As the possession and belief sets are modified, secret set and observers sets (specified by global sets) are modified as well.

Global Sets

The first step of the specification of any protocol using Rubin logic is to instantiate the global sets with values. Global sets are public to each principal in a protocol specification.

Principal Set: This set contains the principals who participate in a protocol.

Rule Set: This set contains inference rules for deriving new statements from existing assertions.

Secret Set: This set contains all of the secrets that exist at any given time in the system.

Observers Sets: For each secret, its set contains all the principals who could possibly know the secret by listening to network traffic or generating it themselves.

Local Sets

Local sets are private to each principal in a protocol specification [35]. For each principal, P, Rubin logic defines the following sets:

Possession Set(P): This set contains all the data relevant to security that this principal knows or possesses. We denote this set by POSS(P) = (poss1, poss2, ⋯, poss).

Belief Set(P): This set contains all the beliefs hold by a principal. For example, the keys it holds between itself and other principals, beliefs about jurisdiction, beliefs about freshness, and beliefs about the possessions of other principals. We denote this set by BEL(P) = (bel1, bel2, ⋯, beln).

Behavior List(P): This item is a list rather than a set because the elements are ordered. BL(P) = Behavior List of P.

Actions

Rubin logic defines actions for dealing with the knowledge in a protocol [36]. The action lists that precede and follow message operations in a principal's behavior list determine a sequence of events performed by the principal during a protocol run. We use the following actions:

Generate-nonce(N)

Send(P)

Receive(P)

Update(X)

Forget(X)

Concat(X1, X2, ⋯,X)

XOR(X1, X2, ⋯,X)

Check(X1, X2, ⋯, X)

Scalar-multiplication(X1, X2, ⋯, X)

Hash(h(·); X1, X2, ⋯, X)

Check-freshness(T)

Here, Concat(X1, X2, ⋯, X) is the action that concatenates the submessages X1, X2, ⋯, X.

Protocol Specification

Notations used for the protocol specification is the same as those in Table 2. Phases 1, 2 and 3 represent the registration phase, the login and authentication phase, and the password updated phase. The global and local sets for the protocol are specified as follows:

Global Sets

The global sets are specified as follows:

Principal set: A principal is one of U, S and GW. U is the protocol initiator.

Rule set:

X contains Y: Y appears as a submessage of X.

S ≔← f(S): S is replaced by the value f(S).

X from E: X is received from E.

LINK(N): LINK is used to link responses to challenges. When a principal generates a nonce, N, the formula LINK(N) is added to the belief set of the principal.

Secret Set: {pw(x ⊕ y), SK}

Observers Sets:

Observers(pw): {U}

Observers(b): {U}

Observers(x): {GW}

Observers (y): {GW}

Observers(h(x ⊕ y)): {S}

Observers(SK): {S}

Local Sets

The local sets are defined for each U, S and GW. Tables 67 and 8 show the specification of the local sets for U, S and GW, respectively.

Table 6.

Local sets specification for principal U.

Principal U
POSS(U) = {pwU, bU, {IDU}}	(U16) Update(IDU, IDSn, X, TU, α, ω)
BEL(U) = {#(pwU), #(bU)}	(U17) Receive(Sn, {Y, TS, δ, τ})
BL(U)	(U18) Check-freshness(T′S)
Phase 1	(U19) Check (δ, Hash(h(·); Contat(IDU, X, X′,TU, IDSn, Y, TS)))
(U1) pw¯_U←Hash(h(⋅);XOR(pw_U,b_U))
(U2) Send (GW,{IDU, pw¯_U})	(U20) KUS ← Scalar-multiplication(rU, Y)
(U3) Update(IDU, pw¯_U)	(U21) Check(τ, Hash(h(·); Contat(Y, T′S, δ, KUS)))
(U4) Receive(GW, {AU, BU, WU, h(·)})	(U22) sk ← Hash(h(·); Contat(X, Y, KUS))
Phase 2	Phase 3
(U5) pw¯_U←Hash(h(⋅);XOR(pw_U,b_U))	(U23) pw¯_U←Hash(h(⋅);XOR(pw_U,b_U))
(U6) h(x⊕y) ← XOR( pw¯_U, AU)	(U24) B′U ← Hash(h(·); Concat (IDU, pw¯_U, h(x(⊕ y))
(U7) B′U ← Hash(h(·);Concat (IDU, pw¯_U, h(x⊕y)))	(U25) Check(B′U, BU)
(U8) Check(B′U, BU)	(U26) KU ← XOR(Hash(h(·); Concat(IDU, pw¯_U)), WU)
(U9) KU ← XOR(Hash(h(·); Concat(IDU, pw¯_U)),WU)	(U27) h(x(⊕ y) ← XOR( pw¯_U, AU)
(U10) Generate-nonce(rU)	(U28) pw′¯_U←Hash(h(⋅);XOR(pw′_U,A_U))
(U11) X ← Scalar-multiplication(rU, P)	(U29) A′U ← XOR ( pw¯_U, h(x ⊕ y))
(U12) X′ ← Scalar-multiplication(rU, KU)	(U30) B′U ← Hash(h(·); Concat(IDU, pw^′¯_U, h(x(⊕ y)))
(U13) ω ← Hash(h(·); Concat(IDU, Hash(h(·);IDSn, h(x ⊕ y)), TU))	(U31) W′U ← XOR(Hash(h(·); Concat(IDU, pw^′¯_U)), KU)
	(U32) AU ← A′U
(U14) α ← Hash(h(·); Concat(IDU, IDSn, X, X′, TU,ω))	(U33) BU ← B′U
(U15) Send(Sn, {IDU, IDSn, X, TU, α, ω})	(U34) WU ← W′U

Table 7.

Local sets specification for principal S.

Principal Sn
POSS(Sn) = {SKGS, h(x ⊕ y), {IDSn}}	(SN7)
BEL(Sn) = {#(SKGS), #(h(x ⊕ y))}	Send(GW, {IDU, X, TU, α, ω, IDSn, Y, TS, β})
BL(Sn)	(SN8) Update(IDU, X, TU, α, ω, IDSn, Y, TS, β)
Phase 2	(SN9) Receive(GW, {TG, γ, δ})
(SN1) Receive(U, {IDU, IDSn, X, TU, α, ω})	(SN10) Check-freshness(TG)
(SN2) Check-freshness(TU)	(SN11) Check
(SN3) Check	(γ,Hash(h(·); Concat(SKGS,IDU,X,TU,α,IDSn,Y,TS,TG)))
(ω, Hash(h(·);Concat(IDU,Hash(h(·);IDSn,h(x ⊕ y)),TU)))	(SN12) KSU ← Scalar-multiplication(rS, X)
(SN4) Generate-nonce(rS)	(SN13) τ ← Hash(h(·); Concat(Y, T′S, δ, KSU))
(SN5) Y ← Scalar-multiplication(rS, P)	(SN14) sk ← Hash(h(·); Contat(X, Y, KSU))
(SN6) β ← Hash	(SN15) Send(U, {Y, TS, T′S, δ, τ})
(h(·); Concat (SKGS, IDU, X, TU, α, ω, IDSn, Y, TS))	(SN16) Update(Y, TS,T′S,δ, τ)

Table 8.

Local sets specification for principal GW.

Principal GW
POSS(GW) = {x, y, h(x ⊕ y), SKGS}	Phase 2
BEL(GW) = {#(x), #(y), #(h(x ⊕ y)), #(SKGS)}	(GW9) Receive(Sn, {IDU, X, TU, α, ω, IDSn, Y, TS, β})
BL(GW)	(GW10) Check-freshness(TS)
Phase 1	(GW11) Check (β, Hash(h(·); Concat(SKGS, IDU, X, TU, α, ω, IDSn, Y, TS)))
(GW1) Received(U, {IDU, pw¯_U)
(GW2) KU ← Scalar-multiplication(Hash(h(·); Concat(IDU, x)), P)	(GW12) X′ ← Scalar-multiplication(Hash(h(·); Concat(IDU, x)), X)
(GW3) AU ← XOR ( pw¯_U, h(x ⊕ y))	(GW13)
(GW4) BU ← Hash(h(·); Concat(IDU, pw¯_U, h(x ⊕ y)))	Check(α, Hash(h(·); Concat(IDU, IDSn, X, X′, TU, ω)))
(GW5)	(GW14) γ ←
WU ← XOR(Hash(h(·); Concat(IDU, pw¯_U)), KU)	Hash(h(·); Concat(SKGS, IDU,X,TU,α,IDSn,Y,Ts,TG))
(GW6) Send(U, {AU, BU, WU, h(·)})	(GW15) δ ← Hash(h(·);Contat(IDU, X, X′, TU, IDSn, Y, TS))
(GW7) Update(AU, BU, WU, h(·))	(GW16) Send(Sn, {TG, γ, δ})
(GW8) Forget(IDU, pw¯_U, AU, BU, KU, WU)	(GW17) Update(TG, γ, δ)

Analysis and Verification

In phase 1, U initiates the protocol, and then the actions in BL(U) are performed. Firstly, (U1)–(U3) actions in BL(U) are performed, which represent that U sends ID and to GW for registration. Next, (GW1)–(GW8) actions in BL(GW) are performed to generate A and W, and to send them to U. By (GW8), GW deletes ID, , A and W from POSS(GW) and BEL(GW). Lastly, the (U4) action in BL(U) is executed, then phase 1 is finished. Due to the (GW8) forget action, the local sets of GW are not changed. However, the local sets of principal U are changed as described below.

POSS(U) = {pw, , {ID}, {A(·)} from GW}

BEL(U) = {#(pw), #(b), #( )}

Accordingly, the global sets are modified as follows:

Secret set: {pw, , x, y, SK(x ⊕ y)}

Observers sets:

Observers ( ): {U}

In the (U5)–(U8) actions in BL(U) of phase 2, the smart card authenticates U, who inputs ID and pw, by checking whether B and are same or not. Next, the (U9)–(U15) actions are executed to generate the protocol values X, X′, h(x ⊕ y), ω, α and r. After the (U16) update action, the local sets of U are changed as follows:

POSS(U) = {ID, , X, X′, h(x ⊕ y), T, {ID}}

BEL(U) = {#(pw), #(b), #(r), #( ), #(X′), #(h(x ⊕ y)), #(T), LINK(r)}

Then, the global sets are modified as follows:

Secret set: {pw, , x, y, X′, SK(x ⊕ y)}

Observers sets:

Observers(X′): {U}

Observers(h(x ⊕ y)): {U}

After the (U5)–(U16) actions are finished, S starts the actions in BL(S) with the incoming message M1 from U. The (SN1)–(SN3) actions in BL(S) are performed to verify the correctness of message M1. If the check succeeds, the (SN4)–(SN8) actions are performed to make the values Y, β and r, and to send the message M2. The local sets of S are changed as follows.

POSS(S) = {Y, T(x ⊕ y), {ID}, {ID} from U}

BEL(S) = {#(r), #(SK), #(h(x ⊕ y)), #(T), LINK(r)}

In this case, the global sets remain unchanged and thus, the secret set is the same as above:

Secret set: {pw, , x, y, X′, SK(x ⊕ y)}

After (SN1)–(SN8) actions of BL(S) are finished, (GW9)–(GW17) actions of BL(GW) are executed. (GW9)–(GW13) actions check the timestamp of S, and then verify the legitimacy of U and S. If they are correct, (GW14)–(GW17) actions of BL(S) are executed to make values(γ, δ) for authentication and send message. γ is used for authentication with S and δ is used for authentication with U.

After the (SN1)–(SN8) actions are done, the (GW9)–(GW13) actions in BL(GW) are performed to check the legitimacy of U and S. If the verification succeeds, the (GW14)–(GW17) actions are performed to generate γ and δ and to send the message M3 to S. The local sets of GW are modified as shown below.

POSS(GW) = {T(x ⊕ y), {ID} from S}

BEL(GW) = {(#(x), #(y), #(X′), #(SK), #(h(x ⊕ y)), #(T)}

The global sets are updated as follows:

Secret set: {pw, , x, y, X′, SK(x ⊕ y)}

Observers sets:

Observers(X′) = {GW}

After the (GW9)–(GW17) actions are finished, the (SN9)-(SN11) actions in BL(S) are conducted to verify the legitimacy of GW and U via the authenticator γ. If the verification process is completed, the (SN12)–(SN16) actions are performed to generate τ and sk from r and Y, and to send the message M4 to U. The local sets of S is updated as follows:

POSS(S) = {Y, , K, {ID},{T} from GW}

BEL(S) = {#(K), #(sk), #(SK), #( ), LINK (r)}

Accordingly, the global sets are modified as follows:

Secret set: {pw, , x, y, K(x ⊕ y)}

Observers sets:

Observers (K) = {S}

Observers(sk) = {S}

The (U17)–(U19) actions in BL(U) are to check the legitimacy of GW and S while the (U20)–(U22) actions are to generate the session key sk from r and Y. So, the conditions for the linkage rule are satisfied.

POSS(U) = {K, {ID}, {Y, , δ, τ} from S}

BEL(U) = {#(K), #(X′), #(sk), #(h(x ⊕ y)}

Secret set: {pw, , x, y, K, (x ⊕ y)}

Observers sets:

Observers (K) = {U}

Observers(sk) = {U}

In phase 3, U changes its password and updates A and W stored in the smart card. In this phase, the local sets of U and the global sets remain unchanged.

The following shows the final version of the global sets.

Secret set: {pw, , x, y, K(x ⊕ y)}

Observers sets:

Observers (pw): {U}

Observers (b): {U}

Observers( ): {U}

Observers(x): {GW}

Observers(y): {GW}

Observers (K): {S}

Observers (K): {U}

Observers(sk): {U, S}

Observers(X′): {U,GW}

Observers(SK): {S}

Observers(h(x ⊕ y)): {U, S}

This result implies that:

pw and are known only to the user U.

x and y are known only to the gateway GW.

The long-term key SK shared between S and GW is not exposed.

X′ is only known to U and GW.

K and K are only available to U and S.

The session key sk is securely shared between U and S.

h(x ⊕ y) is only known to the authorized principals: U, S and GW.

U, S and GW are mutually authenticated during the protocol execution.

This verifies the security claims we made in the previous subsection.

Conclusions

In this paper, we have identified that Shi et al.'s ECC-based authentication protocol designed for wireless sensor networks (WSNs) is vulnerable to: a session key attack, a stolen smart card attack, and a sensor energy exhausting attack. We have also proposed a new authentication protocol that addresses the identified security weaknesses. Our proposed protocol is as efficient as Shi et al.'s protocol and is better suited for WSNs than Yeh et al.'s protocol, the predecessor of Shi et al.'s protocol. As for the security of the proposed protocol, we have provided a heuristic analysis and formally verified the analysis using Rubin logic.