Abstract

The concept of two-factor multiserver authentication protocol was developed to avoid multiple number of registrations using multiple smart-cards and passwords. Recently, a variety of two-factor multiserver authentication protocols have been developed. It is observed that the existing RSA-based multiserver authentication protocols are not suitable in terms of computation complexities and security attacks. To provide lower complexities and security resilience against known attacks, this article proposes a two-factor (password and smart-card) user authentication protocol with the RSA cryptosystem for multiserver environments. The comprehensive security discussion proved that the known security attacks are eliminated in our protocol. Besides, our protocol supports session key agreement and mutual authentication between the application server and the user. We analyze the proof of correctness of the mutual authentication and freshness of session key using the BAN logic model. The experimental outcomes obtained through simulation of the Automated Validation of Internet Security Protocols and Applications (AVISPA) S/W show that our protocol is secured. We consider the computation, communication, and storage costs and the comparative explanations show that our protocol is flexible and efficient compared with protocols. In addition, our protocol offers security resilience against known attacks and provides lower computation complexities than existing protocols. Additionally, the protocol offers password change facility to the authorized user.

1. Introduction

Nowadays, network technologies and the online applications are rapidly growing; the Internet users are accessing online services to make their life more comfortable over Internet. When accessing a remote server, a session key should be negotiated between user and remote server, which would be used to encrypt the confidential messages. In this regard, two-factor authentication protocols using smart-card and password are widely used and designing a robust and efficient two-factor authentication protocol is a critical task. The concept of client-server communication over insecure networks has been introduced for single server environment, and many researchers have proposed numerous authentication protocols [1–3] using hash function [4–6], RSA cryptosystem [7–9], elliptic curve [10], chaotic map [11, 12], and bilinear pairing [13]. However, these protocols are unsuitable for multiserver communications. For this purpose, lots of authentication protocols [13–17] have been put forward for multiserver architecture. In multiserver communications, there are three entities such as a user, a registration center, and a number of application servers. In this environment, all the application servers and users registered themselves to the registration center. All of these application servers are responsible for providing required services to the users. An architecture of the multiserver communication is given in Figure 1.

Figure 1 

Multiserver framework used in our protocol.

User anonymity [18, 19] is one of the security issues in user authentication protocol, where user’s identity should be kept secret from the adversary. There are several application areas such as banking, medical system [7, 10], and wireless sensor network [20], where the authorized users want to keep their identity secret from an adversary; that is, the adversary is unable to extract or guess user’s original identity from the login and authentication messages. In addition to that, the mutual authentication is another important security aspect, where client and server both can verify each other to avoid man-in-the-middle attack. As the adversary can also act as server, so verifying at the server end is also important. Like mutual authentication, protection of low-entropy information such as identity and password from guessing attack is very imperative. Furthermore, the insider attack is also difficult to protect since a person who is managing the registration center may misuse users’ confidential information such as password. So, the protection of such kind of attack is also essential. As we know the public messages of any authentication protocol are transmitted via open channels, and thus an adversary may intercept, drop, modify, and reroute the captured messages. Thus, the adversary can try to impersonate either the user or the remote server. In this regard, mutual authentication [18, 19] between the participants is most important security aspect. Another objective of any client-server authentication protocol is to negotiate a session key between entities. Since both the participants negotiate their session key, whether the session keys computed by the both entities are equal or not should be checked. In order to perform this, a session key verification property [21] should be involved in the protocol.

1.1. Literature Reviews

