<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD Journal Publishing DTD v2.3 20070202//EN" "journalpublishing.dtd">
<article xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" xml:lang="en" article-type="research-article">
<front>
<journal-meta>
<journal-id journal-id-type="nlm-ta">Sensors</journal-id>
<journal-title>Sensors</journal-title>
<issn pub-type="epub">1424-8220</issn>
<publisher>
<publisher-name>Molecular Diversity Preservation International (MDPI)</publisher-name></publisher></journal-meta>
<article-meta>
<article-id pub-id-type="doi">10.3390/s110505020</article-id>
<article-id pub-id-type="publisher-id">sensors-11-05020</article-id>
<article-categories>
<subj-group>
<subject>Article</subject></subj-group></article-categories>
<title-group>
<article-title>RUASN: A Robust User Authentication Framework for Wireless Sensor Networks</article-title></title-group>
<contrib-group>
<contrib contrib-type="author">
<name><surname>Kumar</surname><given-names>Pardeep</given-names></name><xref ref-type="aff" rid="af1-sensors-11-05020"><sup>1</sup></xref></contrib>
<contrib contrib-type="author">
<name><surname>Choudhury</surname><given-names>Amlan Jyoti</given-names></name><xref ref-type="aff" rid="af1-sensors-11-05020"><sup>1</sup></xref></contrib>
<contrib contrib-type="author">
<name><surname>Sain</surname><given-names>Mangal</given-names></name><xref ref-type="aff" rid="af1-sensors-11-05020"><sup>1</sup></xref></contrib>
<contrib contrib-type="author">
<name><surname>Lee</surname><given-names>Sang-Gon</given-names></name><xref ref-type="aff" rid="af2-sensors-11-05020"><sup>2</sup></xref><xref ref-type="corresp" rid="c1-sensors-11-05020"><sup>*</sup></xref></contrib>
<contrib contrib-type="author">
<name><surname>Lee</surname><given-names>Hoon-Jae</given-names></name><xref ref-type="aff" rid="af2-sensors-11-05020"><sup>2</sup></xref></contrib></contrib-group>
<aff id="af1-sensors-11-05020">
<label>1</label> Department of Ubiquitous-IT, Graduate School of Design &amp; IT, Dongseo University, Sasang-Gu, Busan 617-716, Korea; E-Mails: <email>pradeepkhl@gmail.com</email> (P.K.); <email>choudhuryamlanjyoti@gmail.com</email> (A.J.C.); <email>mangalsain1@gmail.com</email> (M.S.)</aff>
<aff id="af2-sensors-11-05020">
<label>2</label> Division of Computer &amp; Information Eng, Dongseo University. San 69-1, Jurye-2-Dong, Sasang-Gu, Busan 617-716, Korea; E-Mail: <email>hjlee@dongseo.ac.kr</email></aff>
<author-notes>
<corresp id="c1-sensors-11-05020">
<label>*</label>Author to whom correspondence should be addressed; E-Mail: <email>nok60@dongseo.ac.kr</email>; Tel.: +82-51-320-1730; Fax: +82-51-327-8955.</corresp></author-notes>
<pub-date pub-type="collection">
<year>2011</year></pub-date>
<pub-date pub-type="epub">
<day>4</day>
<month>5</month>
<year>2011</year></pub-date>
<volume>11</volume>
<fpage>5020</fpage>
<lpage>5046</lpage>
<history>
<date date-type="received">
<day>25</day>
<month>2</month>
<year>2011</year></date>
<date date-type="rev-recd">
<day>17</day>
<month>4</month>
<year>2011</year></date>
<date date-type="accepted">
<day>20</day>
<month>4</month>
<year>2011</year></date></history>
<permissions>
<copyright-statement>© 2011 by the authors; licensee MDPI, Basel, Switzerland.</copyright-statement>
<copyright-year>2011</copyright-year>
<license>
<p>This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution license (http://creativecommons.org/licenses/by/3.0/).</p></license></permissions>
<abstract>
<p>In recent years, wireless sensor networks (WSNs) have been considered as a potential solution for real-time monitoring applications and these WSNs have potential practical impact on next generation technology too. However, WSNs could become a threat if suitable security is not considered before the deployment and if there are any loopholes in their security, which might open the door for an attacker and hence, endanger the application. User authentication is one of the most important security services to protect WSN data access from unauthorized users; it should provide both mutual authentication and session key establishment services. This paper proposes a robust user authentication framework for wireless sensor networks, based on a two-factor (<italic>password and smart card</italic>) concept. This scheme facilitates many services to the users such as user anonymity, mutual authentication, secure session key establishment and it allows users to choose/update their password regularly, whenever needed. Furthermore, we have provided the formal verification using Rubin logic and compare RUASN with many existing schemes. As a result, we found that the proposed scheme possesses many advantages against popular attacks, and achieves better efficiency at low computation cost.</p></abstract>
<kwd-group>
<kwd>wireless sensor network security</kwd>
<kwd>user authentication</kwd>
<kwd>user anonymity</kwd>
<kwd>session key establishment</kwd>
<kwd>confidentiality</kwd></kwd-group></article-meta></front>
<body>
<sec sec-type="intro">
<label>1.</label>
<title>Introduction</title>
<p>Wireless sensor networks (WSNs) are becoming more and more popular in everyday life as they offer economically viable, real time monitoring solutions. These wireless sensors can be quickly and easily deployed in hostile environments, and WSNs are now widely used in a variety of real-time applications, such as vehicular tracking, habitat monitoring, environment control, military surveillance, healthcare monitoring, wildlife monitoring and traffic monitoring. One recent survey declared that, in the near future, WSNs will become an intelligent and integral part of daily lives [<xref ref-type="bibr" rid="b1-sensors-11-05020">1</xref>].</p>
<p>A WSN consists of a discrete group of independent, low cost, low power nodes with limited memory and computation power. They communicate wirelessly over limited frequency and low bandwidth [<xref ref-type="bibr" rid="b1-sensors-11-05020">1</xref>]. More specifically, sensor nodes collectively monitor the area and sense substantial amounts of data, which are transmitted to the base-station traversing some nodes via RF signals and routing schemes.</p>
<p>As sensor nodes are resource constrained devices and are often deployed in a hostile environment and have to sense the information properly and efficiently. So the potential deployment of WSNs for any real-time applications has to deal with many challenges, including security, system architecture and protocol functionalities. Providing security to these resource hungry sensor networks is a very tedious task as compared to conventional networks, such as local area networks (<italic>LANs</italic>) and wide area networks (<italic>WANs</italic>). Consequently, providing suitable security has emerged as one of the critical issue in wireless sensor networks, and the state-of-art should therefore pay attention to how to deploy user-friendly, reliable and secure WSNs.</p>
<p>In real-time WSNs, sensor data queries are commonly issued from the base-station nodes or the backend application system. Moreover, these sensor networks can be accessed from anywhere in an <italic>ad-hoc</italic> manner. As sensor nodes provide services to users by themselves, it is necessary to control who is accessing the information and whether the intended user is authenticated to do so. Therefore, access control is a core requirement for WSNs to protect the data from access by unauthorized parties. In general user authentication where each user must verify their legitimacy is considered as one of the basic solutions for the access control issue.</p>
<p>So far, a number of significant schemes that provide adequate security for wireless sensor networks at the link layer [<xref ref-type="bibr" rid="b2-sensors-11-05020">2</xref>–<xref ref-type="bibr" rid="b6-sensors-11-05020">6</xref>] and the network layer [<xref ref-type="bibr" rid="b7-sensors-11-05020">7</xref>] have been proposed. However, secure user authentication at the application layer has not been addressed effectively in order to prevent illegal access to sensor data. A review of current literature on WSNs reveals that only a few user authentication schemes have been adequately addressed [<xref ref-type="bibr" rid="b8-sensors-11-05020">8</xref>–<xref ref-type="bibr" rid="b22-sensors-11-05020">22</xref>] at the application layer. In [<xref ref-type="bibr" rid="b8-sensors-11-05020">8</xref>–<xref ref-type="bibr" rid="b14-sensors-11-05020">14</xref>], protocols are based on traditional passwords, where secrets are stored at the base station or the gateway. While, the protocols presented in [<xref ref-type="bibr" rid="b18-sensors-11-05020">18</xref>–<xref ref-type="bibr" rid="b21-sensors-11-05020">21</xref>] are based on two-factor user authentication with limited functionality (e.g., <italic>no mutual authentication</italic>, <italic>no secure session key</italic>, and <italic>no confidentiality</italic>) at high computation cost. Therefore, one of the primary concerns in wireless sensor network applications is the design and development of a robust user authentication scheme which is suitable for hostile or unattended environments.</p>
<p>In this paper, we have considered the above challenges and present a robust user authentication framework for wireless sensor networks (RUASN) at the application layer, which uses the two factor approach. The first factor (<italic>something you know</italic>) refers to something that is known by the user, such as a password, while the second factor (<italic>something you have</italic>) refers that something that is embedded on a device, such as smart cards, software tokens, digital certificates or biometric identifiers (e.g., <italic>fingerprint scans</italic> and so on) [<xref ref-type="bibr" rid="b23-sensors-11-05020">23</xref>].</p>
<p>The proposed RUASN framework achieves user authentication (<italic>access control</italic>) for wireless sensor networks, where a user must login with same identity. The proposed scheme is resists many popular attacks, such as replay attack, impersonation attack, insider attack, stolen-verifier attack, password guessing attack, and man-in-the-middle attack. RUASN provides user privacy protection (<italic>i.e.</italic>, <italic>user anonymity</italic>), mutual authentication, and secure session key establishment. In addition, a user can update his/her password whenever demanded. Our framework uses one-way hash functions along with XOR operations to attain low computational overheads. Moreover, this paper further demonstrated the analysis and verification of the proposed protocol using Rubin Logic [<xref ref-type="bibr" rid="b24-sensors-11-05020">24</xref>], which is very close to actual implementation.</p>
<p>The rest of the paper is structured as follows: Section 2 briefly reviews the related literature and the perceived weaknesses of existing schemes. In Section 3 we discuss the design goals, security requirements and system architecture of RUASN. In Section 4, we propose a robust two-factor user authentication framework in detail. Section 5 discusses the nonmonotonic cryptographic protocol and formal verification of proposed protocol using Rubin Logic. Section 6 discusses the security analysis, efficiency evaluation and comparison with existing schemes for wireless sensor networks. Finally, Section 7 conclusions are drawn for RUASN.</p></sec>
<sec>
<label>2.</label>
<title>Literature Review</title>
<p>In this section, we will discuss the literature on user authentication schemes that have been recently proposed to verify the legitimacy of wireless sensor networks users.</p>
<p>Benenson <italic>et al</italic>. [<xref ref-type="bibr" rid="b8-sensors-11-05020">8</xref>] first described several security issues in WSNs, especially the access control problem, and proposed the notion of <italic>n</italic>-authentication, where users can successfully authenticate with at least (<italic>n-t</italic>) of n-sensors, where <italic>t</italic> is the number of sensor nodes that the adversary can compromise. Subsequently, Benenson <italic>et al</italic>. [<xref ref-type="bibr" rid="b9-sensors-11-05020">9</xref>] proposed another solution for the user authentication problem in the face of node capture attacks. The proposed scheme is based on public key cryptography (<italic>PKC</italic>) and elliptic curve cryptography (<italic>ECC</italic>). Some major weaknesses were pointed out in the Benenson <italic>et al</italic>. scheme, such as the fact that impersonation attacks or denial-of-service (<italic>DoS</italic>) attacks could be mounted by sending many bogus signatures during the authentication phase [<xref ref-type="bibr" rid="b10-sensors-11-05020">10</xref>]. Moreover, the computation cost of <italic>PKC</italic> and <italic>ECC</italic> is very high for sensor networks.</p>
<p>Wong <italic>et al</italic>. [<xref ref-type="bibr" rid="b10-sensors-11-05020">10</xref>] proposed a dynamic user authentication scheme for wireless sensor networks, which is based on passwords. This scheme imposes a very light computation cost that requires only one-way hash functions and simple <italic>XOR</italic> operations. The scheme consists of three phases: registration phase, login and authentication phase. Unfortunately, the Wong <italic>et al.</italic> scheme is vulnerable to many attacks such as replay attacks, forgery attacks, stolen-verifier attacks and password guessing attacks [<xref ref-type="bibr" rid="b11-sensors-11-05020">11</xref>,<xref ref-type="bibr" rid="b12-sensors-11-05020">12</xref>,<xref ref-type="bibr" rid="b14-sensors-11-05020">14</xref>,<xref ref-type="bibr" rid="b18-sensors-11-05020">18</xref>].</p>
<p>Vaidya <italic>et al</italic>. [<xref ref-type="bibr" rid="b14-sensors-11-05020">14</xref>] pointed out some weaknesses of the Tseng <italic>et al</italic>. [<xref ref-type="bibr" rid="b11-sensors-11-05020">11</xref>], Wong <italic>et al</italic>. [<xref ref-type="bibr" rid="b10-sensors-11-05020">10</xref>] and Ko [<xref ref-type="bibr" rid="b14-sensors-11-05020">14</xref>] schemes such as replay of account-login attacks, man-in-the-middle (<italic>MITM</italic>) attacks, forgery attacks and stolen-verifier attack with node capture attacks. They proposed two user authentication schemes for wireless sensor networks, which are based on traditional password schemes and claimed that their proposed scheme provides better security features as compared to the Wong <italic>et al</italic>., Tseng <italic>et al</italic>. and Ko <italic>et al</italic>. schemes.</p>
<p>Recently, Das [<xref ref-type="bibr" rid="b18-sensors-11-05020">18</xref>] pointed out some security flaws in Wong <italic>et al</italic>. [<xref ref-type="bibr" rid="b10-sensors-11-05020">10</xref>] scheme, such as the fact this scheme is vulnerable to many logged in users with the same login-id threat and also susceptible to stolen-verifier attacks. Das [<xref ref-type="bibr" rid="b18-sensors-11-05020">18</xref>] proposed a two-factor user authentication for wireless sensor networks, where the legitimate users must prove the possession of both a password and a smart card. Das [<xref ref-type="bibr" rid="b18-sensors-11-05020">18</xref>] claimed that his scheme is secure against many types of attacks (e.g., <italic>user authentication</italic>, <italic>replay</italic>, <italic>guessing</italic>, <italic>impersonation</italic>, <italic>node compromise</italic>, and <italic>stolen-verifier attacks</italic>).</p>
<p>Nyang and Lee [<xref ref-type="bibr" rid="b19-sensors-11-05020">19</xref>] noted that Das’ scheme is not practical and is vulnerable to an offline password guessing attack by insiders, node compromise attacks and does not care about other security issues, <italic>i.e</italic>., encryption and authenticity verification of query responses. Consequently they proposed an enhanced two-factor user authentication protocol for WSNs, which overcome the Das scheme’s security flaws with some additional security services such as confidentiality and authenticity of user query responses. However, their scheme also does not care about mutual authentication and there is no provision for password updates.</p>
<p>Khan and Alghathbar [<xref ref-type="bibr" rid="b20-sensors-11-05020">20</xref>] pointed out that the Das <italic>et al</italic>. [<xref ref-type="bibr" rid="b18-sensors-11-05020">18</xref>] scheme is still not secure and cannot resist many other security attacks, such as gateway-node bypass attacks, and it is vulnerable to insider attacks, as well as not facilitating mutual authentication between the gateway and the sensor nodes and there is no provision for users to change their passwords. Khan and Alghathbar [<xref ref-type="bibr" rid="b20-sensors-11-05020">20</xref>] overcome the security weaknesses of Das’ scheme and proposed an improved two-factor user authentication in WSNs, which provides protection against insider attacks, gateway bypass attacks and introduced a password change phase for users. They suggested two secret (<italic>X</italic><italic><sub>a</sub></italic> and <italic>X</italic><italic><sub>s</sub></italic>) values to be used to overcome the gateway-bypass attacks. For example, <italic>X</italic><italic><sub>a</sub></italic> is used between the user and the gateway, and <italic>X</italic><italic><sub>s</sub></italic> is used between the gateway and the sensor nodes. Furthermore, to overcome the room for insider attack, they passed hashed passwords instead of plain passwords. Their scheme also does not however provide mutual authentication between the user and the gateway.</p>
<p>More recently, He <italic>et al</italic>. [<xref ref-type="bibr" rid="b21-sensors-11-05020">21</xref>] have shown that Das’ protocol is susceptible to insider attacks, impersonation attacks and also found design weaknesses (<italic>i.e.</italic>, <italic>concerning real identity of user</italic>). Later, they proposed an enhanced two-factor user authentication scheme for WSNs that facilitates user anonymity, protection against insider attacks and allows users to change their passwords. Their scheme does not care about mutual authentication between all parties (<italic>i.e.</italic>, <italic>user</italic>, <italic>gateway</italic> and <italic>sensor</italic>). Moreover, the communication cost is quite high as compared with other schemes (see [<xref ref-type="bibr" rid="b10-sensors-11-05020">10</xref>–<xref ref-type="bibr" rid="b14-sensors-11-05020">14</xref>,<xref ref-type="bibr" rid="b18-sensors-11-05020">18</xref>–<xref ref-type="bibr" rid="b20-sensors-11-05020">20</xref>]).</p>
<p>As we have seen above, a number of user authentication schemes have been proposed in order to authenticate user legitimacy for sensor networks. These schemes are not designed properly [<xref ref-type="bibr" rid="b10-sensors-11-05020">10</xref>–<xref ref-type="bibr" rid="b14-sensors-11-05020">14</xref>] (<italic>i.e.</italic>, <italic>stored secrets at the gateway</italic>) and in [<xref ref-type="bibr" rid="b18-sensors-11-05020">18</xref>–<xref ref-type="bibr" rid="b21-sensors-11-05020">21</xref>] they do not provide essential services to the users. Consequently, we conclude that the above schemes have many security flaws and provide less security services. Thus, these security weaknesses and constrained nature of sensor nodes motivated us to design a robust user authentication framework that provides adequate security and provides users with many services, as discussed in the next section.</p></sec>
<sec sec-type="methods">
<label>3.</label>
<title>Design Goals, Security Requirements and System Architecture</title>
<p>In this section, we discuss the design goals, security requirements and system architecture for robust user authentication for wireless sensor networks.</p>
<sec sec-type="methods">
<label>3.1.</label>
<title>Design Goals and Security Requirements</title>
<p>RUASN provides transparent security service for wireless sensor networks. In this paper another goal is to design a simple and user-friendly framework, which will be suitable for real-time WSNs applications. Overall, RUASN is designed with the following characteristics:
<list list-type="simple">
<list-item>
<p><bold><italic>Proper user authentication</italic></bold>: A user must prove his/her authenticity, so that only authentic users can access the WSN data.</p></list-item>
<list-item>
<p><bold><italic>Mutual authentication</italic></bold>: Every entity (<italic>user</italic>, <italic>gateway</italic> and <italic>sensor</italic>) must be mutually authenticated; hence they can ensure the communication is only taking place between authentic entities.</p></list-item>
<list-item>
<p><bold><italic>User anonymity</italic></bold>: Since <italic>all</italic> the messages are broadcasted wirelessly, which means that an attacker may simply eavesdrop on the messages and could breach the privacy of a user, thus, the scheme must provide user anonymity.</p></list-item>
<list-item>
<p><bold><italic>Session key establishment:</italic></bold> A <italic>session</italic> key should be established between a user and sensor node, so that subsequent communication could take place securely.</p></list-item>
<list-item>
<p><bold><italic>Confidentiality:</italic></bold> It is desirable that a user authentication protocol facilitate confidentiality of messages; as a result, these confidential messages can only be used by authorized users.</p></list-item>
<list-item>
<p><bold><italic>Password update:</italic></bold> A <italic>password</italic> based user authentication scheme should provide users a password update facility so that a user can update his/her password freely.</p></list-item>
<list-item>
<p><bold><italic>Low communication and computational cost:</italic></bold> Since sensor nodes are resource constrained devices (e.g., <italic>MicaZ [<xref ref-type="bibr" rid="b25-sensors-11-05020">25</xref>]</italic>, and <italic>Telosb [<xref ref-type="bibr" rid="b26-sensors-11-05020">26</xref>]</italic>) and, in general, application functions also need room for executing their tasks. So, the scheme must be efficient in terms of communication and computational cost.</p></list-item>
<list-item>
<p><bold><italic>Robust against popular attacks:</italic></bold> Clearly, the scheme should defend against different popular attacks, such as replay, impersonation, insider, stolen-verifier, password guessing, and man-in-the-middle attacks. As a result, the scheme should be easily applicable to real-world applications.</p></list-item>
<list-item>
<p><bold><italic>User-Friendliness</italic></bold>: The system <italic>architecture</italic> should be easy to deploy for the WSN applications as well as user-friendly for non-advanced users so users can update his/her password securely according to their will.</p></list-item>
<list-item>
<p><bold><italic>Reliability</italic></bold>: From the security <italic>point</italic> of view, the gateway needs to check the validity of the users and the sensor nodes, so that reliable communication can be established between all the parties.</p></list-item></list></p>
<p>Moreover, Liao <italic>et al</italic>. [<xref ref-type="bibr" rid="b27-sensors-11-05020">27</xref>] identified some security requirements to evaluate a smart card and password based authentication protocol. Their requirements solve most of the problems in smart card oriented schemes. As sensor networks are resource constrained devices, WSN could adopt Liao <italic>et al</italic>. requirements, which are listed below:
<list list-type="simple">
<list-item>
<p>The password tables should not be stored inside the gateway.</p></list-item>
<list-item>
<p>Verification table should not be stored inside the gateway.</p></list-item>
<list-item>
<p>The password should not be transmitted as plain text over the public network.</p></list-item>
<list-item>
<p>Schemes should resist insider-attacks.</p></list-item>
<list-item>
<p>Password length should be sufficient.</p></list-item>
<list-item>
<p>The password is not exposed by the gateway administrator.</p></list-item>
<list-item>
<p>Scheme should resist offline password guessing attacks.</p></list-item></list></p></sec>
<sec>
<label>3.2.</label>
<title>System Architecture</title>
<p>Wireless sensor networks consist of a number N of low-cost sensor devices, which are scattered in a hostile environment. These sensors sense the environmental information, (e.g., <italic>humidity</italic>, <italic>pressure</italic>, <italic>and temperature</italic>) and transmit information to the users for further analysis. A user can access real-time WSN data using their mobile devices (e.g., <italic>laptop</italic>, <italic>PDA or smart-phone</italic>) through wireless communication. WSN data could be easily accessible from anywhere in ad-hoc manner. In real-time environment it is obvious that the gateway nodes and the users are able to access the sensor data directly. The basic system architecture is shown in <xref ref-type="fig" rid="f1-sensors-11-05020">Figure 1</xref>, where a user directly request to the sensor node, upon receiving user request sensor node first verify user authenticity through the gateway node.</p>
<p>After confirmation of the user’s legitimacy he/she can access the real-time sensor data. Furthermore, the gateway node provides a middle ground between the users and the sensor network.</p></sec></sec>
<sec>
<label>4.</label>
<title>RUASN: Robust User Authentication for Wireless Sensor Network</title>
<p>To solve the potential problems of user authentication for WSNs, we propose RUASN which ensures WSN data are only accessed by legitimate users. Thus, before issuing a query to a sensor node, each user must register with the gateway in a secure manner so that they can access the real time sensors’ data. Upon the successful user registration request, the gateway node personalizes a smart card for every registered user, as shown in <xref ref-type="fig" rid="f1-sensors-11-05020">Figure 1</xref>. Then, a user can submit his/her query in an authentic way and access the sensor network data at any time within an administratively configurable period [<xref ref-type="bibr" rid="b10-sensors-11-05020">10</xref>].</p>
<p>In order to execute the proposed framework, we considered that the gateway is a trusted node and it hold two master keys (<italic>x and y</italic>), which are sufficiently large for the sensor network. Before starting the system, it is assumed that the gateway and the sensor nodes share a long-term common secret key, <italic>i.e</italic>., <italic>SK</italic><italic><sub>gs</sub></italic> <italic>= h</italic>(<italic>Sn||y</italic>) using any key agreement protocol. For example, [<xref ref-type="bibr" rid="b4-sensors-11-05020">4</xref>] demonstrated that, with the careful design, D-H key agreement protocol [<xref ref-type="bibr" rid="b28-sensors-11-05020">28</xref>] and RSA public key cryptosystem [<xref ref-type="bibr" rid="b29-sensors-11-05020">29</xref>] can be easily deployed on most constrained devices. Here, <italic>h</italic>(.) is a collision free one-way hash function (<italic>i.e.</italic>, <italic>SHA-1</italic>), which has an output length of 160-bits [<xref ref-type="bibr" rid="b30-sensors-11-05020">30</xref>] and is used throughout this paper. It is assumed that some identical secure symmetric cryptosystems are publically available and stored on the user device, on the gateway and the sensor node. As a result only the users registered with the gateway have access privileges to the sensors, which share a long-term secret with the gateway. The framework is divided into four phases, namely, user registration phase, login phase, authentication phase and password update phase. For convenience <xref ref-type="table" rid="t1-sensors-11-05020">Table 1</xref> provides a list of some notations and symbols will be used throughout the rest of paper.</p>
<sec>
<label>4.1.</label>
<title>Registration Phase (RP)</title>
<p>In the registration phase, initially, each user must register with the <italic>GW</italic> node. A user <italic>U</italic><italic><sub>k</sub></italic> chooses his/her identity (<italic>ID</italic><italic><sub>k</sub></italic>). Now user <italic>U</italic><italic><sub>k</sub></italic> chooses password (<italic>PW</italic><italic><sub>k</sub></italic>) and selects an arbitrary random number <italic>r</italic> which should be sufficiently large and computes <italic>h</italic>(<italic>r ⊕ PW</italic><italic><sub>k</sub></italic>). The <italic>ID</italic><italic><sub>k</sub></italic> and <italic>PW</italic><italic><sub>k</sub></italic> should include uppercase, lower case characters and 0–9 numeric characters [<xref ref-type="bibr" rid="b32-sensors-11-05020">32</xref>]. Afterward, the user submits a registration request to the <italic>GW</italic> node over a secure channel. Upon receiving the <italic>U</italic><italic><sub>k</sub></italic> registration request, the <italic>GW</italic> node computes:
<list list-type="order">
<list-item>
<p><italic>A</italic><italic><sub>k</sub></italic><italic>=h(ID</italic><italic><sub>k</sub></italic><italic>⊕l)</italic></p></list-item>
<list-item>
<p><italic>B</italic><italic><sub>k</sub></italic><italic>= E</italic><italic><sub>x</sub></italic><italic>[ID</italic><italic><sub>k</sub></italic><italic>||l]</italic></p></list-item>
<list-item>
<p><italic>V</italic><italic><sub>k</sub></italic><italic>= h(ID</italic><italic><sub>k</sub></italic><italic>||h(r⊕PW</italic><italic><sub>k</sub></italic><italic>))</italic></p></list-item></list></p>
<p>Thereafter, the <italic>GW</italic> node personalizes a smart card for the user with the parameters <italic>{A</italic><italic><sub>k</sub></italic>, <italic>B</italic><italic><sub>k</sub></italic>, <italic>V</italic><italic><sub>k</sub></italic>, <italic>h</italic>(.), <italic>E</italic><italic><sub>k</sub></italic><italic>[.]</italic>, <italic>D</italic><italic><sub>k</sub></italic><italic>[.]}</italic>. Here, <italic>l</italic> is random number which is generated by the <italic>GW</italic> node and <italic>x</italic> is the gateway secret key and <italic>h</italic>(.) is a collision free one-way function, e.g., SHA-1 [<xref ref-type="bibr" rid="b30-sensors-11-05020">30</xref>]. Subsequently, user <italic>U</italic><italic><sub>k</sub></italic> enters <italic>r</italic> into his/her smart card, by doing so, user <italic>U</italic><italic><sub>k</sub></italic> need not memorize the arbitrary random number. Now the smart card contains <italic>{A</italic><italic><sub>k</sub></italic>, <italic>B</italic><italic><sub>k</sub></italic>, <italic>V</italic><italic><sub>k</sub></italic>, <italic>h</italic>(.), <italic>E</italic><italic><sub>k</sub></italic><italic>[.]</italic>, <italic>D</italic><italic><sub>k</sub></italic><italic>[.]</italic>, <italic>r}</italic>. This step completes the registration phase and the process flow is shown in <xref ref-type="fig" rid="f2-sensors-11-05020">Figure 2</xref>.</p></sec>
<sec>
<label>4.2.</label>
<title>Login Phase (LP)</title>
<p>This phase is invoked whenever a user <italic>U</italic><italic><sub>k</sub></italic> wants to submit his/her query to access the sensor, every time he/she has to complete the login phase. <xref ref-type="fig" rid="f3-sensors-11-05020">Figure 3</xref> shows both the login phase and the authentication phase. The user <italic>U</italic><italic><sub>k</sub></italic> inserts his/her smart card into the terminal and inputs his <italic>ID</italic><italic><sub>k</sub></italic> and <italic>PW</italic><italic><sub>k</sub></italic>.</p>
<p>Now, the smart card performs the following operations:
<list list-type="simple">
<list-item>
<p>(LP-1). Compute: 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mi>V</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup>
<mml:mi> </mml:mi>
<mml:mo>=</mml:mo>
<mml:mi> </mml:mi>
<mml:mi>h</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>I</mml:mi>
<mml:msub>
<mml:mrow>
<mml:mi>D</mml:mi></mml:mrow>
<mml:mi>k</mml:mi></mml:msub>
<mml:mo>|</mml:mo>
<mml:mo>|</mml:mo>
<mml:mi>h</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>r</mml:mi>
<mml:mo>⊕</mml:mo>
<mml:mi>P</mml:mi>
<mml:msub>
<mml:mrow>
<mml:mi>W</mml:mi></mml:mrow>
<mml:mi>k</mml:mi></mml:msub>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>.</p></list-item>
<list-item>
<p>(LP-2). Check whether 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mi>V</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula> and <italic>V</italic><italic><sub>k</sub></italic> are equal or not. If not, then reject the login request, otherwise, the user is a legal user and go to the next step.</p></list-item>
<list-item>
<p>(LP-3). Compute: <italic>H</italic><italic><sub>k</sub></italic> <italic>= h</italic>(<italic>A</italic><italic><sub>k</sub></italic>).</p></list-item>
<list-item>
<p>(LP-4). Compute: <italic>AID</italic><italic><sub>k</sub></italic> <italic>= E</italic><italic><sub>TkTu</sub></italic><italic>[h</italic>(<italic>ID</italic><italic><sub>k</sub></italic>)||<italic>Sn||X</italic><italic><sub>g</sub></italic><italic>]</italic>; here, <italic>Tk</italic><italic><sub>Tu</sub></italic> <italic>=</italic> (<italic>Tu||H</italic><italic><sub>k</sub></italic>) is short-term key and <italic>Sn</italic> is the sensor node, which the user <italic>U</italic><italic><sub>k</sub></italic> wants to access. Here, <italic>X</italic><italic><sub>g</sub></italic> is a secret random number generated by the user <italic>U</italic><italic><sub>k</sub></italic> at login time, which is helpful to generate the session key between the user and the sensor node. <italic>Tu</italic> is denoting the current timestamp of <italic>U</italic><italic><sub>k</sub></italic>’s system, which resist replay attacks.</p></list-item>
<list-item>
<p>(LP-5). Send the login message <italic>M1 = &lt; B</italic><italic><sub>k</sub></italic>, <italic>AID</italic><italic><sub>k</sub></italic>, <italic>Tu &gt;</italic> to the sensor node.</p></list-item></list></p>
<p>Now, this is the end of login phase and the user login request message &lt;<italic>M1&gt;</italic> is send to the sensor node over a public channel.</p></sec>
<sec>
<label>4.3.</label>
<title>Authentication Phase (AP)</title>
<p>The authentication phase is invoked when a sensor node receives the user login request message &lt;<italic>M1&gt;</italic> at time <italic>Ts</italic>. The sensor node authenticates users’ requests by the following steps:
<list list-type="simple">
<list-item>
<p>(AP-1). The sensor node, <italic>Sn</italic> validates the <italic>Tu</italic>: Check, if (<italic>Ts–Tu</italic>) ≥ Δ<italic>T</italic>, if yes, then <italic>Sn</italic> reject this request and terminates the process. Otherwise, it continues with the next step. Here, <italic>Ts</italic> is the current timestamp of <italic>Sn</italic> and Δ<italic>T</italic> is the defined time interval for the transmission delay.</p></list-item>
<list-item>
<p>(AP-2). Now <italic>Sn</italic> generates message <italic>M2 = &lt;B</italic><italic><sub>k</sub></italic>, <italic>AID</italic><italic><sub>k</sub></italic>, <italic>Tu</italic>, <italic>Ts</italic>, <italic>Sn&gt;</italic> and <italic>Q</italic>. Thereafter, <italic>Sn</italic> sends &lt;<italic>M2</italic>, <italic>Q&gt;</italic> to the <italic>GW</italic> node over public network. Here, a message authentication code (<italic>MAC</italic>) [<xref ref-type="bibr" rid="b3-sensors-11-05020">3</xref>,<xref ref-type="bibr" rid="b33-sensors-11-05020">33</xref>] is computed on the message <italic>M2</italic> (<italic>i.e.</italic>, <italic>Q = MAC_<sub>SKgs</sub></italic>((<italic>B<sub>k</sub>||AID<sub>k</sub>||Tu||Ts||Sn</italic>))) for the integrity verification by the <italic>GW</italic> node.</p></list-item>
<list-item>
<p>(AP-3). Upon receiving the message <italic>M2</italic> and <italic>Q</italic> from the sensor node, the <italic>GW</italic> node performs the following actions:</p>
<list list-type="order">
<list-item>
<p>The <italic>GW</italic> node validates the time <italic>Ts</italic>: Check if (<italic>Tg–Ts</italic>) ≥ Δ<italic>T</italic>, if yes, then the <italic>GW</italic> node rejects this request and terminates the process, otherwise, it continues with the next step. Here, <italic>Tg</italic> is the current timestamp of the <italic>GW</italic> node and Δ<italic>T</italic> is the defined time interval for the transmission delay.</p></list-item>
<list-item>
<p>The <italic>GW</italic> node computes <italic>Q′</italic> on the message <italic>M2</italic> using long-term secret key <italic>SK<sub>gs</sub></italic> and verifies <italic>Q′ = Q</italic>, if yes, then the <italic>GW</italic> node considers that this is an original message and proceeds to the next step, otherwise, it rejects the request and terminates further operations.</p></list-item>
<list-item>
<p>The <italic>GW</italic> node decrypts <italic>B<sub>k</sub></italic> using secret key <italic>x</italic> and obtains 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:mi>I</mml:mi>
<mml:msubsup>
<mml:mrow>
<mml:mi>D</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>'</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula> and <italic>l′</italic> of <italic>U<sub>k</sub></italic>. Now, the <italic>GW</italic> node computes 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:mi>h</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>I</mml:mi>
<mml:msubsup>
<mml:mrow>
<mml:mi>D</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>'</mml:mo></mml:msubsup>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>, 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mi>A</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>'</mml:mo></mml:msubsup>
<mml:mi> </mml:mi>
<mml:mo>=</mml:mo>
<mml:mi> </mml:mi>
<mml:mi>h</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>I</mml:mi>
<mml:msubsup>
<mml:mrow>
<mml:mi>D</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>'</mml:mo></mml:msubsup>
<mml:mo>⊕</mml:mo>
<mml:mi>l</mml:mi>
<mml:mo>'</mml:mo>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> and 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mi>H</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>'</mml:mo></mml:msubsup>
<mml:mi> </mml:mi>
<mml:mo>=</mml:mo>
<mml:mi> </mml:mi>
<mml:mi>h</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:msubsup>
<mml:mrow>
<mml:mi>A</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>'</mml:mo></mml:msubsup>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>. Subsequently, the <italic>GW</italic> node generates a temporary key <italic>Tk<sub>Tu</sub></italic> (<italic>Tu||</italic>
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mi>H</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>'</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula>). After that, the <italic>GW</italic> node decrypts the sub-message <italic>AID<sub>k</sub></italic> by using the <italic>Tk<sub>Tu</sub></italic> and obtains <italic>[h</italic>(
<inline-formula>
<mml:math>
<mml:mrow>
<mml:mi>I</mml:mi>
<mml:msubsup>
<mml:mrow>
<mml:mi>D</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula>)<italic>||Sn*||X<sub>g</sub>]</italic>. Afterwards, the <italic>GW</italic> node compares 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:mi>h</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>I</mml:mi>
<mml:msubsup>
<mml:mrow>
<mml:mi>D</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>'</mml:mo></mml:msubsup>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> with 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:mi>h</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>I</mml:mi>
<mml:msubsup>
<mml:mrow>
<mml:mi>D</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>, if this check is successful then the user is a legal user. Here, 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:mi>h</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>I</mml:mi>
<mml:msubsup>
<mml:mrow>
<mml:mi>D</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> is sub-message of <italic>AID<sub>k</sub></italic>. At the same time, the <italic>GW</italic> node verifies whether <italic>Sn</italic> is equal to <italic>Sn*</italic>, which is included in sub-message of <italic>AID<sub>k</sub></italic> and if yes, then the <italic>GW</italic> node considers that <italic>Sn</italic> is a legal node that user <italic>U<sub>k</sub></italic> wants to access. Otherwise, the <italic>GW</italic> node rejects the authentication process.</p></list-item>
<list-item>
<p>After authenticating the user and the sensor node; the <italic>GW</italic> node informs the sensor node that user <italic>U<sub>k</sub></italic> is a legitimate user, therefore, the <italic>GW</italic> node computes message <italic>M3 = &lt;Tg</italic>, <italic>C&gt;</italic> and sends message <italic>M3</italic> to the sensor node. Here, <italic>C = E<sub>SKgs</sub>[h(ID<sub>k</sub>)||X<sub>g</sub>||Tg]</italic> and <italic>Tg</italic> is the current timestamp of the <italic>GW</italic> node.</p></list-item></list></list-item>
<list-item>
<p>(AP-4). Upon receiving the message <italic>M3</italic> from the <italic>GW</italic> node, the sensor node performs the following:</p>
<list list-type="order">
<list-item>
<p>Firstly, <italic>Sn</italic> validate the time <italic>Tg</italic>: Check if (<italic>Ts–Tg</italic>) ≥ Δ<italic>T</italic>, if yes, then the sensor node rejects this request and terminates the process. Otherwise, it continues with the next step. Here, <italic>Ts</italic> is the current timestamp of the sensor node and Δ<italic>T</italic> is the defined time interval for the transmission delay.</p></list-item>
<list-item>
<p>Now, with the knowledge of <italic>SK<sub>gs</sub></italic>, the sensor node decrypts the sub-message <italic>C = D<sub>SKgs</sub>[h(ID<sub>k</sub>)||Xg||Tg*]</italic> and verifies whether <italic>Tg</italic> is equal to <italic>Tg*</italic> or not. If <italic>Tg</italic> is not verified then the process is terminated; otherwise, the sensor node considers the <italic>GW</italic> node a legal node and message <italic>M3</italic> is generated by the original <italic>GW</italic> node.</p></list-item>
<list-item>
<p>Thereafter, <italic>Sn</italic> computes a session key <italic>Ses<sub>K</sub></italic> <italic>= h</italic>(<italic>h</italic>(<italic>ID<sub>k</sub></italic>)<italic>||Xg||Sn||Ts||Tu</italic>) for secure communication between the sensor node and the user. Now, <italic>Sn</italic> generates a message <italic>M4 = &lt;L, Ts&gt;</italic>, and sends it to the user <italic>U<sub>k</sub></italic>. Here, <italic>L = E<sub>SesK</sub>[Xg||Ts]</italic> and <italic>Ts</italic> is the current time stamp of the sensor node.</p></list-item></list></list-item>
<list-item>
<p>(AP-5). While receiving the message <italic>M4</italic> from the sensor node, the user <italic>U<sub>k</sub></italic> performs the following:</p>
<list list-type="order">
<list-item>
<p>Firstly, <italic>U<sub>k</sub></italic> validates the time <italic>Ts</italic>: Check if (<italic>Tu – Ts</italic>) ≥ Δ<italic>T</italic>, if yes, then the sensor node rejects this request and terminates the process. Otherwise, it continues with the next step. Here, <italic>Tu</italic> is the current timestamp of the user <italic>U<sub>k</sub></italic> and Δ<italic>T</italic> is the defined time interval for the transmission delay.</p></list-item>
<list-item>
<p>Now, the user <italic>U<sub>k</sub></italic> computes the session key <italic>Ses<sub>K</sub></italic> <italic>= h</italic>(<italic>h(ID<sub>k</sub></italic>)<italic>||X<sub>g</sub>||Sn||Ts||Tu</italic>) and decrypts the sub-message <italic>L</italic> (<italic>i.e.,</italic> 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>D</mml:mi></mml:mrow>
<mml:mrow>
<mml:mi>S</mml:mi>
<mml:mi>e</mml:mi>
<mml:mi>s</mml:mi>
<mml:mi>K</mml:mi></mml:mrow></mml:msub>
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo></mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mi>X</mml:mi></mml:mrow>
<mml:mi>g</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup>
<mml:mrow>
<mml:mo>|</mml:mo>
<mml:mo>|</mml:mo></mml:mrow>
<mml:mi>T</mml:mi>
<mml:mi>s</mml:mi>
<mml:mrow>
<mml:mo>*</mml:mo></mml:mrow>
<mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:math></inline-formula>) and obtains 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mi>X</mml:mi></mml:mrow>
<mml:mi>g</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula> and <italic>Ts*</italic>. The user <italic>U<sub>k</sub></italic> checks 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>X</mml:mi></mml:mrow>
<mml:mi>g</mml:mi></mml:msub>
<mml:mi> </mml:mi>
<mml:mo>=</mml:mo>
<mml:mi> </mml:mi>
<mml:msubsup>
<mml:mrow>
<mml:mi>X</mml:mi></mml:mrow>
<mml:mi>g</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula> and <italic>Ts = Ts*</italic>, if yes, then he/she believes that <italic>Sn</italic> is a real sensor node, otherwise not.</p></list-item>
<list-item>
<p>Moreover, now the user <italic>U<sub>k</sub></italic> and <italic>Sn</italic> share the symmetric session key <italic>Ses<sub>K</sub></italic> <italic>= h</italic>(<italic>h</italic>(<italic>ID<sub>k</sub></italic>)<italic>||X<sub>g</sub>||Sn||Ts||Tu</italic>) for performing further subsequent operation during a session.</p></list-item></list></list-item></list></p>
<p>As a result, a legitimate user can communicate with real sensor nodes and access the network data.</p></sec>
<sec>
<label>4.4.</label>
<title>Password-Update Phase (PUP)</title>
<p>The password update phase is invoked whenever user <italic>U<sub>k</sub></italic> wants to update his/her old password (<italic>PW<sub>k</sub></italic>). The password update phase is described below:
<list list-type="simple">
<list-item>
<p>(PUP-1). User <italic>U<sub>k</sub></italic> inserts his/her smart card into the terminal and enters his/her identity (<italic>ID<sub>k</sub></italic>) and password (<italic>PW<sub>k</sub></italic>).</p></list-item>
<list-item>
<p>(PUP-2). Firstly, the smart card validates the <italic>U<sub>k</sub></italic>’s entered <italic>ID<sub>k</sub></italic> and <italic>PW<sub>k</sub></italic> with the stored values by computing the following: <italic>Vk* = h</italic>(<italic>ID<sub>k</sub>||h</italic>(<italic>r⊕PW<sub>k</sub></italic>)).</p></list-item>
<list-item>
<p>(PUP-3). Verify whether 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mi>V</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula> and <italic>V<sub>k</sub></italic> are equal or not. If not, then reject the password update request; otherwise, proceed to the next steps.</p></list-item>
<list-item>
<p>(PUP-4). Upon receiving the <italic>U<sub>k</sub>’s</italic> new password (
<inline-formula>
<mml:math>
<mml:mrow>
<mml:mi>P</mml:mi>
<mml:msubsup>
<mml:mrow>
<mml:mi>W</mml:mi></mml:mrow>
<mml:mrow>
<mml:mi>k</mml:mi>
<mml:mi>n</mml:mi>
<mml:mi>e</mml:mi>
<mml:mi>w</mml:mi></mml:mrow>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula>), the smart card computes 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mi>V</mml:mi></mml:mrow>
<mml:mrow>
<mml:mi>k</mml:mi>
<mml:mi>n</mml:mi>
<mml:mi>e</mml:mi>
<mml:mi>w</mml:mi></mml:mrow>
<mml:mo>*</mml:mo></mml:msubsup>
<mml:mi> </mml:mi>
<mml:mo>=</mml:mo>
<mml:mi> </mml:mi>
<mml:mi>h</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>I</mml:mi>
<mml:msub>
<mml:mrow>
<mml:mi>D</mml:mi></mml:mrow>
<mml:mi>k</mml:mi></mml:msub>
<mml:mo>|</mml:mo>
<mml:mo>|</mml:mo>
<mml:mi>h</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>r</mml:mi>
<mml:mo>⊕</mml:mo>
<mml:mi>P</mml:mi>
<mml:msubsup>
<mml:mrow>
<mml:mi>W</mml:mi></mml:mrow>
<mml:mrow>
<mml:mi>k</mml:mi>
<mml:mi>n</mml:mi>
<mml:mi>e</mml:mi>
<mml:mi>w</mml:mi></mml:mrow>
<mml:mo>*</mml:mo></mml:msubsup>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> (PUP-5). Now, the smart card replaces <italic>V<sub>k</sub></italic> with 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mi>V</mml:mi></mml:mrow>
<mml:mrow>
<mml:mi>k</mml:mi>
<mml:mi>n</mml:mi>
<mml:mi>e</mml:mi>
<mml:mi>w</mml:mi></mml:mrow>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula>.</p></list-item></list></p>
<p>After performing the above steps, the password update phase takes place successfully. The flow of the password update phase is shown in <xref ref-type="fig" rid="f4-sensors-11-05020">Figure 4</xref>.</p></sec></sec>
<sec sec-type="methods">
<label>5.</label>
<title>Nonmonotonic Cryptographic Protocol and RUASN Analysis and Verification</title>
<p>This section presents, first, the nonmonotonic cryptographic protocol (<italic>NCP</italic>) [<xref ref-type="bibr" rid="b24-sensors-11-05020">24</xref>], and second, formal analysis and verification of <italic>RUASN</italic> using the <italic>NCP</italic> protocol.</p>
<sec>
<label>5.1.</label>
<title>Nonmonotonic Cryptographic Protocol</title>
<p>This sub-section describes the nonmonotonic cryptographic protocol (<italic>NCP</italic>), which is also known as Rubin Logic. The <italic>NCP</italic> logic assumed that involved entities are trusted, and state of knowledge (<italic>i.e., current state of the protocol</italic>), and describes the authentication logic. In [<xref ref-type="bibr" rid="b24-sensors-11-05020">24</xref>–<xref ref-type="bibr" rid="b34-sensors-11-05020">34</xref>] the authors state that the <italic>NCP</italic> logic does not require any idealization step in specifying the protocol and is very close to real implementation. In Rubin logic the roles are assigned to entities, which are considered as independent processes. The nonmonotonic logic consists of two sets, global set and local set. These sets are directly applicable for protocol analysis, as follows. For more details the reader may refer to [<xref ref-type="bibr" rid="b24-sensors-11-05020">24</xref>] and [<xref ref-type="bibr" rid="b35-sensors-11-05020">35</xref>].</p>
<sec>
<label>5.1.1.</label>
<title>Global Set and Local Set</title>
<p><italic>Global set:</italic> The global sets are publically known to each principal in a protocol specification, and consist of principal set, rule set, secret set and observers set. These sets represent the information of the protocol and the contents of these global sets may get updated as the protocol progresses.</p>
<list list-type="bullet">
<list-item>
<p>➢ <italic>Principal set:</italic> This set represents the involved entities in a protocol, such as, <italic>Et = {Et<sub>1</sub></italic>, <italic>Et<sub>2</sub></italic>, <italic>Et<sub>3</sub></italic>,<italic>…..</italic>, <italic>Et<sub>n</sub>}</italic>.</p></list-item>
<list-item>
<p>➢ <italic>Rule set:</italic> This set contain inference rules for deriving new statements from existing statements, as described in Section 5.1.3.</p></list-item>
<list-item>
<p>➢ <italic>Secret set:</italic> This set holds all the protocol secrets, such as <italic>S = {S<sub>1</sub>, S<sub>2</sub>, S<sub>3</sub>,…., S<sub>n</sub>}</italic>, that exist at any given time in the system.</p></list-item>
<list-item>
<p>➢ <italic>Observers set:</italic> This set holds all <italic>Si</italic> such that for each <italic>Si</italic>, Observers (<italic>Si</italic>) contains all the involved entities who could possibly know the secret <italic>Si</italic> in the system.</p></list-item>
<list-item>
<p>➢ <italic>Local set:</italic> The local sets are not publically known, instead, they are private to each entity. The local sets consist of the following:</p></list-item>
<list-item>
<p>➢ <italic>Possession set</italic> (<italic>Ei</italic>): This set holds all the data relevant to security, and that particular entity knows or possesses, which includes encryption keys, public keys, and other secrets that are not publically available. <italic>POSS</italic>(<italic>Ei</italic>) <italic>= {poss<sub>1</sub></italic>, <italic>poss<sub>2</sub></italic>, <italic>psos<sub>3</sub></italic>,<italic>….</italic>, <italic>poss<sub>n</sub>}</italic>.</p></list-item>
<list-item>
<p>➢ <italic>Belief set:</italic> This set holds all the beliefs held by a principal. For example, the beliefs about freshness, and the beliefs about the possessions of other involved principals. <italic>BEL</italic>(<italic>Ei</italic>) <italic>= {belf<sub>1</sub></italic>, <italic>belf<sub>2</sub></italic>, <italic>belf<sub>3</sub></italic>,<italic>….</italic>, <italic>belf<sub>n</sub>}</italic>.</p></list-item>
<list-item>
<p>➢ <italic>Seen set</italic> (<italic>Ei</italic>): This set holds plaintext message parts that <italic>Ei</italic> sees from messages sent across the network and it also contain a copy of the information as the Observers sets.</p></list-item>
<list-item>
<p>➢ <italic>Behavior list</italic> (<italic>Ei</italic>): This is a list instead of a set, and the list elements are ordered. <italic>BL = {AL</italic>, <italic>bev<sub>1</sub></italic>, <italic>bev<sub>2</sub></italic>, <italic>bev<sub>3</sub></italic>,<italic>…</italic>, <italic>bev<sub>n</sub>}</italic>, here <italic>AL</italic> is an action list, which consists of zero or many actions executed by <italic>Ei</italic> and <italic>bev<sub>n</sub></italic> is a pair, <italic>i.e</italic>., (<italic>message</italic>, <italic>AL</italic>). The messages have two forms: <italic>Send</italic> (<italic>Ei</italic>, <italic>message</italic>) and <italic>Receive</italic> (<italic>Ei</italic>, <italic>message</italic>). Furthermore, after every <italic>Send</italic>(.) operation, the Observers set has to be updated using <italic>Update</italic>(.) operation. After each <italic>Update</italic>(.) operation the control pass to the next <italic>Receive</italic>(.) operation of principal, which is specified in the earlier <italic>Send</italic>(.) operation.</p></list-item>
<list-item>
<p>➢ <italic>Haskeys set</italic> (<italic>Ei</italic>): The Haskeys set holds keys that <italic>Ei</italic> sees either because they are in the initial possession set, or they appear in a message sent across the network and are added to <italic>Ei’s Seen set</italic>.</p></list-item></list></sec>
<sec>
<label>5.1.2.</label>
<title>Actions</title>
<p>Actions are operations which play essential roles in the protocol specification. These actions control the state of knowledge and possessions for involved entities (<italic>such as, constructs messages, hashing, concatenation, encryption /decryption, secret generation, update, and abort operations, are few example</italic>). For a complete list of actions readers may refer to [<xref ref-type="bibr" rid="b24-sensors-11-05020">24</xref>,<xref ref-type="bibr" rid="b35-sensors-11-05020">35</xref>]. As per our requirements, we have defined the following actions, as shown below, which are directly adopted from [<xref ref-type="bibr" rid="b24-sensors-11-05020">24</xref>–<xref ref-type="bibr" rid="b34-sensors-11-05020">34</xref>]. The action is marked with ▪ to show that it has been successful and moved to the next action.</p>
<list list-type="simple">
<list-item>
<p>▪ <italic>Hash</italic> (<italic>h</italic>(.); <italic>X</italic>)</p>
<p>Condition: <italic>h</italic>(.), <italic>X ∈ POSS</italic>(<italic>Ei</italic>)</p>
<p>Result: <italic>POSS</italic>(<italic>Ei</italic>)<italic>: = POSS</italic>(<italic>Ei</italic>) <italic>∪ {h</italic>(<italic>X</italic>)<italic>}</italic></p>
<p>Description: This action is for hashing the data.</p></list-item>
<list-item>
<p>▪ <italic>XOR</italic>(<italic>X<sub>1</sub></italic>, <italic>X<sub>2</sub></italic>, <italic>X<sub>3</sub></italic>, ….., <italic>X<sub>n</sub></italic>)</p></list-item>
<list-item>
<p>Condition: <italic>X<sub>1</sub>, X<sub>2</sub>, X<sub>3</sub>, ….., X<sub>n</sub></italic> <italic>∈ POSS</italic>(<italic>Ei</italic>)</p>
<p>Result: <italic>POSS</italic>(<italic>Ei</italic>): = <italic>POSS</italic>(<italic>Ei</italic>) <italic>∈ {X<sub>1</sub>, X<sub>2</sub>, X<sub>3</sub>, ……,X<sub>n</sub>}</italic></p>
<p>Description: This action is for <italic>XOR</italic>ing the data.</p></list-item>
<list-item>
<p>▪ <italic>Encrypt</italic>(<italic>X</italic>, <italic>k</italic>)</p>
<p>Condition: <italic>X</italic>, <italic>k</italic> ∈ <italic>POSS</italic>(<italic>Ei</italic>)</p></list-item>
<list-item>
<p>Result: <italic>POSS</italic>(<italic>Ei</italic>) : = <italic>POSS</italic>(<italic>Ei</italic>) <italic>∪{{X}<sub>k</sub>}</italic></p>
<p>Description: This action occurs when a principal encrypts data. If <italic>Ei</italic> possesses <italic>X</italic> and knows <italic>k</italic> then he/she can possess <italic>{X}<sub>k</sub></italic>.</p></list-item>
<list-item>
<p>▪ <italic>Decrypt</italic>(<italic>{X}<sub>k</sub></italic>, <italic>k</italic>)</p>
<p>Condition: <italic>{X}<sub>k</sub></italic>, <italic>k</italic> ∈ <italic>POSS</italic>(<italic>Ei</italic>)</p>
<p>Result: <italic>POSS</italic>(<italic>Ei</italic>):= <italic>POSS</italic>(<italic>Ei</italic>) <italic>∪</italic> {<italic>X</italic>}</p></list-item>
<list-item>
<p>Description: This action is performed when a principal decrypts data. If <italic>Ei</italic> possesses <italic>X</italic>, encrypted under <italic>k</italic>, and <italic>Ei</italic> knows <italic>k</italic>, then he/she (<italic>Ei</italic>) can possess <italic>X</italic>.</p></list-item>
<list-item>
<p>▪ <italic>Generate-Secret</italic>(<italic>X<sub>g</sub></italic>)</p></list-item>
<list-item>
<p>Result: <italic>S:= S ∪ {X<sub>g</sub>}, Observers</italic>(<italic>X<sub>g</sub></italic>) <italic>= {Ei}</italic>, <italic>POSS</italic>(<italic>Ei</italic>) <italic>:= POSS</italic>(<italic>Ei</italic>) <italic>∪</italic> {<italic>X<sub>g</sub></italic>, <italic>Ei}</italic>, <italic>BEL</italic>(<italic>Ei</italic>):= <italic>BEL</italic> (<italic>Ei</italic>) <italic>∪</italic> #(<italic>X<sub>g</sub></italic>)</p></list-item>
<list-item>
<p>Description: This action generates a secret for an entity, when needed. Thereafter, a new secret <italic>X<sub>g</sub></italic>, is added to secret <italic>S</italic> and the Observers and Possession sets are updated.</p></list-item>
<list-item>
<p>▪ <italic>Concat</italic>(<italic>X<sub>1</sub>, X<sub>2</sub>, X<sub>3</sub>, ….,X<sub>n</sub></italic>)</p>
<p>Condition: <italic>X<sub>1</sub>, X<sub>2</sub>, X<sub>3</sub>, …..,X<sub>n</sub></italic> <italic>∈ POSS</italic>(<italic>Ei</italic>)</p>
<p>Result: <italic>POSS</italic>(<italic>Ei</italic>) := <italic>POSS</italic>(<italic>Ei</italic>) <italic>∪</italic> {<italic>X<sub>1</sub>, X<sub>2</sub>, X<sub>3</sub>, …., X<sub>n</sub>}</italic></p>
<p>Description: This action concatenates the sub-messages.</p></list-item>
<list-item>
<p>▪ <italic>Check</italic>(<italic>X</italic>, <italic>Y</italic>)</p>
<p>Condition: <italic>X</italic>, <italic>Y ∈ POSS</italic>(<italic>Ei</italic>)</p>
<p>Result: Valid if <italic>X==Y</italic>, otherwise invalid.</p></list-item>
<list-item>
<p>▪ <italic>Split</italic>(<italic>X</italic>)</p></list-item>
<list-item>
<p>Condition: <italic>X contains X<sub>1</sub>, X<sub>2</sub>, X<sub>3</sub>, ….., X<sub>n</sub>, X</italic> ∈ <italic>POSS</italic>(<italic>Ei</italic>)</p>
<p>Result: <italic>POSS</italic>(<italic>Ei</italic>):= <italic>POSS</italic>(<italic>Ei</italic>) <italic>∪ {X<sub>1</sub>, X<sub>2</sub>, X<sub>3</sub>,….,X<sub>n</sub>}</italic></p>
<p>Description: This action is used to break the message into sub-messages.</p></list-item>
<list-item>
<p>▪ <italic>Send</italic>(<italic>Ej</italic>, <italic>X</italic>)</p>
<p>Description: This action sends message <italic>X to Ej</italic> (<italic>i.e.</italic>, <italic>Ei to Ej</italic>).</p></list-item>
<list-item>
<p>▪ <italic>Receive</italic>(<italic>Ej</italic>, <italic>X</italic>)</p>
<p>Description: This action receives message <italic>X</italic> from <italic>Ej</italic> (<italic>i.e.</italic>, <italic>Ei receives from Ej</italic>) and added to <italic>POSS</italic>(<italic>Ei</italic>).</p></list-item>
<list-item>
<p>▪ <italic>Update</italic>(<italic>X</italic>)</p>
<p>Description: The purpose of update action is to update the Observers sets of all secrets that are sent on the network.</p></list-item>
<list-item>
<p>▪ <italic>Forget</italic>(<italic>X</italic>)</p>
<p>Description: The purpose of forget action, when <italic>Ei</italic> no longer is in possession of <italic>X</italic>.</p></list-item>
<list-item>
<p>▪ <italic>Abort:</italic></p>
<p>Description: The abort action takes place when a checked action could not satisfy the established conditions. Furthermore, this action aborts the system, if a protocol run is illegal. As a result, analysis reports a failure.</p></list-item></list></sec>
<sec>
<label>5.1.3.</label>
<title>Inference Rules</title>
<p>A procedure which combines known facts and produce new fact is called an inference rule [<xref ref-type="bibr" rid="b24-sensors-11-05020">24</xref>]. These inference rules are used to fact about beliefs during the protocol execution and are applied whenever they are relevant to protocol progress. The following inference rules are defined as per our requirements, which are directly adopted from [<xref ref-type="bibr" rid="b24-sensors-11-05020">24</xref>,<xref ref-type="bibr" rid="b35-sensors-11-05020">35</xref>].</p>
<list list-type="simple">
<title><italic>Notation:</italic></title>
<list-item>
<p><bold><italic>X contains Y:</italic></bold> <italic>Y</italic> appears as a sub-message of <italic>X</italic>.</p></list-item>
<list-item>
<p><bold><italic>S: = f</italic>(<italic>S</italic>)</bold>: <italic>S</italic> is replaced by the value of <italic>f</italic>(<italic>S</italic>).</p></list-item>
<list-item>
<p><bold><italic>X from E:</italic></bold> <italic>X</italic> is received from <italic>E</italic>.</p></list-item></list>
<list list-type="order">
<list-item>
<p><italic>Message-meaning rule:</italic>
<disp-formula>
<mml:math display="block">
<mml:mrow>
<mml:mfrac>
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mrow>
<mml:mo>{</mml:mo>
<mml:mi>X</mml:mi>
<mml:mo>}</mml:mo></mml:mrow></mml:mrow>
<mml:mi>k</mml:mi></mml:msub>
<mml:mi> </mml:mi>
<mml:mtext mathvariant="italic">from</mml:mtext>
<mml:mi> </mml:mi>
<mml:mi>E</mml:mi>
<mml:mi>j</mml:mi>
<mml:mo>∈</mml:mo>
<mml:mi> </mml:mi>
<mml:mtext mathvariant="italic">POSS</mml:mtext>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>E</mml:mi>
<mml:mi>i</mml:mi>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>,</mml:mo>
<mml:mi> </mml:mi>
<mml:mo>{</mml:mo>
<mml:mi>E</mml:mi>
<mml:mi>i</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi> </mml:mi>
<mml:mi>E</mml:mi>
<mml:mi>j</mml:mi>
<mml:mo>}</mml:mo>
<mml:mi> </mml:mi>
<mml:mo>⊆</mml:mo>
<mml:mtext mathvariant="italic">POSS</mml:mtext>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>E</mml:mi>
<mml:mi>i</mml:mi>
<mml:mo stretchy="false">)</mml:mo></mml:mrow>
<mml:mrow>
<mml:mtext mathvariant="italic">BEL</mml:mtext>
<mml:mi> </mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>E</mml:mi>
<mml:mi>i</mml:mi>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>:</mml:mo>
<mml:mi> </mml:mi>
<mml:mo>=</mml:mo>
<mml:mi> </mml:mi>
<mml:mtext mathvariant="italic">BEL</mml:mtext>
<mml:mi> </mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>E</mml:mi>
<mml:mi>i</mml:mi>
<mml:mo stretchy="false">)</mml:mo>
<mml:mi> </mml:mi>
<mml:mo>∪</mml:mo>
<mml:mo>{</mml:mo>
<mml:mi>X</mml:mi>
<mml:mi> </mml:mi>
<mml:mo>∈</mml:mo>
<mml:mi> </mml:mi>
<mml:mtext mathvariant="italic">POSS</mml:mtext>
<mml:mi> </mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>E</mml:mi>
<mml:mi>i</mml:mi>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>}</mml:mo></mml:mrow></mml:mfrac></mml:mrow></mml:math></disp-formula></p></list-item>
<list-item>
<p><italic>Origin rule:</italic>
<disp-formula>
<mml:math display="block">
<mml:mrow>
<mml:mfrac>
<mml:mrow>
<mml:mi>X</mml:mi>
<mml:mi> </mml:mi>
<mml:mo>∈</mml:mo>
<mml:mi> </mml:mi>
<mml:mtext mathvariant="italic">POSS</mml:mtext>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>E</mml:mi>
<mml:mi>i</mml:mi>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>,</mml:mo>
<mml:mi> </mml:mi>
<mml:mi>X</mml:mi>
<mml:mi> </mml:mi>
<mml:mtext mathvariant="italic">contains</mml:mtext>
<mml:mi> </mml:mi>
<mml:msub>
<mml:mrow>
<mml:mi>x</mml:mi></mml:mrow>
<mml:mn>1</mml:mn></mml:msub>
<mml:mo>,</mml:mo>
<mml:mi> </mml:mi>
<mml:mi>E</mml:mi>
<mml:mi>j</mml:mi>
<mml:mi> </mml:mi>
<mml:mo>∈</mml:mo>
<mml:mi> </mml:mi>
<mml:mtext mathvariant="italic">Observers</mml:mtext>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mrow>
<mml:mi>x</mml:mi></mml:mrow>
<mml:mn>1</mml:mn></mml:msub>
<mml:mo stretchy="false">)</mml:mo></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>x</mml:mi></mml:mrow>
<mml:mn>1</mml:mn></mml:msub>
<mml:mi> </mml:mi>
<mml:mtext mathvariant="italic">from</mml:mtext>
<mml:mi> </mml:mi>
<mml:mi>E</mml:mi>
<mml:mi>j</mml:mi>
<mml:mi> </mml:mi>
<mml:mo>∈</mml:mo>
<mml:mi> </mml:mi>
<mml:mtext mathvariant="italic">POSS</mml:mtext>
<mml:mi> </mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>E</mml:mi>
<mml:mi>i</mml:mi>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mfrac></mml:mrow></mml:math></disp-formula></p></list-item>
<list-item>
<p><italic>Sub-message origin rule:</italic>
<disp-formula>
<mml:math display="block">
<mml:mrow>
<mml:mfrac>
<mml:mrow>
<mml:mi>X</mml:mi>
<mml:mi> </mml:mi>
<mml:mo>∈</mml:mo>
<mml:mi> </mml:mi>
<mml:mtext mathvariant="italic">POSS</mml:mtext>
<mml:mi> </mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>E</mml:mi>
<mml:mi>i</mml:mi>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>,</mml:mo>
<mml:mi> </mml:mi>
<mml:mi>X</mml:mi>
<mml:mi> </mml:mi>
<mml:mtext mathvariant="italic">contains</mml:mtext>
<mml:mo>{</mml:mo>
<mml:msub>
<mml:mrow>
<mml:mi>x</mml:mi></mml:mrow>
<mml:mn>1</mml:mn></mml:msub>
<mml:mo>,</mml:mo>
<mml:mi> </mml:mi>
<mml:msub>
<mml:mrow>
<mml:mi>x</mml:mi></mml:mrow>
<mml:mn>2</mml:mn></mml:msub>
<mml:mo>}</mml:mo>
<mml:mi> </mml:mi>
<mml:mtext mathvariant="italic">from</mml:mtext>
<mml:mi> </mml:mi>
<mml:mi>E</mml:mi>
<mml:mi>j</mml:mi></mml:mrow>
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>x</mml:mi></mml:mrow>
<mml:mn>2</mml:mn></mml:msub>
<mml:mi> </mml:mi>
<mml:mtext mathvariant="italic">from</mml:mtext>
<mml:mi> </mml:mi>
<mml:mi>E</mml:mi>
<mml:mi>j</mml:mi>
<mml:mi> </mml:mi>
<mml:mo>∈</mml:mo>
<mml:mi> </mml:mi>
<mml:mtext mathvariant="italic">POSS</mml:mtext>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>E</mml:mi>
<mml:mi>i</mml:mi>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mfrac></mml:mrow></mml:math></disp-formula></p></list-item>
<list-item>
<p><italic>Sub-message freshness rule:</italic>
<disp-formula>
<mml:math display="block">
<mml:mrow>
<mml:mfrac>
<mml:mrow>
<mml:mo>#</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:msub>
<mml:mrow>
<mml:mi>x</mml:mi></mml:mrow>
<mml:mn>1</mml:mn></mml:msub>
<mml:mo stretchy="false">)</mml:mo>
<mml:mi> </mml:mi>
<mml:mo>∈</mml:mo>
<mml:mi> </mml:mi>
<mml:mtext mathvariant="italic">BEL</mml:mtext>
<mml:mi> </mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>E</mml:mi>
<mml:mi>i</mml:mi>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>,</mml:mo>
<mml:mi> </mml:mi>
<mml:mo>{</mml:mo>
<mml:mi>X</mml:mi>
<mml:mi> </mml:mi>
<mml:mtext mathvariant="italic">contains</mml:mtext>
<mml:mi> </mml:mi>
<mml:msub>
<mml:mrow>
<mml:mi>x</mml:mi></mml:mrow>
<mml:mn>1</mml:mn></mml:msub>
<mml:mo>,</mml:mo>
<mml:mi> </mml:mi>
<mml:mi>Y</mml:mi>
<mml:mi> </mml:mi>
<mml:mtext mathvariant="italic">contains</mml:mtext>
<mml:mi> </mml:mi>
<mml:msub>
<mml:mrow>
<mml:mi>x</mml:mi></mml:mrow>
<mml:mn>2</mml:mn></mml:msub>
<mml:mo>}</mml:mo>
<mml:mi> </mml:mi>
<mml:mo>⊆</mml:mo>
<mml:mi> </mml:mi>
<mml:mtext mathvariant="italic">POSS</mml:mtext>
<mml:mi> </mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>E</mml:mi>
<mml:mi>i</mml:mi>
<mml:mo stretchy="false">)</mml:mo></mml:mrow>
<mml:mrow>
<mml:mtext mathvariant="italic">BEL</mml:mtext>
<mml:mi> </mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>E</mml:mi>
<mml:mi>i</mml:mi>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>:</mml:mo>
<mml:mi> </mml:mi>
<mml:mo>=</mml:mo>
<mml:mi> </mml:mi>
<mml:mtext mathvariant="italic">BEL</mml:mtext>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>E</mml:mi>
<mml:mi>i</mml:mi>
<mml:mo stretchy="false">)</mml:mo>
<mml:mi> </mml:mi>
<mml:mo>∪</mml:mo>
<mml:mi> </mml:mi>
<mml:mo>#</mml:mo>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>x</mml:mi>
<mml:mn>1</mml:mn>
<mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mfrac></mml:mrow></mml:math></disp-formula></p></list-item></list>
<p>For a complete list of inference rules, readers may refer to [<xref ref-type="bibr" rid="b24-sensors-11-05020">24</xref>] and [<xref ref-type="bibr" rid="b35-sensors-11-05020">35</xref>].</p></sec></sec>
<sec sec-type="methods">
<label>5.2.</label>
<title>RUASN Analysis and Verification Using Rubin-Logic</title>
<p>This sub-section presents the analysis and verification of the proposed <italic>RUASN</italic> using well-known Rubin logic [<xref ref-type="bibr" rid="b24-sensors-11-05020">24</xref>]. The <italic>NCP</italic> logic integrates protocol analysis with protocol specification and thus, beliefs of involved entities and current state of knowledge is updated as the protocol run progresses. For <italic>RUASN</italic> analysis and verification, only three phases are accounted, namely, registration phase, login phase and authentication phase, as follows.</p>
<sec>
<label>5.2.1.</label>
<title>RUASN Specification</title>
<p>For convenience, a list of some additional notations and symbols will be used in the <italic>RUASN</italic> analysis and verification, as shown in <xref ref-type="table" rid="t2-sensors-11-05020">Table 2</xref>.</p>
<p>As per the <italic>NCP</italic> logic, the specifications of <italic>RUASN</italic> are the following:</p>
<p><italic>Global sets:</italic> It consists of four sets:
<list list-type="simple">
<list-item>
<p>▪ <italic>Principal set: P = U</italic>, <italic>GW</italic>, and <italic>Sn</italic>. Here, <italic>U</italic> is the initiator of <italic>RUASN</italic>.</p></list-item>
<list-item>
<p>▪ <italic>Rule set:</italic> Inference rules are defined in Section 5.1.3.</p></list-item>
<list-item>
<p>▪ <italic>Secret set: {PW<sub>k</sub>, r, x, y, l, SK<sub>gs</sub>}</italic></p></list-item>
<list-item>
<p>▪ <italic>Observers set:</italic></p>
<list list-type="simple">
<list-item>
<p><italic>Observers</italic> (<italic>PW<sub>k</sub>,r</italic>)<italic>: {U}</italic></p></list-item>
<list-item>
<p><italic>Observers</italic>(<italic>x</italic>, <italic>y</italic>, <italic>l</italic>)<italic>: {GW}</italic></p></list-item>
<list-item>
<p><italic>Observers</italic> (<italic>SK<sub>gs</sub></italic>)<italic>: {GW, Sn}</italic></p></list-item></list></list-item></list></p>
<p><italic>Local sets:</italic> The local sets consist of <italic>U</italic>, <italic>GW</italic>, and <italic>Sn</italic> and are as shown in <xref ref-type="table" rid="t3-sensors-11-05020">Table 3</xref>.</p></sec>
<sec sec-type="methods">
<label>5.2.2.</label>
<title>RUASN Analysis and Verification</title>
<p>Once the protocol specification has been completed, the analysis begins. This subsection analyzes the proposed scheme, which is very close to real implementation. We have considered three phases, namely, registration phase, login phase and authentication phase, where three entities are involved in the protocol progress [<italic>i.e.</italic>, <italic>user</italic>(<italic>U</italic>), <italic>gateway</italic>(<italic>GW</italic>) and <italic>sensor</italic>(<italic>Sn</italic>)].</p>
<p>As we can see the Phase-I in <xref ref-type="table" rid="t3-sensors-11-05020">Table 3</xref>, the entity <italic>U</italic> is the initiator of the protocol, so user behavior list actions are executed first [<italic>i.e.</italic>, <italic>BL</italic>(<italic>U</italic>)]. The first three actions are executed in <italic>BL</italic>(<italic>U</italic>) and once the <italic>Update</italic> action is performed, the next actions have to be executed in the <italic>GW</italic> behavior list, since the <italic>Send</italic> operation (<italic>i.e.</italic>, <italic>Send</italic>(<italic>GW</italic>,<italic>{ID<sub>k</sub></italic>,<italic>Pass}</italic>)) is specifies <italic>GW</italic> list, as shown below:
<list list-type="simple">
<list-item>
<p>▪ <italic>Hash</italic>(<italic>h</italic>(.)<italic>; XOR</italic>(<italic>r</italic>, <italic>PW<sub>k</sub></italic>))→<italic>Pass</italic></p></list-item>
<list-item>
<p>▪ <italic>Send</italic>(<italic>GW</italic>, <italic>{ID<sub>k</sub>, Pass}</italic>)</p></list-item>
<list-item>
<p>▪ <italic>Update</italic>(<italic>{ID<sub>k</sub>, PW<sub>k</sub>, r}</italic>)</p></list-item></list></p>
<p>Now GW’s Phase-I actions behavior lists takes place [<italic>i.e.</italic>, <italic>BL</italic>(<italic>GW</italic>)] and first seven actions are executed in <italic>BL</italic>(<italic>GW</italic>). After the <italic>Update</italic> operation, the next operations have to be executed in the user’s behavior list as below, the <italic>Send</italic> operation [<italic>Send</italic>(<italic>U</italic>, <italic>{A<sub>k</sub></italic>, <italic>B<sub>k</sub></italic>, <italic>V<sub>k</sub></italic>, <italic>h</italic>(.),<italic>E<sub>k</sub>,D<sub>k</sub>}</italic>)] assigned to <italic>U</italic>. Then the <italic>Forget</italic> operation removes all values (<italic>i.e.</italic>, <italic>A<sub>k</sub></italic>,<italic>B<sub>k</sub></italic>,<italic>V<sub>k</sub>,E<sub>k</sub>,D<sub>k</sub></italic>) from the local possession set [<italic>POSS</italic>(<italic>GW</italic>)], as shown below:
<list list-type="simple">
<list-item>
<p>▪ <italic>Receive</italic>(<italic>U</italic>, <italic>{ID<sub>k</sub>, Pass}</italic>)</p></list-item>
<list-item>
<p>▪ <italic>Generate-secret number</italic>(<italic>l</italic>)</p></list-item>
<list-item>
<p>▪ <italic>Hash</italic>(<italic>h</italic>(.)<italic>; XOR</italic>(<italic>ID<sub>k</sub>, l</italic>))→<italic>A<sub>k</sub></italic></p></list-item>
<list-item>
<p>▪ <italic>Encrypt</italic>(<italic>{Concat</italic>(<italic>ID<sub>k</sub>, l</italic>)<italic>}<sub>x</sub>)→B<sub>k</sub></italic></p></list-item>
<list-item>
<p>▪ <italic>Hash</italic>(<italic>h</italic>(.)<italic>; Concat</italic>(<italic>ID<sub>k</sub></italic>, <italic>Pass</italic>))<italic>→V<sub>k</sub></italic></p></list-item>
<list-item>
<p>▪ <italic>Send</italic>(<italic>U</italic>, {<italic>A<sub>k</sub>,B<sub>k</sub>,V<sub>k</sub>, h</italic>(.),<italic>E<sub>k</sub>,D<sub>k</sub>}</italic>)</p></list-item>
<list-item>
<p>▪ <italic>Update</italic>(<italic>{A<sub>k</sub>, B<sub>k</sub>, V<sub>k</sub>, h</italic>(.),<italic>E<sub>k</sub>,D<sub>k</sub>, Pass}</italic>)</p></list-item>
<list-item>
<p>▪ <italic>Forget</italic>(<italic>{A<sub>k</sub>, B<sub>k</sub>, V<sub>k</sub>, E<sub>k</sub>,D<sub>k</sub>, Pass}</italic>)</p></list-item></list></p>
<p>It is clear that after the end of the user and the gateway Phase-I, there is no significant change in their global sets, whereas, in the local sets of both entities (<italic>i.e</italic>., <italic>user</italic> and <italic>gateway</italic>) have are some changes, as shown:
<list list-type="simple">
<list-item>
<p><italic>POSS</italic>(<italic>U</italic>) = <italic>{ID<sub>k</sub>, PW<sub>k</sub>, r{A<sub>k</sub>, B<sub>k</sub>, V<sub>k</sub>, h</italic>(.),<italic>E<sub>k</sub>,D<sub>k</sub>}}</italic></p></list-item>
<list-item>
<p><italic>BEL</italic>(<italic>U</italic>) = <italic>{#</italic>(<italic>PW<sub>k</sub></italic>)<italic>}</italic></p></list-item>
<list-item>
<p><italic>POSS</italic>(<italic>GW</italic>) = <italic>{x</italic>,<italic>y</italic>,<italic>l</italic>,<italic>SK<sub>gs</sub>}</italic></p></list-item>
<list-item>
<p><italic>BEL</italic>(<italic>GW</italic>) = <italic>{#</italic>(<italic>x</italic>), <italic>#</italic>(<italic>y</italic>), <italic>#</italic>(<italic>l</italic>), <italic>#</italic>(<italic>SK<sub>gs</sub></italic>)<italic>}</italic></p></list-item></list></p>
<p>This is the end of Phase-I.</p>
<p>Subsequently, Phase-II begins and two entities (<italic>i.e.</italic>, <italic>User</italic> and <italic>Sensor</italic>) are involved in this phase. As, <italic>U</italic> is the initiator of the protocol, and thus next operations have to be executed in <italic>U’s</italic> behavior list (<italic>BL</italic>(<italic>U</italic>)), as follows:
<list list-type="simple">
<list-item>
<p>▪ <italic>Hash</italic>(<italic>h</italic>(.)<italic>; Concat</italic>(<italic>ID<sub>k</sub>, Pass</italic>))→
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mi>V</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula></p></list-item>
<list-item>
<p>▪ <italic>Check</italic>(
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mi>V</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula>, <italic>V<sub>k</sub></italic>)</p></list-item>
<list-item>
<p>▪ <italic>Hash</italic>(<italic>h</italic>(.)<italic>; A<sub>k</sub></italic>)→<italic>H<sub>k</sub></italic></p></list-item>
<list-item>
<p>▪ <italic>Generate-secret</italic>(<italic>X<sub>g</sub></italic>)</p></list-item>
<list-item>
<p>▪ <italic>Concat</italic>(<italic>Tu</italic>, <italic>H<sub>k</sub>)→TkTu</italic></p></list-item>
<list-item>
<p>▪ <italic>Encrypt</italic>(<italic>{Concat</italic>(<italic>Hash</italic>(<italic>h</italic>(.)<italic>;ID<sub>k</sub></italic>, <italic>Sn</italic>, <italic>X<sub>g</sub></italic>))<italic>}<sub>TkTu</sub></italic>)→<italic>AID<sub>k</sub></italic></p></list-item>
<list-item>
<p>▪ <italic>Send</italic>(<italic>Sn</italic>,<italic>{B<sub>k</sub>, AID<sub>k</sub>, Tu}</italic>)→<italic>M1</italic></p></list-item>
<list-item>
<p>▪ <italic>Update</italic>(<italic>ID<sub>k</sub>, X<sub>g</sub>, Sn</italic>, <italic>Tu</italic>)</p></list-item></list></p>
<p>After the <italic>Update</italic> operation, the following changes will takes place in <italic>BL</italic>(<italic>U</italic>).
<list list-type="simple">
<list-item>
<p><italic>POSS</italic>(<italic>U) = {ID<sub>k</sub></italic>, <italic>V<sub>k</sub></italic>, <italic>X<sub>g</sub></italic>, <italic>TkTu</italic>, <italic>AID<sub>k</sub></italic>, <italic>A<sub>k</sub></italic>, <italic>H<sub>k</sub>}</italic></p></list-item>
<list-item>
<p><italic>BEL</italic>(<italic>U</italic>) = <italic>{#</italic>(<italic>X<sub>g</sub></italic>), <italic>#</italic>(<italic>TkTu</italic>)<italic>}</italic></p></list-item></list></p>
<p>The global set of entity <italic>U</italic> will change with the following:
<list list-type="bullet">
<list-item>
<p><italic>Observers</italic>(<italic>X<sub>g</sub></italic>)<italic>: {U}</italic></p></list-item></list></p>
<p>The <italic>next</italic> operations have to be executed in <italic>Sn’s</italic> behavior list [<italic>BL</italic>(<italic>Sn</italic>)], because the above <italic>Send</italic> operation (<italic>i.e.</italic>, <italic>Send</italic>(<italic>Sn</italic>,<italic>{Bk</italic>, <italic>AIDk</italic>, <italic>Tu}</italic>)<italic>→M1</italic>) specifies <italic>Sn</italic>. Upon receiving the <italic>Receive</italic> operation (<italic>i.e.</italic>, <italic>Receive</italic> (<italic>U</italic>,<italic>{M1}</italic>)), <italic>Sn</italic> does the following:
<list list-type="simple">
<list-item>
<p>▪ <italic>Receive</italic>(<italic>U</italic>, <italic>{M1}</italic>) <italic>[</italic>Here <italic>M1 =</italic> (<italic>B<sub>k</sub>, AID<sub>k</sub>, Tu)]</italic></p></list-item>
<list-item>
<p>▪ <italic>Split</italic>(<italic>M1</italic>)</p></list-item>
<list-item>
<p>▪ <italic>Check-freshness</italic> (<italic>Ts</italic> – <italic>Tu</italic>) ≥Δ<italic>T</italic>, if yes, then aborts.</p></list-item>
<list-item>
<p>▪ <italic>MAC</italic>(<italic>{Concat</italic>(<italic>B<sub>k</sub></italic>, <italic>AID<sub>k</sub></italic>, <italic>Tu</italic>, <italic>Ts</italic>, <italic>Sn</italic>)<italic>}SK<sub>gs</sub></italic>)<italic>→Q</italic></p></list-item>
<list-item>
<p>▪ <italic>Send</italic>(<italic>GW</italic>, <italic>{M2</italic>, <italic>Q}</italic>) <italic>[</italic>Here <italic>M2</italic> = (<italic>B<sub>k</sub>,AID<sub>k</sub>, Tu</italic>, <italic>Ts, Sn</italic>)<italic>]</italic></p></list-item>
<list-item>
<p>▪ <italic>Update</italic>(<italic>M2</italic>, <italic>Q</italic>)</p></list-item></list></p>
<p>The <italic>Update</italic> operation makes the following changes in <italic>BL</italic>(<italic>Sn</italic>):
<list list-type="bullet">
<list-item>
<p><italic>POSS</italic>(<italic>Sn</italic>) <italic>= {B<sub>k</sub></italic>, <italic>AID<sub>k</sub></italic>, <italic>Tu</italic>, <italic>Ts</italic>, <italic>Sn</italic>, <italic>Q</italic>, <italic>SK<sub>gs</sub>}</italic></p></list-item>
<list-item>
<p><italic>BEL</italic>(<italic>Sn</italic>) <italic>= {#</italic>(<italic>SK<sub>gs</sub></italic>)<italic>}</italic></p></list-item></list></p>
<p>As we can see the next operations will be executed in <italic>GW’s</italic> behavior list [<italic>BL</italic>(<italic>GW</italic>)], as the above <italic>Sn Send</italic> operation (<italic>i.e.</italic>, <italic>Send</italic>(<italic>GW</italic>,<italic>{M2</italic>, <italic>Q}</italic>)) specifies to <italic>GW</italic>. Upon receiving the <italic>Receive</italic> operation [<italic>i.e.</italic>, <italic>Receive</italic> (<italic>Sn</italic>,<italic>{M2</italic>,<italic>Q}</italic>) ] from <italic>Sn</italic>. Now, <italic>BL</italic>(<italic>GW</italic>) performs the following operations:
<list list-type="simple">
<list-item>
<p>▪ <italic>Receive</italic>(<italic>Sn</italic>, <italic>{M2</italic>, <italic>Q}</italic>)<italic>[</italic>Here <italic>M2 = B<sub>k</sub></italic>, <italic>AID<sub>k</sub></italic>, <italic>Tu</italic>, <italic>Ts</italic>, <italic>Sn]</italic></p></list-item>
<list-item>
<p>▪ <italic>Split</italic>(<italic>M2</italic>, <italic>Q</italic>)</p></list-item>
<list-item>
<p>▪ <italic>Split</italic>(<italic>M2</italic>)</p></list-item>
<list-item>
<p>▪ <italic>Check-freshness</italic> (<italic>Tg</italic> – <italic>Ts</italic>) <italic>≥</italic> Δ<italic>T</italic>, if yes, then aborts.</p></list-item>
<list-item>
<p>▪ <italic>MAC</italic>(<italic>{B<sub>k</sub></italic>, <italic>AID<sub>k</sub></italic>, <italic>Tu</italic>, <italic>Ts</italic>, <italic>Sn}<sub>SKgs</sub></italic>)<italic>→Q′</italic></p></list-item>
<list-item>
<p>▪ <italic>Check</italic>(<italic>Q</italic>, <italic>Q′</italic>)</p></list-item>
<list-item>
<p>▪ <italic>Decrypt</italic>(<italic>{B<sub>k</sub>}<sub>x</sub></italic>) and obtain <italic>[</italic>
<inline-formula>
<mml:math>
<mml:mrow>
<mml:mi>I</mml:mi>
<mml:msubsup>
<mml:mrow>
<mml:mi>D</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>'</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula>, <italic>l′]</italic></p></list-item>
<list-item>
<p>▪ <italic>Hash</italic>(<italic>h</italic>(.);
<inline-formula>
<mml:math>
<mml:mrow>
<mml:mi>I</mml:mi>
<mml:msubsup>
<mml:mrow>
<mml:mi>D</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>'</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula>)</p></list-item>
<list-item>
<p>▪ <italic>Hash</italic>(<italic>h</italic>(.)<italic>; XOR</italic>(
<inline-formula>
<mml:math>
<mml:mrow>
<mml:mi>I</mml:mi>
<mml:msubsup>
<mml:mrow>
<mml:mi>D</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>'</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula>, <italic>l′</italic>)) <italic>→A<sub>k</sub>′</italic></p></list-item>
<list-item>
<p>▪ <italic>Hash</italic>
<inline-formula>
<mml:math>
<mml:mrow>
<mml:mi>h</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mo>.</mml:mo>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>;</mml:mo>
<mml:msubsup>
<mml:mrow>
<mml:mi>A</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>'</mml:mo></mml:msubsup>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>→</mml:mo>
<mml:msubsup>
<mml:mrow>
<mml:mi>H</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>'</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula></p></list-item>
<list-item>
<p>▪ <italic>Concat</italic>(<italic>Tu</italic>, 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mi>H</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>'</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula>)<italic>→TkTu</italic></p></list-item>
<list-item>
<p>▪ <italic>Decrypt</italic>(<italic>{AID<sub>k</sub>}<sub>TkTu</sub></italic>) and obtain<italic>[h</italic>(
<inline-formula>
<mml:math>
<mml:mrow>
<mml:mi>I</mml:mi>
<mml:msubsup>
<mml:mrow>
<mml:mi>D</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula>), <italic>Sn*</italic>, <italic>X<sub>g</sub>]</italic></p></list-item>
<list-item>
<p>▪ <italic>Check</italic>(<italic>h</italic>(
<inline-formula>
<mml:math>
<mml:mrow>
<mml:mi>I</mml:mi>
<mml:msubsup>
<mml:mrow>
<mml:mi>D</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula>), <italic>h</italic>(
<inline-formula>
<mml:math>
<mml:mrow>
<mml:mi>I</mml:mi>
<mml:msubsup>
<mml:mrow>
<mml:mi>D</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>'</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula>))</p></list-item>
<list-item>
<p>▪ <italic>Check</italic>(<italic>Sn*</italic>, <italic>Sn</italic>)</p></list-item>
<list-item>
<p>▪ <italic>Encrypt</italic>(<italic>{Concat</italic>(<italic>Hash</italic>(<italic>h</italic>(.)<italic>; ID<sub>k</sub></italic>), <italic>X<sub>g</sub></italic>, <italic>Tg</italic>)<italic>}<sub>SKgs</sub></italic>)<italic>→C</italic></p></list-item>
<list-item>
<p>▪ <italic>Send</italic>(<italic>Sn</italic>, <italic>{ Tg</italic>, <italic>C }</italic>)<italic>→M3</italic></p></list-item>
<list-item>
<p>▪ <italic>Update</italic>(<italic>Tg</italic>, <italic>C</italic>)</p></list-item></list></p>
<p>After applying <italic>Update</italic> operation the following changes take place in the gateway entity:
<list list-type="simple">
<list-item>
<p><italic>POSS</italic>(<italic>GW</italic>) <italic>= {ID<sub>k</sub></italic>, <italic>H<sub>k</sub></italic>, <italic>X<sub>g</sub></italic>, <italic>SK<sub>gs</sub></italic>, <italic>Sn</italic>, <italic>l</italic>, <italic>x</italic>, <italic>y</italic>, <italic>{B<sub>k</sub></italic>, <italic>AID<sub>k</sub></italic>, <italic>Tu</italic>, <italic>Ts</italic>, <italic>Sn}</italic> and <italic>{MAC{B<sub>k</sub></italic>, <italic>AID<sub>k</sub></italic>, <italic>Tu</italic>, <italic>Ts</italic>, <italic>Sn}<sub>Skgs</sub>}</italic>from <italic>Sn}</italic></p></list-item>
<list-item>
<p><italic>BEL</italic>(<italic>GW</italic>) <italic>= {#</italic>(<italic>SK<sub>gs</sub></italic>),<italic>#</italic>(<italic>x</italic>), <italic>#</italic>(<italic>y</italic>), <italic>#</italic>(<italic>l</italic>),<italic>#</italic>(<italic>Tg</italic>)<italic>}</italic></p></list-item></list></p>
<p>Subsequently, the global set of entity <italic>GW</italic> will change with the following:
<list list-type="simple">
<list-item>
<p><italic>Observers</italic>(<italic>X<sub>g</sub></italic>)<italic>: {U</italic>, <italic>GW}</italic></p></list-item></list></p>
<p>The next operations have to be executed in Phase-III of <italic>BL</italic>(<italic>Sn</italic>), because the above <italic>Send</italic> operation [<italic>i.e.</italic>, <italic>Send</italic>(<italic>Sn</italic>, <italic>{Tg</italic>, <italic>C}</italic>)] specifies <italic>Sn</italic> and upon receiving the <italic>Receive</italic> operation [<italic>i.e.</italic>, <italic>Receive</italic>(<italic>GW</italic>,<italic>{Tg</italic>, <italic>C}</italic>)] <italic>Sn</italic> will do the following:
<list list-type="simple">
<list-item>
<p>▪ <italic>Receive</italic>(<italic>GW</italic>, <italic>{Tg</italic>, <italic>C}</italic>).</p></list-item>
<list-item>
<p>▪ <italic>Split</italic>(<italic>Tg</italic>, <italic>C</italic>).</p></list-item>
<list-item>
<p>▪ <italic>Check-freshness</italic> (<italic>Ts</italic> – <italic>Tg</italic>) <italic>≥</italic> Δ<italic>T</italic>, if yes, then aborts.</p></list-item>
<list-item>
<p>▪ <italic>Decrypt</italic>(<italic>{C}<sub>SKgs</sub></italic>) and obtain <italic>[h</italic>(<italic>ID<sub>k</sub></italic>, <italic>X<sub>g</sub></italic>, <italic>Tg*</italic>)<italic>].</italic></p></list-item>
<list-item>
<p>▪ <italic>Check</italic>(<italic>Tg*</italic>, <italic>Tg</italic>).</p></list-item>
<list-item>
<p>▪ <italic>Hash</italic>(<italic>h</italic>(.)<italic>; Concat</italic>(<italic>Hash</italic>(.)<italic>; ID<sub>k</sub></italic>, <italic>X<sub>g</sub></italic>, <italic>Sn</italic>, <italic>Ts</italic>, <italic>Tu</italic>))<italic>→Ses<sub>K.</sub></italic></p></list-item>
<list-item>
<p>▪ <italic>Encrypt</italic>(<italic>{Concat</italic>(<italic>X<sub>g</sub></italic>, <italic>Ts</italic>)<italic>}<sub>SesK</sub></italic>)<italic>→L.</italic></p></list-item>
<list-item>
<p>▪ <italic>Send</italic>(<italic>U</italic>, <italic>{L</italic>, <italic>Ts}</italic>)<italic>→M4.</italic></p></list-item>
<list-item>
<p>▪ <italic>Update</italic>(<italic>L</italic>, <italic>Ts</italic>).</p></list-item></list></p>
<p>After applying the <italic>Update</italic> operation on the received message, the following changes will occur in the <italic>Sn</italic> entity:
<list list-type="simple">
<list-item>
<p><italic>POSS</italic>(<italic>Sn</italic>) <italic>= { SK<sub>gs</sub></italic>, <italic>Ses<sub>K</sub></italic>, <italic>Ts{ID<sub>k</sub></italic>, <italic>X<sub>g</sub></italic>, <italic>Tg}SK<sub>gs</sub></italic> from <italic>GW}</italic></p></list-item>
<list-item>
<p><italic>BEL</italic>(<italic>Sn</italic>) <italic>= {#</italic>(<italic>SK<sub>gs</sub></italic>), <italic>#</italic>(<italic>Ses<sub>K</sub></italic>), <italic>#</italic>(<italic>X<sub>g</sub></italic>), <italic>#</italic>(<italic>Ts</italic>)<italic>}</italic></p></list-item></list></p>
<p>The following changes will occur in the global set of the entity <italic>Sn</italic>:
<list list-type="simple">
<list-item>
<p><italic>Observers</italic>(<italic>X<sub>g</sub></italic>)<italic>: {U</italic>, <italic>GW</italic>, <italic>Sn}</italic></p></list-item>
<list-item>
<p><italic>Observers</italic>(<italic>Ses<sub>K</sub></italic>)<italic>: {Sn}</italic></p></list-item></list></p>
<p>Thereafter, the next operations have to be executed in Phase-III of <italic>BL</italic>(<italic>U</italic>). Since the above <italic>Send</italic> operation [<italic>i.e.</italic>, <italic>Send</italic>(<italic>U</italic>, <italic>{L</italic>, <italic>Ts}</italic>)] specifies <italic>U</italic> entity and <italic>BL</italic>(<italic>U</italic>) perform the following actions:
<list list-type="simple">
<list-item>
<p>▪ <italic>Receive</italic>(<italic>Sn</italic>, <italic>{L</italic>, <italic>Ts}</italic>)<italic>→M4 [</italic>Here <italic>L=ESes<sub>K</sub>[X<sub>g</sub>||Ts]]</italic></p></list-item>
<list-item>
<p>▪ <italic>Split</italic>(<italic>{L</italic>, <italic>Ts}</italic>)</p></list-item>
<list-item>
<p>▪ <italic>Check-freshness</italic> (<italic>Tu</italic> – <italic>Ts</italic>) <italic>≥</italic> Δ<italic>T</italic>, if yes, then aborts.</p></list-item>
<list-item>
<p>▪ <italic>Hash</italic>(<italic>h</italic>(.)<italic>; Concat</italic>(<italic>Hash</italic>(<italic>h</italic>(.)<italic>; ID<sub>k</sub></italic>, <italic>X<sub>g</sub></italic>, <italic>Sn</italic>, <italic>Ts</italic>, <italic>Tu</italic>)))<italic>→Ses<sub>K</sub></italic></p></list-item>
<list-item>
<p>▪ <italic>Decrypt</italic>(<italic>{L}<sub>SesK</sub></italic>) and obtain (
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mi>X</mml:mi></mml:mrow>
<mml:mi>g</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula>, <italic>Ts*</italic>)</p></list-item>
<list-item>
<p>▪ <italic>Check</italic>(<italic>X<sub>g</sub></italic>, 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mi>X</mml:mi></mml:mrow>
<mml:mi>g</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula>)</p></list-item>
<list-item>
<p>▪ <italic>Check</italic>(<italic>Ts</italic>, <italic>Ts*</italic>)</p></list-item></list></p>
<p>In the <italic>Check</italic> operation <italic>U</italic>’s verify <italic>X<sub>g</sub></italic>, which was generated by him/her and verify time-stamp <italic>Ts</italic>. If the <italic>Check</italic> operations are successful then the following changes will occur in <italic>BL</italic>(<italic>U</italic>):</p>
<p>Local set:
<list list-type="simple">
<list-item>
<p><italic>POSS</italic>(<italic>U</italic>) <italic>= {X<sub>g</sub></italic>, <italic>Sn</italic>, <italic>Ses<sub>K</sub>}</italic></p></list-item>
<list-item>
<p><italic>BEL</italic>(<italic>U</italic>) <italic>= {#</italic>(<italic>X<sub>g</sub></italic>), <italic>#</italic>(<italic>Ses<sub>K</sub></italic>)<italic>}</italic></p></list-item></list></p>
<p>Now finally the global set contains:
<list list-type="simple">
<list-item>
<p><italic>Observers</italic>(<italic>X<sub>g</sub></italic>)<italic>: {U</italic>, <italic>GW</italic>, <italic>Sn}</italic></p></list-item>
<list-item>
<p><italic>Observers</italic>(<italic>Ses<sub>K</sub></italic>)<italic>: {U</italic>, <italic>Sn}</italic></p></list-item></list></p>
<p>The application of Rubin logic in our framework is illustrated above, which closely resembles the structure of real user authentication system in wireless sensor network. Our specifications are designed to resemble actual implementation as much as possible.</p></sec></sec></sec>
<sec>
<label>6.</label>
<title>Evaluation of RUASN</title>
<p>In this section, we present our proposed <italic>RUASN</italic> evaluation in terms of security analysis (<italic>i.e.</italic>, <italic>can it resist against several well-known attacks</italic>), and efficiency analysis in terms of computational and communication cost. Finally, we show a functionality comparison with existing schemes.</p>
<p>Before evaluating the RUASN, it is assumed that an adversary may have full control over the network with following capabilities:
<list list-type="bullet">
<list-item>
<p>An adversary may intercept all the messages (<italic>i.e.</italic>, <italic>M1</italic>, <italic>M2</italic>, <italic>M3 and M4</italic>) at any time.</p></list-item>
<list-item>
<p>He/she may intercept, delete or modify, and insert any message over the public network.</p></list-item>
<list-item>
<p>In addition, we assume that an adversary may hack either passwords or steal user <italic>U<sub>k</sub>’s</italic> smart card, extract secrets [<xref ref-type="bibr" rid="b36-sensors-11-05020">36</xref>,<xref ref-type="bibr" rid="b37-sensors-11-05020">37</xref>], but cannot do both at the same time [<xref ref-type="bibr" rid="b38-sensors-11-05020">38</xref>].</p></list-item>
<list-item>
<p>As per the current literature, extracting secrets from the smart card memory is quite difficult and some smart card manufacturer companies provide countermeasures against risk of side channel attacks [<xref ref-type="bibr" rid="b18-sensors-11-05020">18</xref>,<xref ref-type="bibr" rid="b36-sensors-11-05020">36</xref>]. Furthermore, [<xref ref-type="bibr" rid="b39-sensors-11-05020">39</xref>] has proposed countermeasures against power analysis attacks.</p></list-item></list></p>
<p>Based on above assumptions, an attacker may execute certain attacks to breach the proposed RUASN scheme.</p>
<sec sec-type="methods">
<label>6.1.</label>
<title>Security Analysis</title>
<p>In this subsection, we analyze the security of proposed RUASN and further compare with the M.L, Das [<xref ref-type="bibr" rid="b18-sensors-11-05020">18</xref>], He <italic>et al</italic>. [<xref ref-type="bibr" rid="b21-sensors-11-05020">21</xref>], Wong <italic>et al</italic>. [<xref ref-type="bibr" rid="b10-sensors-11-05020">10</xref>], and Vaidya <italic>et al</italic>. [<xref ref-type="bibr" rid="b14-sensors-11-05020">14</xref>] schemes. We prove that the presented scheme can resist certain popular attacks that are found in the existing wireless sensor network literature.</p>
<p><bold><italic>Mutual Authentication</italic></bold>. Our scheme provides mutual authentication, where all entities (<italic>i.e.</italic>, <italic>user</italic>, <italic>gateway</italic> and <italic>sensor node</italic>) are mutually authenticating each other. More specifically, when the <italic>GW</italic> node receives the message <italic>M2</italic> (<italic>i.e.</italic>, <italic>&lt;B<sub>k</sub></italic>, <italic>AID<sub>k</sub></italic>, <italic>Tu</italic>, <italic>Ts</italic>, <italic>Sn&gt;</italic>) and <italic>Q</italic>, it can make sure that the user message <italic>M1</italic> (<italic>i.e.</italic>, <italic>&lt;B<sub>k</sub></italic>, <italic>AID<sub>k</sub></italic>, <italic>Tu&gt;</italic>) is included in the sensor node message <italic>M2</italic>. When the sensor node receives message <italic>M3</italic> (<italic>i.e.</italic>, <italic>&lt;Tg</italic>, <italic>C&gt;</italic>), it ensures that this message is generated by the <italic>GW</italic> node. Furthermore, when the user receives message <italic>M4</italic> (<italic>i.e.</italic>, <italic>&lt;L</italic>, <italic>Ts&gt;</italic>), he/she can also confirm that this message is generated by the sensor node. Hence, mutual authentication is achieved.</p>
<p><bold><italic>User anonymity</italic></bold>. In our scheme, user anonymity <italic>U<sub>k</sub></italic> is preserved at the registration phase by computing <italic>A<sub>k</sub></italic> <italic>= h</italic>(<italic>ID<sub>k</sub>⊕ l</italic>) <italic>and B<sub>k</sub></italic> <italic>= E<sub>x</sub>[ID<sub>k</sub>||l]</italic>. In addition, it is impossible to extract <italic>ID<sub>k</sub></italic> from the <italic>AID<sub>k</sub></italic>, which is <italic>E<sub>TkTu</sub>[h</italic>(<italic>ID<sub>k</sub></italic>)<italic>||Sn||X<sub>g</sub>]</italic>, and it is also very difficult to revert the <italic>h</italic>(<italic>ID<sub>k</sub></italic>). So, our scheme can preserve user anonymity.</p>
<p><bold><italic>Session Key Establishment</italic></bold>. The proposed scheme provides session key establishment after the authentication phase. A session key [<italic>i.e</italic>., <italic>Ses<sub>K</sub></italic> <italic>= h</italic>(<italic>h</italic>(<italic>ID<sub>k</sub></italic>)<italic>||X<sub>g</sub>||Sn||Ts||Tu</italic>)] is set up between the user and the sensor node for secure subsequent communication. The <italic>Ses<sub>K</sub></italic> will be different for each login session and cannot be replayed after the time expires. More importantly, the user and the sensor node can securely execute encryptions and decryptions by using of <italic>Ses<sub>K</sub></italic> and hence, achieve confidentiality for the subsequent messages.</p>
<p><bold><italic>Confidentiality</italic></bold>. Our proposed scheme provides adequate confidentiality to their messages (<italic>such as</italic>, <italic>E<sub>TkTu</sub>[h</italic>(<italic>ID<sub>k</sub></italic>)<italic>||Sn||X<sub>g</sub>]</italic>, <italic>E<sub>SKgs</sub>[h</italic>(<italic>ID<sub>k</sub></italic>)<italic>||X<sub>g</sub>||Tg]</italic> and <italic>E<sub>SesK</sub>[X<sub>g</sub>||Ts]</italic>). More precisely, these messages are confidential from any attacker.</p>
<p><bold><italic>Replay Attacks</italic></bold>. Our scheme is resistant to replay attacks [<xref ref-type="bibr" rid="b42-sensors-11-05020">42</xref>], because the authenticity of messages <italic>&lt;M1&gt;</italic>, <italic>&lt;M2&gt;</italic>, <italic>&lt;M3&gt; and &lt;M4&gt;</italic> are validated by checking the freshness of four timestamps ((<italic>Ts – Tu</italic>) <italic>≥</italic> Δ<italic>T</italic>, (<italic>Tg</italic> – <italic>Ts</italic>) <italic>≥</italic> Δ<italic>T</italic>, (<italic>Ts</italic> – <italic>Tg</italic>) <italic>≥</italic> Δ<italic>T</italic> and (<italic>Tu</italic> – <italic>Ts</italic>) <italic>≥</italic> Δ<italic>T</italic>). Let’s assume an intruder intercepts a login request message <italic>M1</italic> and attempt to access the sensor node by replaying the same message (<italic>M1</italic>). The verification of this login attempt fails, since the time difference expires (<italic>i.e.</italic>, (<italic>Ts – Tu</italic>) ≥ ΔT). Similarly, if an intruder intercepts a valid message <italic>M2</italic> (<italic>i.e.</italic>, <italic>&lt;B<sub>k</sub></italic>, <italic>AID<sub>k</sub></italic>, <italic>Tu</italic>, <italic>Ts</italic>, <italic>Sn&gt;</italic>) and attempts to replay it to the <italic>GW</italic> node, the verification request will fail at the <italic>GW</italic> node because of the time difference expires again (<italic>i.e.</italic>, (<italic>Tg</italic> – <italic>Ts</italic>) <italic>≥</italic> Δ<italic>T</italic>). Thus, our framework is secure against replaying of messages.</p>
<p><bold><italic>User Impersonation Attacks.</italic></bold> An attacker cannot impersonate the user. Suppose an attacker forges a login message <italic>&lt;B<sub>k</sub></italic>, <italic>AID<sub>k</sub></italic>, <italic>Tu&gt;</italic>. Now, he/she will again try to login into the system with the modified message &lt;
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mi>B</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula>, 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mtext mathvariant="italic">AID</mml:mtext></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula>, <italic>Tu</italic>&gt;, since, the fake 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mtext mathvariant="italic">AID</mml:mtext></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula> will not be verified at the <italic>GW</italic> node, and the <italic>GW</italic> node cannot get the original sub-message 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:mo>{</mml:mo>
<mml:mi>h</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:msubsup>
<mml:mrow>
<mml:mtext mathvariant="italic">ID</mml:mtext></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>||</mml:mo>
<mml:mtext mathvariant="italic">Sn</mml:mtext>
<mml:mo>*</mml:mo>
<mml:mo>}</mml:mo></mml:mrow></mml:math></inline-formula> by decrypting 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mtext mathvariant="italic">AID</mml:mtext></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula>. Therefore, it is not possible to impersonate the user.</p>
<p><bold><italic>Gateway Impersonation Attacks.</italic></bold> As long as an attacker does not possess the secret key <italic>SK<sub>gs</sub></italic>, he/she cannot impersonate the server and cannot cheat the sensor node. Hence, it frustrates attackers to generate the valid message <italic>M4</italic> to the sensor node.</p>
<p><bold><italic>Insider Attacks.</italic></bold> It is possible in a real-time environment, when the gateway manager or system administrator can use the user password <italic>PW<sub>k</sub></italic> (<italic>e.g.</italic>, <italic>weak password</italic>) to impersonate the user <italic>U<sub>k</sub></italic> through any other network gateways [<xref ref-type="bibr" rid="b20-sensors-11-05020">20</xref>,<xref ref-type="bibr" rid="b21-sensors-11-05020">21</xref>,<xref ref-type="bibr" rid="b40-sensors-11-05020">40</xref>]. In this case, our scheme does not give any room for privileged insiders, since, in the registration phase, the user <italic>U<sub>k</sub></italic> is passing <italic>h</italic>(<italic>r⊕PW<sub>k</sub></italic>) instead of the plain password. Thus, the insider of the <italic>GW</italic> node cannot get <italic>PW<sub>k</sub></italic> easily [<xref ref-type="bibr" rid="b20-sensors-11-05020">20</xref>,<xref ref-type="bibr" rid="b21-sensors-11-05020">21</xref>]. Here, <italic>r</italic> is a sufficiently high entropy number, which is not revealed to the <italic>GW</italic> node. Furthermore, the proposed scheme does not store any verifier table and can resist the insider attacks [<xref ref-type="bibr" rid="b41-sensors-11-05020">41</xref>].</p>
<p><bold><italic>Stolen-Verifier Attacks.</italic></bold> The stolen-verifier attack scenario is not applicable to our scheme, as we are not using any password/verifier table.</p>
<p><bold><italic>Offline-Password Guessing Attacks.</italic></bold> Our scheme is free from any password verifier table, so password guessing attacks are not feasible. In the login phase, passwords are not simply transmitted, instead, they are transmitted with some other secret (<italic>i.e.</italic>, <italic>V<sub>k</sub></italic> <italic>= h</italic>(<italic>ID<sub>k</sub>|| h</italic>(<italic>r⊕PW<sub>k</sub></italic>))), which makes it difficult to guess the user’s password.</p>
<p><bold><italic>Man-in-the-Middle Attacks.</italic></bold> An attacker may attempt a man-in-the-middle (<italic>MIMT</italic>) attack by modifying the login message <italic>&lt;B<sub>k</sub></italic>, <italic>AID<sub>k</sub></italic>, <italic>Tu&gt; into &lt;</italic>
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mi>B</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula>, 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mtext mathvariant="italic">AID</mml:mtext></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula>, <italic>Tu*&gt;</italic>. However, this malicious attempt will not work, as the false 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mtext mathvariant="italic">AID</mml:mtext></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula> will not be verified at the <italic>GW</italic> node and the <italic>GW</italic> node cannot get the original sub-message 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:mo>{</mml:mo>
<mml:mi>h</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:msubsup>
<mml:mrow>
<mml:mtext mathvariant="italic">ID</mml:mtext></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>|</mml:mo>
<mml:mo>|</mml:mo>
<mml:mtext mathvariant="italic">Sn</mml:mtext>
<mml:mo>*</mml:mo>
<mml:mo>}</mml:mo></mml:mrow></mml:math></inline-formula> by decrypting 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mtext mathvariant="italic">AID</mml:mtext></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula>. Thus, man-in-the-middle attacks are not applicable to the RUASN scheme.</p>
<p><bold><italic>Secure Password Update.</italic></bold> In the secure password update phase, our framework first verifies the old <italic>ID<sub>k</sub></italic>, <italic>PW<sub>k</sub></italic> and only then requests a new password. Otherwise, it rejects all password update requests. Therefore, our framework updates passwords securely.</p>
<p><bold><italic>Gateway Secret Key Guessing Attacks.</italic></bold> In our scheme, the gateway secret keys (<italic>x</italic> and <italic>y</italic>) are very long and possess high entropy. In addition, neither <italic>x</italic> nor <italic>y</italic> are transmitted in plain text over the public channel, instead <italic>x</italic> and <italic>y</italic> are mainly used as a key to encrypt data (<italic>Ex[IDk||l]</italic>, <italic>SKgs = h</italic>(<italic>Sn||y</italic>)). Hence, it is very difficult to guess both the gateway master keys, <italic>x</italic> and <italic>y</italic>.</p></sec>
<sec sec-type="methods">
<label>6.2.</label>
<title>Efficiency Analysis</title>
<p>In this subsection, we present an efficiency analysis (<italic>i.e.</italic>, <italic>computational cost</italic> and <italic>communication cost</italic>) of our scheme and compare it with existing schemes (Das [<xref ref-type="bibr" rid="b18-sensors-11-05020">18</xref>], He <italic>et al.</italic> [<xref ref-type="bibr" rid="b21-sensors-11-05020">21</xref>], Wong <italic>et al.</italic> [<xref ref-type="bibr" rid="b10-sensors-11-05020">10</xref>] and Vaidya <italic>et al.</italic> [<xref ref-type="bibr" rid="b14-sensors-11-05020">14</xref>]) for wireless sensor networks. The evaluation parameters are shown below:
<list list-type="simple">
<list-item>
<p><bold><italic>H</italic></bold>: performing one-way hash function.</p></list-item>
<list-item>
<p><bold><italic>S</italic></bold>: symmetric cryptosystem.</p></list-item>
<list-item>
<p><bold><italic>MAC</italic></bold>: the time for performing a <italic>MAC.</italic></p></list-item></list></p>
<p><bold><italic>Computation Cost:</italic></bold> <italic>RUASN</italic> adopts low-cost computations like a one-way hash function and symmetric cryptosystem, which is acceptable for WSNs and provides more security features with reasonable computational costs. As we can see the computation cost comparisons of our scheme and other related scheme are summarized in <xref ref-type="table" rid="t4-sensors-11-05020">Table 4</xref>. It is easy to see that, in the registration phase (<italic>i.e.</italic>, <italic>one-time job</italic>) our scheme requires <italic>4H</italic> and one symmetric cryptosystem, whereas in [<xref ref-type="bibr" rid="b21-sensors-11-05020">21</xref>] and [<xref ref-type="bibr" rid="b14-sensors-11-05020">14</xref>] <italic>6H</italic> and <italic>4H</italic> are required, respectively. Furthermore, in the login and authentication phase the proposed scheme requires <italic>9H</italic>, <italic>6S</italic> and <italic>2MAC</italic>, whereas, [<xref ref-type="bibr" rid="b18-sensors-11-05020">18</xref>,<xref ref-type="bibr" rid="b21-sensors-11-05020">21</xref>] and [<xref ref-type="bibr" rid="b14-sensors-11-05020">14</xref>] require <italic>9H</italic>, <italic>11H</italic> and <italic>9H</italic>, respectively. This is due to fact that in order to provide more functionality such as mutual authentication, user anonymity, message confidentiality, and secure session key establishment, more computational costs are incurred.</p>
<p><bold><italic>Communication Cost:</italic></bold> It is easy to visualize from <xref ref-type="fig" rid="f3-sensors-11-05020">Figure 3</xref> that <italic>RUASN</italic> requires four message exchanges for the whole communication and confirmation of all entities (<italic>i.e.</italic>, <italic>user</italic>, <italic>gateway</italic> and <italic>sensor</italic>), which is practical for real-time applications.</p></sec>
<sec sec-type="methods">
<label>6.3.</label>
<title>Functionality Analysis</title>
<p>From <xref ref-type="table" rid="t5-sensors-11-05020">Table 5</xref>, it is easy to see that the <italic>RUASN</italic> has more security functionality as compared to other existing proposed protocols for WSNs. Our scheme has robust security features such as mutual authentication between all entities (<italic>i.e.</italic>, <italic>user</italic>, <italic>gateway</italic> and <italic>sensor</italic>), user anonymity, confidentiality, secure session key establishment, secure password update phase and secure against insider attacks, and it meets all the requirements of Liao <italic>et al</italic>. [<xref ref-type="bibr" rid="b27-sensors-11-05020">27</xref>], which are discussed in Section 3.</p>
<p>As we have seen in the above analysis, it is clear that the <italic>RUASN</italic> is a robust user authentication protocol and provides more security services at less cost.</p></sec></sec>
<sec sec-type="conclusions">
<label>7.</label>
<title>Conclusions</title>
<p>In real-time, as the sensor networks themselves offer services to users; it is necessary to control who is accessing the information and if it he/she allowed to do so. Therefore, access control is an imperative requirement for wireless sensor networks to protect the data access from unauthorized parties.</p>
<p>In this regard, we have proposed a robust user authentication framework for wireless sensor networks, RUASN, which is based on a two-factor approach (<italic>i.e.</italic>, <italic>password</italic> and <italic>smart card</italic>) by exploiting the advantages of cryptographic hash functions and cryptosystems. We have shown a security analysis and performance analysis of the RUASN framework and compared it with recent existing schemes. Through analysis, we show that our scheme is more robust against many popular attacks, which are prominent risks for wireless sensor network and that it provides many security services (<italic>i.e.</italic>, <italic>mutual authentication</italic>, <italic>user anonymity</italic>, <italic>confidentiality</italic>, <italic>secure session key and allow users to choose/updates their password</italic>) at reasonable computational costs.</p></sec></body>
<back>
<ack>
<p>For the fourth author, this work was supported by 2010 National Research Foundation of Korea, and for the fifth author, this work was supported by Dongseo Frontier 2009 Project and 2010 National Research Foundation of Korea.</p></ack>
<ref-list>
<title>References</title>
<ref id="b1-sensors-11-05020"><label>1.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Akyildiz</surname><given-names>IF</given-names></name><name><surname>Su</surname><given-names>W</given-names></name><name><surname>Sankarasubramamiam</surname><given-names>Y</given-names></name><name><surname>Cayirci</surname><given-names>E</given-names></name></person-group><article-title>A survey on saensor network</article-title><source>IEEE Comm. Mag</source><year>2002</year><volume>40</volume><fpage>102</fpage><lpage>114</lpage></citation></ref>
<ref id="b2-sensors-11-05020"><label>2.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Perrig</surname><given-names>A</given-names></name><name><surname>Szewczyk</surname><given-names>R</given-names></name><name><surname>Web</surname><given-names>V</given-names></name><name><surname>Culler</surname><given-names>D</given-names></name><name><surname>Tygar</surname><given-names>JD</given-names></name></person-group><article-title>SPINS: Security protocol for sensor networks</article-title><conf-name>Proceeding of the 7th Annual International Conference on Mobile Computing and Networks (MOBBICOM 2001)</conf-name><conf-loc>Rome, Italy</conf-loc><conf-date>July 2001</conf-date></citation></ref>
<ref id="b3-sensors-11-05020"><label>3.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Karloff</surname><given-names>C</given-names></name><name><surname>Sastry</surname><given-names>N</given-names></name><name><surname>Wagner</surname><given-names>D</given-names></name></person-group><article-title>TinySec: A link layer security architecture for wireless sensor networks</article-title><conf-name>Proceeding of the 2nd ACM Conference on Embedded Networked Sensor System (SenSys 2004)</conf-name><conf-loc>Baltimore, MD, USA</conf-loc><conf-date>November 2004</conf-date></citation></ref>
<ref id="b4-sensors-11-05020"><label>4.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Watro</surname><given-names>R</given-names></name><name><surname>Kong</surname><given-names>D</given-names></name><name><surname>Cuti</surname><given-names>SF</given-names></name><name><surname>Gardiner</surname><given-names>C</given-names></name><name><surname>Lynn</surname><given-names>C</given-names></name><name><surname>Kruus</surname><given-names>P</given-names></name></person-group><article-title>TinyPK: Securing sensor networks with public key technology</article-title><conf-name>Proceedings of the 2nd ACM Workshop on Security of ad hoc and Sensor Networks, SASN '04</conf-name><conf-loc>Washington, DC, USA</conf-loc><conf-date>25 October 2004</conf-date></citation></ref>
<ref id="b5-sensors-11-05020"><label>5.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Luk</surname><given-names>M</given-names></name><name><surname>Mezzour</surname><given-names>G</given-names></name><name><surname>Perrig</surname><given-names>A</given-names></name><name><surname>Gligor</surname><given-names>V</given-names></name></person-group><article-title>MiniSec: A secure sensor network communication architecture</article-title><conf-name>Proceeding of the 6th International Conference on Information Processing in Sensor Networks, IPSN’07</conf-name><conf-loc>Cambridge, MA, USA</conf-loc><conf-date>25–27 April 2007</conf-date></citation></ref>
<ref id="b6-sensors-11-05020"><label>6.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Kumar</surname><given-names>P</given-names></name><name><surname>Cho</surname><given-names>S</given-names></name><name><surname>Lee</surname><given-names>DS</given-names></name><name><surname>Lee</surname><given-names>YD</given-names></name><name><surname>Lee</surname><given-names>HJ</given-names></name></person-group><article-title>TriSec: A secure data framework for wireless sensor networks using authenticated encryption</article-title><source>Int. J. Marit. Inf. Commun. Sci</source><year>2010</year><volume>8</volume><fpage>129</fpage><lpage>135</lpage></citation></ref>
<ref id="b7-sensors-11-05020"><label>7.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Karlof</surname><given-names>C</given-names></name><name><surname>Wagner</surname><given-names>D</given-names></name></person-group><article-title>Secure routing in wireless sensor networks: Attacks and countermeasure</article-title><source>Ad Hoc Netw</source><year>2003</year><fpage>293</fpage><lpage>315</lpage></citation></ref>
<ref id="b8-sensors-11-05020"><label>8.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Benenson</surname><given-names>Z</given-names></name><name><surname>Gartner</surname><given-names>F</given-names></name><name><surname>Kesdogan</surname><given-names>D</given-names></name></person-group><article-title>User Authentication in sensor network (extended abstract)</article-title><conf-name>Proceedings of the Informatik 2004, 34 Jahrestagung der Gesellschaft fur Informatik, Workshop on Sensor Networks</conf-name><conf-loc>Ulm, Germany</conf-loc><conf-date>September 2004</conf-date></citation></ref>
<ref id="b9-sensors-11-05020"><label>9.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Benenson</surname><given-names>Z</given-names></name><name><surname>Gedicke</surname><given-names>N</given-names></name><name><surname>Raivio</surname><given-names>O</given-names></name></person-group><article-title>Realizing robust user authentication in sensor networks</article-title><conf-name>Proceedings of the Workshop on Real-World Wireless Sensor Network (REALWSN’05)</conf-name><conf-loc>Stockholm, Sweden</conf-loc><conf-date>20–21 June 2005</conf-date></citation></ref>
<ref id="b10-sensors-11-05020"><label>10.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Wong</surname><given-names>KHM</given-names></name><name><surname>Zheng</surname><given-names>Y</given-names></name><name><surname>Cao</surname><given-names>J</given-names></name><name><surname>Wang</surname><given-names>S</given-names></name></person-group><article-title>A dynamic user authentication scheme for wireless sensor networks</article-title><conf-name>Proceedings of the IEEE International Conference on Sensor Networks, Ubiquitous, and Trustworthy Computing (SUTC’06)</conf-name><conf-loc>Taichung, Taiwan</conf-loc><conf-date>5–7 June 2006</conf-date></citation></ref>
<ref id="b11-sensors-11-05020"><label>11.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Tseng</surname><given-names>HR</given-names></name><name><surname>Jan</surname><given-names>RH</given-names></name><name><surname>Yang</surname><given-names>W</given-names></name></person-group><article-title>An improved dynamic user authentication scheme for wireless sensor networks</article-title><conf-name>Proceedings of the IEEE Global Communications Conference (GLOBECOM’07)</conf-name><conf-loc>Washington, DC, USA</conf-loc><conf-date>26–30 November 2007</conf-date><fpage>986</fpage><lpage>990</lpage></citation></ref>
<ref id="b12-sensors-11-05020"><label>12.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Lee</surname><given-names>TH</given-names></name></person-group><article-title>Simple dynamic user authentication protocols for wireless sensor networks</article-title><conf-name>Proceedings of the 2nd International Conference on Sensor Technologies and Application (SENSORCOMM’08)</conf-name><conf-loc>Cap Esterel, France</conf-loc><conf-date>25–31 August 2008</conf-date><fpage>657</fpage><lpage>660</lpage></citation></ref>
<ref id="b13-sensors-11-05020"><label>13.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Ko</surname><given-names>LC</given-names></name></person-group><article-title>A novel dynamic user authentication scheme for wireless sensor networks</article-title><conf-name>Proceeding of the IEEE International Symposium on Wireless Communication Systems 2008, ISWCS'08</conf-name><conf-loc>Reykjavik, Iceland</conf-loc><conf-date>21–24 October 2008</conf-date><fpage>608</fpage><lpage>612</lpage></citation></ref>
<ref id="b14-sensors-11-05020"><label>14.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Vaidya</surname><given-names>B</given-names></name><name><surname>Rodrigues</surname><given-names>JJPC</given-names></name><name><surname>Park</surname><given-names>JH</given-names></name></person-group><article-title>User authentication schemes with pseudonymity for ubiquitous sensor network in NGN</article-title><source>Int. J. Commun. Syst</source><year>2010</year><volume>23</volume><fpage>1201</fpage><lpage>1222</lpage><pub-id pub-id-type="doi">10.1002/dac.1097</pub-id></citation></ref>
<ref id="b15-sensors-11-05020"><label>15.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Banerjee</surname><given-names>S</given-names></name><name><surname>Mukhopadhyay</surname><given-names>D</given-names></name></person-group><article-title>Symmetric key based authenticated querying in wireless sensor networks</article-title><conf-name>Proceedings of the 1st ACM International Conference on Integrated Internet Ad hoc and Sensor Networks (InterSense)</conf-name><conf-loc>New York, NY, USA</conf-loc><conf-date>June 2002</conf-date><fpage>1278</fpage><lpage>1287</lpage></citation></ref>
<ref id="b16-sensors-11-05020"><label>16.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Yoon</surname><given-names>SJ</given-names></name><name><surname>Lee</surname><given-names>H</given-names></name><name><surname>Ji</surname><given-names>SB</given-names></name><name><surname>Kim</surname><given-names>K</given-names></name></person-group><article-title>A user authentication scheme with privacy protection for wireless sensor networks</article-title><conf-name>Proceedings of the 2nd Joint Workshop on Information Security</conf-name><conf-loc>Tokyo, Japan</conf-loc><conf-date>6–7 August 2007</conf-date><fpage>233</fpage><lpage>244</lpage></citation></ref>
<ref id="b17-sensors-11-05020"><label>17.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Li</surname><given-names>CT</given-names></name><name><surname>Lee</surname><given-names>CC</given-names></name></person-group><article-title>A novel user authentication and privacy preserving scheme with smart cards for wireless communications</article-title><source>Math Comput Modelling</source><year>2011</year><pub-id pub-id-type="doi">10.1016/j.mcm.2011.01.010.</pub-id></citation></ref>
<ref id="b18-sensors-11-05020"><label>18.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Das</surname><given-names>ML</given-names></name></person-group><article-title>Two-factor user authentication in wireless sensor networks</article-title><source>IEEE Trans. Wireless Comm</source><year>2009</year><volume>8</volume><fpage>1086</fpage><lpage>1090</lpage><pub-id pub-id-type="doi">10.1109/TWC.2008.080128</pub-id></citation></ref>
<ref id="b19-sensors-11-05020"><label>19.</label><citation citation-type="web"><person-group person-group-type="author"><name><surname>Nyang</surname><given-names>DH</given-names></name><name><surname>Lee</surname><given-names>MK</given-names></name></person-group><source>Improvement of Das’s Two-Factor Authentication Protocol in Wireless Sensor Networks</source><comment>Available Online: <ext-link xlink:href="http://eprint.iacr.org/2009/631.pdf/" ext-link-type="uri">http://eprint.iacr.org/2009/631.pdf/</ext-link> (accessed on 07 July 2010)</comment></citation></ref>
<ref id="b20-sensors-11-05020"><label>20.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Khan</surname><given-names>MK</given-names></name><name><surname>Alghathbar</surname><given-names>K</given-names></name></person-group><article-title>Cryptanalysis and security improvement of ‘two-factor user authentication in wireless sensor networks’</article-title><source>Sensors</source><year>2010</year><volume>10</volume><fpage>2450</fpage><lpage>2459</lpage><pub-id pub-id-type="doi">10.3390/s100302450</pub-id><pub-id pub-id-type="pmid">22294935</pub-id></citation></ref>
<ref id="b21-sensors-11-05020"><label>21.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>He</surname><given-names>D</given-names></name><name><surname>Gao</surname><given-names>Y</given-names></name><name><surname>Chan</surname><given-names>S</given-names></name><name><surname>Chen</surname><given-names>C</given-names></name><name><surname>Bu</surname><given-names>J</given-names></name></person-group><article-title>An enhanced two-factor user authentication scheme in wireless sensor networks</article-title><source>Int. J. Ad-Hoc Sensor Wirel. Netw</source><year>2010</year><volume>0</volume><fpage>1</fpage><lpage>11</lpage></citation></ref>
<ref id="b22-sensors-11-05020"><label>22.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>He</surname><given-names>DJ</given-names></name><name><surname>Mab</surname><given-names>MD</given-names></name><name><surname>Zhang</surname><given-names>Y</given-names></name><name><surname>Chen</surname><given-names>C</given-names></name><name><surname>Bu</surname><given-names>JJ</given-names></name></person-group><article-title>A strong user authentication scheme with smart cards for wireless communications</article-title><source>Comput. Commun</source><year>2011</year><volume>34</volume><fpage>367</fpage><lpage>374</lpage><pub-id pub-id-type="doi">10.1016/j.comcom.2010.02.031</pub-id></citation></ref>
<ref id="b23-sensors-11-05020"><label>23.</label><citation citation-type="web"><collab>RSA</collab><comment>Available Online: <ext-link xlink:href="http://www.rsa.com/node.aspx?id=1156" ext-link-type="uri">http://www.rsa.com/node.aspx?id=1156</ext-link> (accessed on 12 August 2010).</comment></citation></ref>
<ref id="b24-sensors-11-05020"><label>24.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Rubin</surname><given-names>AD</given-names></name><name><surname>Honeyman</surname><given-names>P</given-names></name></person-group><article-title>Nonmonotonic cryptographic protocols</article-title><conf-name>Proceedings of the Computer Security Foundation Workshop VII</conf-name><conf-loc>Franconia, NH, USA</conf-loc><conf-date>June 1994</conf-date><fpage>100</fpage><lpage>116</lpage></citation></ref>
<ref id="b25-sensors-11-05020"><label>25.</label><citation citation-type="web"><source>MICAz</source><comment>Available Online: <ext-link xlink:href="http://www.openautomation.net/uploadsproductos/micaz_datasheet.pdf" ext-link-type="uri">http://www.openautomation.net/uploadsproductos/micaz_datasheet.pdf</ext-link> (accessed on 10 January 2010).</comment></citation></ref>
<ref id="b26-sensors-11-05020"><label>26.</label><citation citation-type="web"><collab>TelosB Datasheet</collab><comment>Available Online: <ext-link xlink:href="http://www.willow.co.uk/TelosB_Datasheet.pdf/" ext-link-type="uri">http://www.willow.co.uk/TelosB_Datasheet.pdf/</ext-link> (accessed on 12 January 2010).</comment></citation></ref>
<ref id="b27-sensors-11-05020"><label>27.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Liao</surname><given-names>IE</given-names></name><name><surname>Lee</surname><given-names>CC</given-names></name><name><surname>Hwang</surname><given-names>MS</given-names></name></person-group><article-title>A password authentication scheme over insecure networks</article-title><source>J. Comput. Syst. Sci</source><year>2006</year><volume>72</volume><fpage>727</fpage><lpage>740</lpage><pub-id pub-id-type="doi">10.1016/j.jcss.2005.10.001</pub-id></citation></ref>
<ref id="b28-sensors-11-05020"><label>28.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Diffie</surname><given-names>W</given-names></name><name><surname>Hellman</surname><given-names>ME</given-names></name></person-group><article-title>New directions in Cryptography</article-title><source>IEEE Trans Inform Theory</source><year>1976</year><source>IT-22</source><fpage>644</fpage><lpage>654</lpage></citation></ref>
<ref id="b29-sensors-11-05020"><label>29.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Rivest</surname><given-names>RL</given-names></name><name><surname>Shamir</surname><given-names>A</given-names></name><name><surname>Adleman</surname><given-names>L</given-names></name></person-group><article-title>A method for obtaining digital signatures and public-key cryptosystems</article-title><source>Comm. ACM</source><year>1978</year><volume>21</volume><fpage>120</fpage><lpage>126</lpage><pub-id pub-id-type="doi">10.1145/359340.359342</pub-id></citation></ref>
<ref id="b30-sensors-11-05020"><label>30.</label><citation citation-type="web"><collab>National Institute of Standards and Technology</collab><source>FIPS PUB 180-1, Secure Hash Standard</source><publisher-name>US Department of Commerce</publisher-name><publisher-loc>Gaithersburg, MD, USA</publisher-loc><comment>Available Online <ext-link xlink:href="http://www.techheap.com/cryptography/hash/fip180-1.pdf/" ext-link-type="uri">http://www.techheap.com/cryptography/hash/fip180-1.pdf/</ext-link> (accessed on 9 August 2009).</comment></citation></ref>
<ref id="b31-sensors-11-05020"><label>31.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Čapkun</surname><given-names>S</given-names></name><name><surname>Čagalj</surname><given-names>M</given-names></name><name><surname>Karame</surname><given-names>G</given-names></name><name><surname>Tippenhauer</surname><given-names>NO</given-names></name></person-group><article-title>Integrity Regions: Authentication through Presence in Wireless Networks</article-title><source>IEEE Trans. Mob. Comput</source><year>2010</year><volume>9</volume><fpage>1608</fpage><lpage>1621</lpage><pub-id pub-id-type="doi">10.1109/TMC.2010.127</pub-id></citation></ref>
<ref id="b32-sensors-11-05020"><label>32.</label><citation citation-type="web"><person-group person-group-type="author"><name><surname>Sullivan</surname><given-names>B</given-names></name></person-group><source>Preventing a Brute Force or Dictionary Attack: How to Keep the Brutes Away from your Loot</source> <comment>Available Online: <ext-link xlink:href="http://h71028.www7.hp.com/ERC/cache/568358-0-0-0-121.html/" ext-link-type="uri">http://h71028.www7.hp.com/ERC/cache/568358-0-0-0-121.html/</ext-link> (accessed on 21 February 2010).</comment></citation></ref>
<ref id="b33-sensors-11-05020"><label>33.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Bellare</surname><given-names>M</given-names></name><name><surname>Kilian</surname><given-names>J</given-names></name><name><surname>Rogaway</surname><given-names>P</given-names></name></person-group><article-title>The security of the cipher block chaining message authentication code</article-title><source>J. Comput. Syst. Sci</source><year>2000</year><volume>61</volume><fpage>362</fpage><lpage>399</lpage><pub-id pub-id-type="doi">10.1006/jcss.1999.1694</pub-id></citation></ref>
<ref id="b34-sensors-11-05020"><label>34.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Vaidya</surname><given-names>B</given-names></name><name><surname>Park</surname><given-names>JH</given-names></name><name><surname>Yeo</surname><given-names>SS</given-names></name><name><surname>Rodrigues</surname><given-names>JJPC</given-names></name></person-group><article-title>Robust one-time password authentication scheme using smart card for home network environment</article-title><source>Comput. Commun</source><year>2011</year><volume>34</volume><fpage>326</fpage><lpage>336</lpage><pub-id pub-id-type="doi">10.1016/j.comcom.2010.03.013</pub-id></citation></ref>
<ref id="b35-sensors-11-05020"><label>35.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Das</surname><given-names>ML</given-names></name><name><surname>Narasimhan</surname><given-names>VL</given-names></name></person-group><article-title>Towards a formal verification of an authentication protocol using non-monotonic logic</article-title><conf-name>Proceedings of the 5th International Conference on Information Technology: New Generation</conf-name><conf-loc>CA, USA</conf-loc><year>2008</year><fpage>545</fpage><lpage>550</lpage></citation></ref>
<ref id="b36-sensors-11-05020"><label>36.</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Kocher</surname><given-names>P</given-names></name><name><surname>Jaffe</surname><given-names>J</given-names></name><name><surname>Jun</surname><given-names>B</given-names></name></person-group><article-title>Differential power analysis</article-title><conf-name>Proceeding of the Advances in Cryptology (CRYPTO’99)</conf-name><conf-loc>Santa Barbara, CA, USA</conf-loc><conf-date>15–19 August 1999</conf-date><fpage>388</fpage><lpage>397</lpage></citation></ref>
<ref id="b37-sensors-11-05020"><label>37.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Messerges</surname><given-names>TS</given-names></name><name><surname>Dabbish</surname><given-names>EA</given-names></name><name><surname>Sloan</surname><given-names>RH</given-names></name></person-group><article-title>Examining Smart-card security under the threat of Power Analysis attacks</article-title><source>IEEE Trans. Comput</source><year>2002</year><volume>51</volume><fpage>541</fpage><lpage>552</lpage><pub-id pub-id-type="doi">10.1109/TC.2002.1004593</pub-id></citation></ref>
<ref id="b38-sensors-11-05020"><label>38.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Yang</surname><given-names>G</given-names></name><name><surname>Wong</surname><given-names>DS</given-names></name><name><surname>Wang</surname><given-names>H</given-names></name><name><surname>Deng</surname><given-names>X</given-names></name></person-group><article-title>Two-factor mutual authentication based on smart card and passwords</article-title><source>J. Comput. Syst. Sci</source><year>2008</year><volume>74</volume><fpage>1160</fpage><lpage>1172</lpage><pub-id pub-id-type="doi">10.1016/j.jcss.2008.04.002</pub-id></citation></ref>
<ref id="b39-sensors-11-05020"><label>39.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Popp</surname><given-names>T</given-names></name><name><surname>Oswald</surname><given-names>E</given-names></name><name><surname>Mangard</surname><given-names>S</given-names></name></person-group><article-title>Power analysis attacks and countermeasuers</article-title><source>IEEE Des. Test. Comput</source><year>2007</year><volume>24</volume><fpage>535</fpage><lpage>543</lpage><pub-id pub-id-type="doi">10.1109/MDT.2007.200</pub-id></citation></ref>
<ref id="b40-sensors-11-05020"><label>40.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Ku</surname><given-names>WC</given-names></name><name><surname>Chen</surname><given-names>CM</given-names></name><name><surname>Lee</surname><given-names>HL</given-names></name></person-group><article-title>Cryptanalysis of a variant of peyravian-zunic’s password authentication scheme</article-title><source>IEICE Trans Commun</source><year>2003</year><source>E86-B</source><fpage>1682</fpage><lpage>1684</lpage></citation></ref>
<ref id="b41-sensors-11-05020"><label>41.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Ku</surname><given-names>WC</given-names></name><name><surname>Chen</surname><given-names>SM</given-names></name></person-group><article-title>Weaknesses and improvements of an efficient password based remote user authentication scheme using smart cards</article-title><source>IEEE Trans. Consum. Electron</source><year>2004</year><volume>50</volume><fpage>204</fpage><lpage>207</lpage><pub-id pub-id-type="doi">10.1109/TCE.2004.1277863</pub-id></citation></ref>
<ref id="b42-sensors-11-05020"><label>42.</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Chang</surname><given-names>CC</given-names></name><name><surname>Lee</surname><given-names>CY</given-names></name><name><surname>Chiu</surname><given-names>YC</given-names></name></person-group><article-title>Enhanced Authentication scheme with anonymity for roaming service in global mobility networks</article-title><source>Comput. Commun</source><year>2009</year><volume>32</volume><fpage>611</fpage><lpage>618</lpage><pub-id pub-id-type="doi">10.1016/j.comcom.2008.11.032</pub-id></citation></ref></ref-list>
<sec sec-type="display-objects">
<title>Figures and Tables</title>
<fig id="f1-sensors-11-05020" position="float">
<label>Figure 1.</label>
<caption>
<p>The basic system architecture for RUASN.</p></caption>
<graphic xlink:href="sensors-11-05020f1.gif"/></fig>
<fig id="f2-sensors-11-05020" position="float">
<label>Figure 2.</label>
<caption>
<p>Flow of registration phase.</p></caption>
<graphic xlink:href="sensors-11-05020f2.gif"/></fig>
<fig id="f3-sensors-11-05020" position="float">
<label>Figure 3.</label>
<caption>
<p>Flow of login and authentication phases.</p></caption>
<graphic xlink:href="sensors-11-05020f3.gif"/></fig>
<fig id="f4-sensors-11-05020" position="float">
<label>Figure 4.</label>
<caption>
<p>Flow of password update phase.</p></caption>
<graphic xlink:href="sensors-11-05020f4.gif"/></fig>
<table-wrap id="t1-sensors-11-05020" position="float">
<label>Table 1.</label>
<caption>
<p>Notation and symbols used in the paper.</p></caption>
<table frame="hsides" rules="groups">
<thead>
<tr>
<th align="left" valign="bottom"><bold>Notation</bold></th>
<th align="left" valign="bottom"><bold>Descriptions</bold></th></tr></thead>
<tbody>
<tr>
<td align="left" valign="top"><italic>GW</italic> node</td>
<td align="left" valign="top">WSN gateway node</td></tr>
<tr>
<td align="left" valign="top"><italic>U<sub>k</sub></italic></td>
<td align="left" valign="top"><italic>k</italic><sup>th</sup> User to be login</td></tr>
<tr>
<td align="left" valign="top"><italic>ID<sub>k</sub></italic></td>
<td align="left" valign="top">Login_ID of <italic>U<sub>k</sub></italic></td></tr>
<tr>
<td align="left" valign="top"><italic>PW<sub>k</sub></italic></td>
<td align="left" valign="top">Password of <italic>U<sub>k</sub></italic></td></tr>
<tr>
<td align="left" valign="top"><italic>x and y</italic></td>
<td align="left" valign="top">Gateway master keys</td></tr>
<tr>
<td align="left" valign="top"><italic>r</italic></td>
<td align="left" valign="top">Arbitrary random number selected by user</td></tr>
<tr>
<td align="left" valign="top"><italic>l</italic></td>
<td align="left" valign="top">Random number generated by the <italic>GW</italic> node</td></tr>
<tr>
<td align="left" valign="top"><italic>E<sub>key</sub></italic> <italic>[m]</italic></td>
<td align="left" valign="top">Message <italic>m</italic> is encrypted with symmetric <italic>key</italic></td></tr>
<tr>
<td align="left" valign="top"><italic>D<sub>key</sub></italic> <italic>[m]</italic></td>
<td align="left" valign="top">Message <italic>m</italic> is decrypted with symmetric <italic>key</italic></td></tr>
<tr>
<td align="left" valign="top"><italic>MAC_<sub>key</sub></italic> (<italic>m</italic>) [<xref ref-type="bibr" rid="b31-sensors-11-05020">31</xref>]</td>
<td align="left" valign="top">Message authentication code over message <italic>m</italic> with secret <italic>key</italic></td></tr>
<tr>
<td align="left" valign="top"><italic>S<sub>n</sub></italic></td>
<td align="left" valign="top">Sensor Node <italic>ID</italic></td></tr>
<tr>
<td align="left" valign="top"><italic>X<sub>g</sub></italic></td>
<td align="left" valign="top">Secret parameter generated by the user <italic>U<sub>k</sub></italic></td></tr>
<tr>
<td align="left" valign="top"><italic>h</italic>(.)</td>
<td align="left" valign="top">Cryptographic hash function</td></tr>
<tr>
<td align="left" valign="top">⊕</td>
<td align="left" valign="top">Bitwise XOR operation</td></tr>
<tr>
<td align="left" valign="top">||</td>
<td align="left" valign="top">Concatenation operation</td></tr></tbody></table></table-wrap>
<table-wrap id="t2-sensors-11-05020" position="float">
<label>Table 2.</label>
<caption>
<p>Additional notations.</p></caption>
<table frame="hsides" rules="groups">
<thead>
<tr>
<th align="left" valign="bottom"><bold>Notation</bold></th>
<th align="left" valign="bottom"><bold>Description</bold></th></tr></thead>
<tbody>
<tr>
<td align="left" valign="top"><italic>U</italic>, <italic>GW</italic> and <italic>Sn</italic></td>
<td align="left" valign="top">User, Gateway and Sensor, respectively entities</td></tr>
<tr>
<td align="left" valign="top"><italic>X1→X2</italic></td>
<td align="left" valign="top">X1 replace by X2</td></tr>
<tr>
<td align="left" valign="top"><italic>Phase - I</italic></td>
<td align="left" valign="top">Registration phase</td></tr>
<tr>
<td align="left" valign="top"><italic>Phase - II</italic></td>
<td align="left" valign="top">Login phase</td></tr>
<tr>
<td align="left" valign="top"><italic>Phase - III</italic></td>
<td align="left" valign="top">Authentication phase</td></tr></tbody></table></table-wrap>
<table-wrap id="t3-sensors-11-05020" position="float">
<label>Table 3.</label>
<caption>
<p>Local Sets for RUASN.</p></caption>
<table frame="hsides" rules="groups">
<tbody>
<tr>
<td align="center" valign="top"><bold><italic>1.</italic></bold> <underline><bold><italic>Entity U</italic></bold></underline></td></tr>
<tr>
<td align="center" valign="top"><italic>POSS(U) = {PW<sub>k</sub></italic>,<italic>{ID<sub>k</sub>}</italic>,<italic>r }</italic></td></tr>
<tr>
<td align="center" valign="top"><italic>BEL(U) = {#(PW<sub>k</sub>)</italic>, <italic>#(r)}</italic></td></tr>
<tr>
<td align="center" valign="top"><italic>BL(U) =</italic></td></tr>
<tr>
<td align="center" valign="top">(1.1) Phase – I</td></tr>
<tr>
<td align="center" valign="top">▪ <italic>Hash(h(.); XOR(r</italic>, <italic>PW<sub>k</sub>))→Pass</italic><break/>▪ <italic>Send(GW</italic>, <italic>{ID<sub>k</sub></italic>, <italic>Pass})</italic><break/>▪ <italic>Update({ID<sub>k</sub></italic>, <italic>PW<sub>k</sub></italic>, <italic>r})</italic><break/>▪ <italic>Receive (GW</italic>, <italic>{A<sub>k</sub></italic>, <italic>B<sub>k</sub></italic>, <italic>V<sub>k</sub></italic>, <italic>h(.),E<sub>k</sub>, D<sub>k</sub>})</italic></td></tr>
<tr>
<td align="center" valign="top">(1.2) Phase – II</td></tr>
<tr>
<td align="center" valign="top">▪ <italic>Hash(h(.);Concat(ID<sub>k</sub></italic>, <italic>Pass))→</italic>
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mi>V</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula><break/>▪ <italic>Check(</italic>
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mi>V</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula>, <italic>V<sub>k</sub>)</italic><break/>▪ <italic>Hash(h(.); A<sub>k</sub>)→H<sub>k</sub></italic><break/>▪ <italic>Generate-secret(X<sub>g</sub>)</italic><break/>▪ <italic>Concat(Tu</italic>, <italic>H<sub>k</sub>)→Tk<sub>Tu</sub></italic><break/>▪ <italic>Encrypt({Concat(Hash(h(.);ID<sub>k</sub></italic>,<italic>Sn</italic>, <italic>X<sub>g</sub>))}<sub>TkTu</sub>)→AID<sub>k</sub></italic><break/>▪ <italic>Send(Sn</italic>,<italic>{B<sub>k</sub></italic>, <italic>AID<sub>k</sub></italic>, <italic>Tu})→M1</italic><break/>▪ <italic>Update(ID<sub>k</sub></italic>, <italic>X<sub>g</sub></italic>, <italic>Sn</italic>, <italic>Tu)</italic></td></tr>
<tr>
<td align="center" valign="top">(1.3) Phase – III</td></tr>
<tr>
<td align="center" valign="top">▪ <italic>Receive(Sn</italic>, <italic>{L</italic>, <italic>Ts})→M4 [Here L=E<sub>SesK</sub>[X<sub>g</sub>||Ts]]</italic><break/>▪ <italic>Split({L</italic>, <italic>Ts})</italic><break/>▪ <italic>Check-freshness (Tu</italic> – <italic>Ts)</italic> ≥ Δ<italic>T</italic>, <italic>if yes</italic>, <italic>then aborts.</italic><break/>▪ <italic>Hash(h(.);Concat(Hash(h(.);ID<sub>k</sub></italic>,<italic>X<sub>g</sub></italic>,<italic>Sn</italic>,<italic>Ts</italic>, <italic>Tu)))→SesK</italic><break/>▪ <italic>Decrypt({L}<sub>SesK</sub></italic> <italic>and obtain (</italic>
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mi>X</mml:mi></mml:mrow>
<mml:mi>g</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula>, <italic>Ts*)</italic></td></tr>
<tr>
<td align="center" valign="top"><italic>Check(X<sub>g</sub></italic>, 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mi>X</mml:mi></mml:mrow>
<mml:mi>g</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula><italic>)</italic></td></tr>
<tr>
<td align="center" valign="top">▪ <italic>Check(Ts</italic>, <italic>Ts*)</italic></td></tr>
<tr>
<td align="center" valign="top"><bold><italic>2.</italic></bold> <underline><bold><italic>Entity GW</italic></bold></underline></td></tr>
<tr>
<td align="center" valign="top"><italic>POSS(GW) = {x</italic>, <italic>y</italic>, <italic>l</italic>, <italic>and SK<sub>gs</sub>}</italic></td></tr>
<tr>
<td align="center" valign="top"><italic>BEL(GW) = {#(s)</italic>, <italic>#(y)</italic>, <italic>#(l)</italic>,<italic>#(SK<sub>gs</sub>)}</italic></td></tr>
<tr>
<td align="center" valign="top"><italic>BL(GW) =</italic></td></tr>
<tr>
<td align="center" valign="top">(2.1) Phase – I</td></tr>
<tr>
<td align="center" valign="top">▪ <italic>Receive(U</italic>, <italic>{ID<sub>k</sub></italic>, <italic>Pass})</italic><break/>▪ <italic>Generate-secret number(l)</italic><break/>▪ <italic>Hash(h(.); XOR(ID<sub>k</sub></italic>, <italic>l))→A<sub>k</sub></italic><break/>▪ <italic>Encrypt({Concat(ID<sub>k</sub></italic>, <italic>l)}<sub>x</sub>)→B<sub>k</sub></italic><break/>▪ <italic>Hash(h(.);Concat(ID<sub>k</sub></italic>, <italic>Pass))→V<sub>k</sub></italic><break/>▪ <italic>Send(U</italic>, <italic>{A<sub>k</sub></italic>, <italic>B<sub>k</sub></italic>, <italic>V<sub>k</sub></italic>, <italic>h(.)})</italic><break/>▪ <italic>Update({A<sub>k</sub></italic>, <italic>B<sub>k</sub></italic>, <italic>V<sub>k</sub></italic>, <italic>h(.)</italic>, <italic>Pass})</italic><break/>▪ <italic>Forget({A<sub>k</sub></italic>,<italic>B<sub>k</sub></italic>, <italic>V<sub>k</sub></italic>, <italic>Pass})</italic></td></tr>
<tr>
<td align="center" valign="top">(2.2) Phase – II</td></tr>
<tr>
<td align="center" valign="top"><italic>NA</italic></td></tr>
<tr>
<td align="center" valign="top">(2.3) Phase – III</td></tr>
<tr>
<td align="center" valign="top">▪ <italic>Receive(Sn</italic>,<italic>{M2</italic>, <italic>Q})[Here M2 = B<sub>k</sub></italic>, <italic>AID<sub>k</sub></italic>, <italic>Tu</italic>, <italic>Ts</italic>, <italic>Sn]</italic><break/>▪ <italic>Split(M2</italic>, <italic>Q)</italic><break/>▪ <italic>Split(M2)</italic><break/>▪ <italic>Check-freshness (Tg</italic> – <italic>Ts)</italic> ≥ Δ<italic>T</italic>, <italic>if yes</italic>, <italic>then aborts.</italic><break/>▪ <italic>MAC({B<sub>k</sub></italic>, <italic>AID<sub>k</sub></italic>,<italic>Tu</italic>, <italic>Ts</italic>, <italic>Sn}<sub>SKgs</sub>)→Q′</italic><break/>▪ <italic>Check(Q</italic>, <italic>Q′)</italic><break/>▪ <italic>Decrypt({B<sub>k</sub>}<sub>x</sub>) and obtain [</italic>
<inline-formula>
<mml:math>
<mml:mrow>
<mml:mi>I</mml:mi>
<mml:msubsup>
<mml:mrow>
<mml:mi>D</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>'</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula>, <italic>l′]</italic><break/>▪ <italic>Hash(h(.);</italic> 
<inline-formula>
<mml:math>
<mml:mrow>
<mml:mi>I</mml:mi>
<mml:msubsup>
<mml:mrow>
<mml:mi>D</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>'</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula><italic>)</italic><break/>▪ <italic>Hash(h(.);XOR(</italic>
<inline-formula>
<mml:math>
<mml:mrow>
<mml:mi>I</mml:mi>
<mml:msubsup>
<mml:mrow>
<mml:mi>D</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>'</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula>, <italic>l′)) →</italic>
<inline-formula>
<mml:math>
<mml:mrow>
<mml:msubsup>
<mml:mrow>
<mml:mi>A</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>'</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula><break/>▪ <italic>Hash</italic>
<inline-formula>
<mml:math>
<mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>h</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:mo>.</mml:mo>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>;</mml:mo>
<mml:msubsup>
<mml:mrow>
<mml:mi>A</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>'</mml:mo></mml:msubsup>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>→</mml:mo>
<mml:msubsup>
<mml:mrow>
<mml:mi>H</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>'</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula><break/>▪ <italic>Concat</italic>
<inline-formula>
<mml:math>
<mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:mi>T</mml:mi>
<mml:mi>u</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi> </mml:mi>
<mml:msubsup>
<mml:mrow>
<mml:mi>H</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>'</mml:mo></mml:msubsup>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>→</mml:mo>
<mml:mi>T</mml:mi>
<mml:msub>
<mml:mrow>
<mml:mi>k</mml:mi></mml:mrow>
<mml:mrow>
<mml:mi>T</mml:mi>
<mml:mi>u</mml:mi></mml:mrow></mml:msub></mml:mrow></mml:math></inline-formula><break/>▪ <italic>Decrypt({AID<sub>k</sub>}<sub>TkTu</sub>) and obtain[h(</italic>
<inline-formula>
<mml:math>
<mml:mrow>
<mml:mi>I</mml:mi>
<mml:msubsup>
<mml:mrow>
<mml:mi>D</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula><italic>)</italic>, <italic>Sn*</italic>, <italic>X<sub>g</sub>]</italic><break/>▪ <italic>Check(h(</italic>
<inline-formula>
<mml:math>
<mml:mrow>
<mml:mi>I</mml:mi>
<mml:msubsup>
<mml:mrow>
<mml:mi>D</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>*</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula><italic>)</italic>, <italic>h(</italic>
<inline-formula>
<mml:math>
<mml:mrow>
<mml:mi>I</mml:mi>
<mml:msubsup>
<mml:mrow>
<mml:mi>D</mml:mi></mml:mrow>
<mml:mi>k</mml:mi>
<mml:mo>'</mml:mo></mml:msubsup></mml:mrow></mml:math></inline-formula><italic>))</italic><break/>▪ <italic>Check(Sn*</italic>, <italic>Sn)</italic><break/>▪ <italic>Encrypt({Concat(Hash(h(.);ID<sub>k</sub>)</italic>, <italic>X<sub>g</sub></italic>, <italic>Tg)}<sub>SKgs</sub>)→C</italic><break/>▪ <italic>Send(Sn</italic>, <italic>{C</italic>, <italic>Tg})→M3</italic><break/>▪ <italic>Update(C</italic>, <italic>Tg)</italic></td></tr>
<tr>
<td align="center" valign="top"><bold><italic>3.</italic></bold> <underline><bold><italic>Entity Sn</italic></bold></underline></td></tr>
<tr>
<td align="center" valign="top"><italic>POSS(Sn) = { SKgs</italic>, <italic>Sn }</italic></td></tr>
<tr>
<td align="center" valign="top"><italic>BEL(Sn) = {#(SKgs)</italic>, <italic>#(Sn)}</italic></td></tr>
<tr>
<td align="center" valign="top"><italic>BL(Sn) =</italic></td></tr>
<tr>
<td align="center" valign="top">(3.1) Phase – I</td></tr>
<tr>
<td align="center" valign="top"><italic>NA</italic></td></tr>
<tr>
<td align="center" valign="top">(3.2) Phase – II</td></tr>
<tr>
<td align="center" valign="top">▪ <italic>Receive(U</italic>, <italic>{M1}) [Here M1= (B<sub>k</sub></italic>, <italic>AID<sub>k</sub></italic>, <italic>Tu)]</italic><break/>▪ <italic>Split(M1)</italic><break/>▪ <italic>Check-freshness (Ts – Tu)</italic> ≥ Δ<italic>T</italic>, <italic>if yes</italic>, <italic>then aborts.</italic><break/>▪ <italic>MAC({Concat(B<sub>k</sub></italic>,<italic>AID<sub>k</sub></italic>,<italic>Tu</italic>,<italic>Ts</italic>,<italic>Sn)}<sub>SKgs</sub>)→Q</italic><break/>▪ <italic>Send(GW</italic>, <italic>{M2</italic>, <italic>Q}) [Here M2 = (B<sub>k</sub></italic>,<italic>AID<sub>k</sub></italic>, <italic>Tu</italic>, <italic>Ts</italic>, <italic>Sn)]</italic><break/>▪ <italic>Update(M2</italic>, <italic>Q)</italic></td></tr>
<tr>
<td align="center" valign="top">(3.3) Phase – III</td></tr>
<tr>
<td align="center" valign="top">▪ <italic>Receive(GW</italic>,<italic>{Tg</italic>, <italic>C})</italic><break/>▪ <italic>Split(Tg</italic>, <italic>C)</italic><break/>▪ <italic>Check-freshness (Ts –Tg)</italic> ≥ Δ<italic>T</italic>, <italic>if yes</italic>, <italic>then aborts.</italic><break/>▪ <italic>Decrypt({C}<sub>SKgs</sub>) and obtain [h(ID<sub>k</sub></italic>, <italic>X<sub>g</sub></italic>, <italic>Tg*)]</italic><break/>▪ <italic>Check(Tg*</italic>, <italic>Tg)</italic><break/>▪ <italic>Hash(h(.);Concat(Hash(.);ID<sub>k</sub></italic>, <italic>X<sub>g</sub></italic>, <italic>Sn</italic>, <italic>Ts</italic>, <italic>Tu))→Ses<sub>K</sub></italic><break/>▪ <italic>Encrypt({Concat(X<sub>g</sub></italic>, <italic>Ts)}<sub>SesK</sub>)→L</italic><break/>▪ <italic>Send(U</italic>, <italic>{L</italic>, <italic>Ts})→M4</italic><break/>▪ <italic>Update(L</italic>, <italic>Ts)</italic></td></tr></tbody></table>
<table-wrap-foot><fn id="tfn1-sensors-11-05020">
<p><italic>NA:</italic> Not Applicable.</p></fn></table-wrap-foot></table-wrap>
<table-wrap id="t4-sensors-11-05020" position="float">
<label>Table 4.</label>
<caption>
<p>A performance comparison of RUASN with the existing schemes.</p></caption>
<table frame="box" rules="cols">
<thead>
<tr>
<th align="center" valign="middle" rowspan="2"><bold>Schemes</bold></th>
<th colspan="2" align="center" valign="middle"><bold>Registration</bold>
<hr/></th>
<th colspan="3" align="center" valign="middle"><bold>Login and Authentication</bold>
<hr/></th></tr>
<tr>
<th align="center" valign="middle"><bold>User</bold></th>
<th align="center" valign="middle"><bold>Gateway</bold></th>
<th align="center" valign="middle"><bold>User</bold></th>
<th align="center" valign="middle"><bold>Gateway</bold></th>
<th align="center" valign="middle"><bold>Sensor node</bold></th></tr>
<tr>
<th colspan="6" align="center" valign="middle">
<hr/></th>
<th colspan="6" align="center" valign="middle">
<hr/></th></tr></thead>
<tbody>
<tr>
<td align="left" valign="top">Das [<xref ref-type="bibr" rid="b18-sensors-11-05020">18</xref>]</td>
<td align="center" valign="top"><italic>-</italic></td>
<td align="center" valign="top"><italic>3H</italic></td>
<td align="center" valign="top"><italic>4H</italic></td>
<td align="center" valign="top"><italic>4H</italic></td>
<td align="center" valign="top"><italic>1H</italic></td></tr>
<tr>
<td align="left" valign="top">Daojing <italic>et al</italic>. [<xref ref-type="bibr" rid="b21-sensors-11-05020">21</xref>]</td>
<td align="center" valign="top"><italic>1H</italic></td>
<td align="center" valign="top"><italic>5H</italic></td>
<td align="center" valign="top"><italic>5H</italic></td>
<td align="center" valign="top"><italic>5H</italic></td>
<td align="center" valign="top"><italic>1H</italic></td></tr>
<tr>
<td align="left" valign="top">Wong <italic>et al</italic>. [<xref ref-type="bibr" rid="b10-sensors-11-05020">10</xref>]</td>
<td align="center" valign="top"><italic>-</italic></td>
<td align="center" valign="top"><italic>3H</italic></td>
<td align="center" valign="top"><italic>-</italic></td>
<td align="center" valign="top"><italic>1H</italic></td>
<td align="center" valign="top"><italic>3H</italic></td></tr>
<tr>
<td align="left" valign="top">Vaidya <italic>et al</italic>. [<xref ref-type="bibr" rid="b14-sensors-11-05020">14</xref>]</td>
<td align="center" valign="top"><italic>2H</italic></td>
<td align="center" valign="top"><italic>2H</italic></td>
<td align="center" valign="top"><italic>3H</italic></td>
<td align="center" valign="top"><italic>3H</italic></td>
<td align="center" valign="top"><italic>3H</italic></td></tr>
<tr>
<td align="left" valign="top"><bold>Proposed RUASN</bold></td>
<td align="center" valign="top"><bold><italic>1H</italic></bold></td>
<td align="center" valign="top"><bold><italic>3H + 1S</italic></bold></td>
<td align="center" valign="top"><bold><italic>4H + 2S</italic></bold></td>
<td align="center" valign="top"><bold><italic>4H + 2S + 1MAC</italic></bold></td>
<td align="center" valign="top"><bold><italic>1H + 2S + 1MAC</italic></bold></td></tr></tbody></table></table-wrap>
<table-wrap id="t5-sensors-11-05020" position="float">
<label>Table 5.</label>
<caption>
<p>Functionality comparison of RUASN with existing schemes.</p></caption>
<table frame="box" rules="cols">
<thead>
<tr>
<th align="center" valign="middle"><bold>Security Features</bold></th>
<th align="center" valign="middle"><bold>Das [<xref ref-type="bibr" rid="b18-sensors-11-05020">18</xref>]</bold></th>
<th align="center" valign="middle"><bold>He</bold> <bold><italic>et al</italic>. [<xref ref-type="bibr" rid="b21-sensors-11-05020">21</xref>]</bold></th>
<th align="center" valign="middle"><bold>Wong</bold> <bold><italic>et al</italic>. [<xref ref-type="bibr" rid="b10-sensors-11-05020">10</xref>]</bold></th>
<th align="center" valign="middle"><bold>Vaidya</bold> <bold><italic>et al</italic>. [<xref ref-type="bibr" rid="b14-sensors-11-05020">14</xref>]</bold></th>
<th align="center" valign="middle"><bold>Proposed RUASN</bold></th></tr>
<tr>
<th colspan="6" align="center" valign="middle">
<hr/></th></tr></thead>
<tbody>
<tr>
<td align="left" valign="top">Provides mutual authentication</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">Yes</td>
<td align="center" valign="top"><bold>Yes</bold></td></tr>
<tr>
<td align="left" valign="top">Provide user privacy</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">Yes</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">Yes</td>
<td align="center" valign="top"><bold>Yes</bold></td></tr>
<tr>
<td align="left" valign="top">Confidentiality</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top"><bold>Yes</bold></td></tr>
<tr>
<td align="left" valign="top">Secure Session key agreement</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top"><bold>Yes</bold></td></tr>
<tr>
<td align="left" valign="top">Secure password update phase</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">Yes</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">Yes</td>
<td align="center" valign="top"><bold>Yes</bold></td></tr>
<tr>
<td align="left" valign="top">Replay attack</td>
<td align="center" valign="top">Yes</td>
<td align="center" valign="top">Yes</td>
<td align="center" valign="top">Yes</td>
<td align="center" valign="top">Yes</td>
<td align="center" valign="top"><bold>Yes</bold></td></tr>
<tr>
<td align="left" valign="top">No password tables stored inside the gateway</td>
<td align="center" valign="top">Yes</td>
<td align="center" valign="top">Yes</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top"><bold>Yes</bold></td></tr>
<tr>
<td align="left" valign="top">No verification table stored inside the gateway</td>
<td align="center" valign="top">Yes</td>
<td align="center" valign="top">Yes</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top"><bold>Yes</bold></td></tr>
<tr>
<td align="left" valign="top">Password is not be transmitted as plaintext</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">Yes</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">Yes</td>
<td align="center" valign="top"><bold>Yes</bold></td></tr>
<tr>
<td align="left" valign="top">Resist insider-attacks</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">Yes</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">Yes</td>
<td align="center" valign="top"><bold>Yes</bold></td></tr>
<tr>
<td align="left" valign="top">Password is not exposed to the gateway administrator</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">Yes</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top"><bold>Yes</bold></td></tr>
<tr>
<td align="left" valign="top">Secure against gateway secret key guessing attack</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top"><bold>Yes</bold></td></tr>
<tr>
<td align="left" valign="top">Secure against password guessing attack</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">Yes</td>
<td align="center" valign="top">No</td>
<td align="center" valign="top">Yes</td>
<td align="center" valign="top"><bold>Yes</bold></td></tr></tbody></table></table-wrap></sec></back></article>