In the literature, numerous multiserver authentication protocols are designed to achieve strong security as well as lower complexities. In 2009, Liao and wang [22] put forward a multiserver authentication protocol; however, Chen et al. [23] showed that the protocol in [22] suffers from forward secrecy problem. Further, Hsiang and Shih [24] demonstrated that the protocol in [22] cannot defy some common attacks [13], and then they enhanced it to remedy the identified weaknesses. Lee et al. [25] designed an enhanced and efficient multiserver authentication protocol after pointing out the security weakness of the protocol in [24]. Subsequently, Troung et al. [26] illustrated that the protocol in [24] cannot resist smart-card stolen and user impersonation attacks. To vanquish these loopholes, the authors put forward another multiserver authentication protocol and showed that it is secure against common attacks. Moreover, Sood et al. [15] observed different security weaknesses of the protocol in [24] and then designed a multiserver authentication protocol. In 2012, Li et al. [17] showed that the protocol in [15] cannot withstand smart-card stolen attack and subsequently put forward a new protocol. Currently, Pippal et al. [14] designed a secure smart-card based user authentication protocol and showed that their protocol is robust against known attacks. Unfortunately, He et al. [27] demonstrated that the protocol in [14] is not secure against impersonation attack, offline password guessing attack, insider attack, and server spoofing attack. Also, Yeh [16] demonstrated that the protocol in [14] is not secure against some common attacks. More recently, Hsieh and Leu [28] demonstrated that Liao and Hsiao’s protocol [29] could not give full security requirements and then devised an efficient protocol using bilinear pairing. In 2015, Amin and Biswas [13] showed that the protocol in [28] is insecure against offline password guessing attack, server masquerading attack, and user anonymity problem. Additionally, they described that the password change facility of this protocol is not user-friendly. To overcome these security vulnerabilities, Amin and Biswas [13] devised user authentication and session key agreement protocol using smart-card and bilinear pairing. In the same year, Giri et al. [8] proposed a robust authentication protocol using RSA and claimed that it is strongly protected against security vulnerabilities. But, Amin and Biswas [7] highlighted that the protocol in [8] is not secure against several security attacks. Further, they proposed a new protocol to overcome the security weaknesses. In 2016, Sutrala et al. [30] show that the protocol in [7] is not secure and also proposed an improved protocol. Similarly, the authors in [31] demonstrated security attacks of the protocol in [7] and proposed a new RSA-based authentication protocol.

1.2. Contributions

This article claims the following contributions.(i)We have pointed out that all the existing RSA-based multiserver protocols include high computation cost and are insecure against known attacks.(ii)The main contribution of this article is the design and analysis of a lightweight and robust authentication protocol for multiserver environments.(iii)The proposed protocol is analyzed using the AVISPA S/W and its results showed that our protocol is secure.(iv)We proved that our protocol is completely protected against known security threats. Further, it solves the problem of anonymity issue.(v)We show that the performance of our protocol is better in terms of computation and communication overheads.

1.3. Organization of the Article

Section 2 discusses our authentication protocol for multiserver architecture. The concrete security discussion of our protocol appears in Section 3. The authentication correctness of our protocol using BAN logic is shown in Section 4. The simulation results of our protocol using AVISPA S/W are discussed in Section 5. The comprehensive performance measurement of our protocol and comparative results with other protocols appear in Section 6. We have provided the conclusion with some remarks and future scope in Section 7.

2. Proposed Authentication Protocol

Based on RSA cryptosystem, this section introduces a two-factor multiserver authentication protocol using password and smart-card. Our authentication protocol includes initialization phase, registration phase for application server and user , login phase, verification phase, and password change phase. We present a list of symbols used throughout this article in the Notations.

2.1. Initialization Phase

This phase is executed by the to initialize the whole system. Accordingly, determines two large prime numbers and (each of them at least 1024 bits), computes , and further determines a generator . keeps as secrets and publishes as public value. further selects a cryptographic hash function : , where represents arbitrary binary string and is a fixed-length binary string.

2.2. Application Server Registration Phase

The main objective of is to provide remote services to on demand through insecure communication. In order to provide remote services, all must execute registration phase to the trusted . During registration, and perform the operations as given below.

Step 1. first selects his/her identity and submits it to through a secure channel.

Step 2. After receiving the registration request, chooses a public key such that and computes the corresponding private key , where . further computes confidential information .

Step 3. maintains a table that includes and keeps it securely. Finally, sends to securely.
We further depict the registration phase of application server of the proposed protocol in Figure 2.

Figure 2 

Application server registration phase of our protocol.

2.3. User Registration Phase

To register with , performs the tasks as explained below.

Step 1. determines his/her identity together with password and sends to over a secure channel, where .

Step 2. After receiving , computes , , , , and and then embeds into an new and fresh smart-card.

Step 3. After preparing the smart-card, sends it to over secure channel or in person.

Further we demonstrate the user registration phase of our protocol in Figure 3.

Figure 3 

User registration phase of our protocol.

2.4. Login Phase

At the time of enjoying remote services, takes initiation and executes this phase. The following operations are performed in this phase.

Step 1. inserts the smart-card and enters to the terminal on request. Then, the terminal computes , , , and and checks the condition whether matches with . If the condition holds, it implies that and .

Step 2. The terminal now produces a random number and calculates and and then sends to using an insecure channel.

Further we provide description of login phase of the proposed protocol in Figure 4.

Figure 4 

Login phase of our protocol.

2.5. Verification Phase

This phase achieves a session key agreement between and with the help of over insecure communication. All the operations performed by , , and are discussed now.

Step 1. After getting login message , first decrypts using its own secret key and then further computes , , and . Then checks whether matches with . If the condition holds, is verified by .

Step 2. extracts and the public key and then computes . Finally, sends , to via insecure channel.

Step 3. After receiving , computes , , and and then transmits to over insecure channel.

Step 4. After receiving , first decrypts using its private key and according to RSA cryptosystem, obtains . Then computes and and then checks whether matches with . If such condition is incorrect, terminates the connection or else authenticates .

Step 5. After verifying , computes the session key and further computes and . sends to through any insecure channel.

Step 6. After receiving , computes , , and and checks whether holds. If the condition holds, authenticates and session key generated by and is verified.

Further we provide the description of verification phase of our protocol in Figure 5.

Figure 5 

Verification phase of our protocol.

2.6. Password Change Phase

In password-based remote user authentication protocol, user’s password is one of the most sensitive information pieces and must be changed whenever required. Therefore, password change phase must be rendered to the registered user. This phase requires the following actions to change the password.

Step 1. inserts the smart-card and enters old to the terminal on request. Then, the terminal computes , , , and and checks whether matches with . If the condition is correct, it implies that and .

Step 2. After successfully verifying , the smart-card made request to the for a new password. Then enters a fresh password and then the smart-card computes , , , and and replaces with .

Further we explained the our password change phase in Figure 6.

Figure 6 

Password update phase of our protocol.

3. Discussion about the Security

This section measures security strength of our protocol by analyzing several security attacks. Generally, password-based authentication protocol suffers from different attacks. The authentication protocol must resist the known attacks and achieve mutual authentication, session key verification along with login, and password change phase efficiently. Here, we analyze that our protocol can defy all the relevant security attacks. In this regard, we define some valid assumptions [2, 10, 20] as follows.

Definition 1. An adversary has the capabilities for retrieving smart-card information using power consumption monitoring method [34, 35]. For instance, if gets the smart-card, he/she has the capability of finding the confidential data from it.

Definition 2. All messages produced by the protocol during execution are sent via insecure communication such as Internet. Therefore, intercepts, deletes, modifies, reroutes, and resends the transmitted message. It is worth noting that cannot intercept any information from the secure network [10].

Definition 3. knows execution of the protocol; that is, the protocol is public. Additionally, may behave like legitimate user or client.

Definition 4. We considered that the authorized user selects dictionary word as password and identity. It is noted that is unable to guess password and identity in polynomial time. If is known to , then it is hard to verify guessed password and identity using in polynomial time [20].

Definition 5. We considered that the random nonce and secret key size are significantly large (parameter with high entropy). Therefore, is unable to guess the information within polynomial time.

Definition 6. Let and only is known to . Then cannot find or from within polynomial time.

Definition 7. Assume length of identity or password is characters. According to [36], the probability of guessing the password is approximately equal to .

Theorem 8. Our multiserver authentication protocol resists smart-card stolen attack.

Proof. In smart-card stolen attack, generally extracts all the smart-card information (see Definition 1) and then tries to login to on behalf of . Suppose got smart-card of and extracted the information , where , , , , and . Note that cannot compute any confidential information of   or using . Further, and are protected by the hash function and symmetric key encryption algorithm, respectively. Therefore, the extraction of secure information by is infeasible and the protocol resists smart-card stolen attack.

Theorem 9. Our multiserver authentication protocol can defy the offline identity guessing attack.

Proof. As per Theorem 8, it is clear that has no advantage to found confidential information from the lost/stolen smart-card of any legal user. In this attack, we further elaborated whether can guess user’s identity using intercepted public messages. We supposed that intercepts the login messages , , and , where , , , , , , and . Note that cannot guess using without knowing the secret key of . Further, cannot guess from without . If wants to verify the guessed identity using and , the probability would be approximately and , respectively, where length of is 1024 bits. The value of is transmitted as ciphertext, and therefore, it is also infeasible to extract information without the private key of . Hence, the proposed authentication protocol can defy this type of offline identity guessing attack.

Theorem 10. Our multiserver authentication protocol can defy the offline password guessing attack.

Proof. Similar to Theorem 9, may attempt to guess of in offline mode. We described in Theorem 8 that cannot extract or guess ’s password from the smart-card information. In addition, the public messages are also independent of ’s . As a result, has no way to guess ’s password in offline mode.

Theorem 11. Our multiserver authentication protocol can defy the insider attack.

Proof. As mentioned in [7, 10], if the insider person of or gets ’s password by some means, she/he can attempt to login different accounts of . Thus, the protection against the insider attack is also an important issue in password-based authentication system. When the registration phase of our protocol is executed, delivers and to for issuing a smart-card, where . Since is protected by hash function, is unable to extract due to one-way behavior of the hash function.

Theorem 12. Our multiserver authentication protocol can defy the user impersonation attack.

Proof. To impersonate , has to generate a valid login message that must be authenticated by . During the login phase, generates , where and . Note that can generate the random number . However, it is very difficult to compute without knowing from the known information. Therefore, the protocol resists user impersonation attack.

Theorem 13. Our multiserver authentication protocol can defy the server impersonation attack.

Proof. Resembling Theorem 12, may attempt to forge the authentication message to . For that, has to compute another genuine message , which is to be authenticated by , where and . Now, generates the random number and tries to compute the valid . But, it is infeasible to compute without knowing . On the other hand, cannot compute correct without knowing . Hence, the adversary is unable to launch this attack.

Theorem 14. Our multiserver authentication protocol can defy the session key computation attack.

Proof. The protocol negotiates a session key between and , which will be used to encrypt the confidential information transmitted over public channel. Our authentication protocol computes the session key and its security depends on the hash function. Note that session key depends on the confidential information . We discussed earlier that is unable to compute these pieces of information. Hence, is unable to calculate the session key of our protocol.

Theorem 15. Our multiserver authentication protocol can defy the known session specific temporary information attack.

Proof. It is assumed that short-term information used in the protocol is known to . However, could not compute the session key in any session. We assume that knows and tries to compute . Then needs to compute . We described earlier that the computation of is not feasible by . Therefore, cannot launch this attack.

Theorem 16. Our multiserver authentication protocol can defy the stolen verifier attack.

Proof. At the time of application server registration, maintains a table called , which includes . Among these, is the most confidential parameter used in the proposed protocol. We now supposed that got by some means and attempted to break the security of the proposed protocol. Note that is not stored in plaintext form. It is stored as in the table, where is the secret key of . As a result, cannot compute without knowing .

4. Authentication Proof Using BAN Logic

This section addresses the freshness of the exchanged message and the proof of the mutual authentication based on Burrows-Abadi-Needham (BAN) logic [9, 13]. Being a known security model, BAN logic is required to demonstrate the authentication and secure key distribution protocols. Now, some backgrounds and notations used in BAN logic are given below.(i)Principals are agents involved in the protocol (usually people or programs).(ii)Keys are required to encrypt messages symmetrically.(iii)Public Keys are similar to Keys except they are used in pairs.(iv)Nonces are message parts that are not repeated.(v)Timestamps are similar to nonces where they are unlikely to be repeated.The BAN statements used in this paper that are required to analyze the security of our protocol are listed in the Notations.

The logical postulates of the BAN logic are listed in Table 1.

In order to prove the authentication protocol is valid, a list of the following things must be processed:(i)In language of formal logic, idealize our protocol.(ii)Find out assumptions about the initial state of our protocol.(iii)In order to deduce new predicates, use production and rules of the logic.(iv)Use logic to find out beliefs made by parties in our protocol.To show our protocol is secure, it must satisfy BAN logic based goals as discussed below.(i)Goal 1: (ii)Goal 2: (iii)Goal 3: (iv)Goal 4: Our protocol is transformed into the idealized form: :  : The assumptions on initial state of the protocol are made to analyze the proposed protocol as follows:       Idealized form of the protocol is demonstrated under BAN logic with assumptions. The main proofs are as follows: : . Based on seeing rule, we get  According to , , and message meaning rule, we know . According to , , and freshness-conjuncatenation rule and nonce verification rule, we know , where is the essential session key parameter of the proposed protocol. According to , , and the jurisdiction rule is applied, we know : . According to , , and the session key rule is used, we get :   (Goal 3).  with nonce verification rule according to is used and we get :   (Goal 4). : . Based on seeing rule it gets : . Based on , , and message meaning rules, it is known that : . Based on , , and nonce verification and freshness-conjuncatenation rules, we get : , where is essential session key parameter of our protocol. Based on , , and jurisdiction rule, we get : . Based on , , and the session key rule, we get :   (Goal 1).  and nonce verification rule are used according to and get :   (Goal 2).The discussion made above proves that our protocol correctly achieves the mutual authentication property.

5. Simulation Results of the Scheme Using AVISPA

We first briefly discuss the concept of the AVISPA and then present simulation results followed by HLPSL code of our protocol. According to literature review, the AVISPA is one of the widely used simulation tools for verifying security correction of the authentication protocol. Many earlier protocols [7, 10, 20] have been simulated using AVISPA tool.

5.1. Description of the AVISPA Tool

It is well known that AVISPA [37] is known as a tool for formal security verification. AVISPA supports HLPSL (High Level Scheme Specification Language). A general description and pictorial representation of the AVISPA tool can be found in [20, 37, 38]. AVISPA tool supports four different back-ends (OFMC, CL-AtSe, SATMC, and TA4SP) and abstraction based methods that are integrated through HLPSL. We refer to [38] for more details of OFMC, CL-AtSe, SATMC, and TA4SP. During the execution of the tool, HLPSL specification is interpreted into intermediate form (IF) by hlpsl2if translator where IF is lower-level language and directly read by AVISPA back-ends.

The HLPSL is a role-oriented language where every party plays a role during protocol execution. Every role is free from others, retrieving some initial information through parameters and communicating with other roles by the channels. Intruder is framed using the model [39] with a possibility for intruder as a legitimate role in protocol run. In addition, role system narrates principals, number of sessions, and roles. OUTPUT FORMAT (OF) using the four back-ends is produced, and (OF) after successful execution highlights the result whether our protocol is safe or not under which condition output is generated. Based on the HLPSL language, we have implemented the role specifications for the user, registration center, and application server in Algorithms 1, 2, and 3, respectively. The role specification for the session, goal, and environment in HLPSL is given in Algorithm 4.

5.2. Simulation Results

Algorithms 5 and 6 show the results on back-ends CL-AtSe and OFMC. Results for both the back-ends confirm that the protocol is SAFE which indicates that the protocol resists passive and active attacks. The proposed protocol achieves the following six properties and two authentication phases that are mentioned below.(1)Secrecy_of sec 1: is the confidential information and known to only.(2)Secrecy_of sec 2: the confidential information is known to only.(3)Secrecy_of sec 3: the session key is shared only between and .(4)Secrecy_of sec 4: the private key of is shared between .(5)Secrecy_of sec 5: the confidential information and pieces are only known to .(6)secrecy_of sec 6: the random numbers are known to only.(7)authentication_on alice_server_Ri: produces a random nonce , and if gets it secretly, then authenticates .(8)authentication_on server_alice_Rj: authenticates based on the random number .

6. Performance Evaluation and Discussion

This section discusses the performance of the proposed protocol and then compares it with the recently published protocols [14, 16, 32, 33] in terms of computation, smart-card storage, and communication costs. Note that the login and authentication phases are necessary for performing secure communication in each authentication cycle. Therefore, we have considered these phases in comparison. To evaluate the computational cost, this article used the following time complexities.(i): cost for one-way hash operation(ii): cost for symmetric key encryption/decryption operation(iii): cost for exponentiation operation(iv): cost for modular multiplication operation

The results obtained in [40] have executed various cryptographic operations using MIRACL C/C++ Library. It requires Windows 7 with 32-bit OS, Visual C++ 2008, 1024-bit cyclic group, 160-bit prime field , AES for symmetric encryption/decryption, and SHA-1 operation. On these above configurations, execution time (in ms) of such different operations is as follows: , , , and .

In Tables 2 and 3, we observed that computational cost and execution time of our protocol are lower than the protocols proposed in [14, 16] and nearly equal to the protocols in [32, 33]. Our protocol provides strong security protection against known attacks, such as mutual authentication, user anonymity, session key agreement, efficient login phase, and verification phase, and response time of the protocol is comparatively lesser than other protocols. For better understanding, we give execution cost (ms) comparison of the proposed protocol and the related ones [14, 16, 32, 33] in Figure 7.

Figure 7 

Execution time (ms) of different protocols.

In Table 4, smart-card storage cost, communication cost, and total number of message transmissions have been provided. The notation indicates that smart-card storage capacity is dependent on the total number of application servers. Therefore, the limitation of the protocols [14, 16, 32] is that the number of application servers is restricted owing to low capacity of smart-card. Note that smart-card storage cost does not increase with the number of application servers in the protocol [33] and our protocol. The proposed protocol requires less storage costs for the smart-card compared to the protocols proposed in [14, 16, 32, 33]. In our protocol, we provide session key verification property and to achieve it, the protocol takes extra single message exchange in comparison with the protocols [14, 16, 32, 33]. Note that the protocols [14, 16, 32, 33] do not provide the session key verification property. In Table 4, we also noticed that the total number of bits transmission of our protocol is lesser than related protocols.

7. Conclusion and Future Scope

This article presents a flexible and cost-effective RSA-based multiserver authentication protocol to perform secure mutual authentication over any insecure channel with user and application server. We have then proved informally that our protocol can defy different cryptographic attacks. Moreover, the security of the mutual authentication and the freshness of the session key have been established based on BAN logic model, and AVISPA simulation results claim that proposed protocol is SAFE in CL-AtSe and OFMC models. We have then shown that the performance of our protocol is more effective than the existing protocols in terms of complexities. Our protocol is not only robust, but also flexible since it has user-friendly password change phase.

In recent times, cloud computing is also applied to the environment of mobile communication. However, the computation and storage capabilities of mobile devices are very limited. Therefore an attempt can be made to design a provably secure and lightweight multiserver authentication protocol for mobile cloud computing environments.

Notations

Conflicts of Interest

The authors declare that there are no conflicts of interest regarding the publication of this paper.

Acknowledgments

The authors extend their appreciation to the Deanship of Scientific Research at King Saud University for funding this work through Research Group no. RG-288.