1 Introduction

The session initiation protocol (SIP) has gained much popularity as SIP can accomplish sessions including multimedia distribution, internet multimedia conferences and the internet telephone calls. Authentication is performed when a remote user wants to access SIP services enabling the verification of legality of both the remote user as well as the SIP server. The SIP authentication can be performed in a variety of ways for differing applications, like one time password authentication, public key cryptography and digital signatures, some other protocols for SIP authentication are IP SEC, SSL, SSH and Kerberos. Typically the use of authentication protocol depends on the sensitivity of different applications as well as the available resources [1, 2]. The password based authenticated key agreement requires the authenticity of both the user and SIP server before initiating the session. A number of password based authentication schemes are proposed for SIP [3–26]. In earlier such schemes, the SIP server maintained a database for password of each user. And in such cases, the server has to protect the database from internal and external adversaries. Such databases are vulnerable to stolen verifier attacks as well as burdening the server resources. In 2013, Zhang et al. [27] came up with a solution to this problem, in their solution they eliminated the need of server database, and claimed their protocol to be efficient and secure, but Tu et al. [28] proved their protocol to be vulnerable to user impersonation attack. Furthermore, Tu et al. [28] proposed an enhanced protocol to improve the security, but Farash [29] questioned the security of Tu et al.’s protocol and proved it to be vulnerable to server impersonation attack. Then Farash [29] proposed an improved protocol and claimed their proposed protocol to withstand the known attacks. However in this paper, we show that Farash’s protocol [29] is vulnerable to user impersonation attack, password guessing attack, session-specific temporary information leakage attack and lacks user anonymity. Furthermore, we proposed an improved protocol. The proposed protocol not only robust against all known attacks, but is also lightweight as compared to Farash’s protocol [29]. Rest of the paper is organized as: Section 2 describes the basics of Elliptic curve cryptography along with related computational hard problems. Section 3 reviews Farash’s scheme, and its cryptanalysis is discussed in Section 4. In Section 5, we propose our scheme. Security of the proposed scheme is analyzed in Section 6. We also performed automatic protocol verification using automated verification tool ProVerif in Section 7. A comparative performance analysis of the proposed scheme is discussed in Section 8. Finally, we give our conclusions in Section 9.

2 Preliminaries

This section describes some basics of elliptic curve cryptography(ECC) along with related hard problems to clasp the concepts used in this paper.

2.1 Elliptic curve cryptography

Miller [30] and Koblitz [31] were the first to present the use of elliptic curves in cryptography, which latterly proved to be more efficient as compared to conventional public key cryptography [32]. ECC provides same security for reduced parameters size. In elliptic curver based cryptography, the mathematical operations are carried out on an equation E q (i,j):y 2=x 3+i x+j mod q, where q is a large prime number such that size of q≥160 b i t s & \(i,j\in Z_{p}^{*}\). The integers i,j defines the curve, while (x,y) are the points which fulfills the statement, 4i 3+27j 2 mod q≠0. The point at infinity O is considered as identity element. Two common operations over E q (i,j) are point addition and scalar point multiplication, where scalar point multiplication is considered as repeated addition. Let R is a point over E q (i,j) and k is an integer then k R=R+R+R+.....R (k t i m e s). The domain parameters (q,i,j,R) belongs to the finite field. Below are the two common computational problems pertaining to ECC security:

  1. 1.

    Elliptic Curve Discrete Logarithm Problem (ECDLP) ECDLP can be stated as, given two points R and S over an elliptic curve E q (i,j), it is computationally hard to find an integer k such that R=k S in polynomial time.

  2. 2.

    Elliptic Curve Computational Diffie Hellman Problem (ECCDH) ECCDH can be stated as, given three points Q, a Q and b Q over an elliptic curve E q (i,j), it is computationally hard to find a b Q in polynomial time.

3 Review of Farash’s scheme

Here we give description of Farash’s session initiation protocol which involves four phases: setup, registration, login-authentication, and password change phases. As an aid, we make Table 1 for notations meaningful in this paper.

Table 1 The notations and their meaning
Full size table

3.1 Setup phase

The server S selects an elliptic curve E over the finite field F q and an additive group G of order p with P as generator. S selects three one-way hash functions h:{0,1}∗→{0,1}n,h 1:G×{0,1}∗×{0,1}∗→{0,1}n, and h 2:G×G×{0,1}∗×{0,1}∗→{0,1}n. S chooses a private key k, computes public key k P. Finally, S publishes the parameters {E(F q),P,p,G,h,h 1,h 2}, and keeps k as secret key.

3.2 Registration phase

In this phase, a person who wishes to be a legal user U of the system registers itself at the server S over a secure channel. The steps involved are as follows:

  1. 1.

    U freely chooses his u s e r n a m e u , password p w u , and a random number \(a_{u} \in Z_{p}^{*}\). U computes h(p w u ∥a u ) and sends the registration request {u s e r n a m e u ,h(p w u ∥a u )} to S.

  2. 2.

    For the received registration request {u s e r n a m e u ,h(p w u ∥a u )}, S computes r u =(h(p w u ∥a u )+h(u s e r n a m e u ∥k))P. S stores r u in a smart card SC and issues it to U.

  3. 3.

    U inserts the random number a u in the received SC.

3.3 Login-Authentication Phase

In this phase, U first initiates the login process and then interacts with S for mutual authentication. The steps involved are as follows:

  1. 1.

    U inserts his/her SC to a card reader and then inputs u s e r n a m e u and p w u .

  2. 2.

    SC chooses a random number \(b \in Z_{p}^{*}\) and computes b P, w u =b(r u −h(p w u ∥a u )P) and z u =h(u s e r n a m e u ∥b P∥w u ). SC sends the login request {u s e r n a m e u ,b P,z u } to S.

  3. 3.

    For the received login request {u s e r n a m e u ,b P,z u },S computes \(w_{u}^{*}=h(username_{u}\|k)\\bP\) and \(z_{u}^{*}=h(username_{u}\|bP\|w_{u}^{*})\). Then S compares \(z_{u}^{*}\) and z u . If \(z_{u}^{*}=z_{u}\), U is authenticated and S selects two random numbers c, \(d \in Z_{p}^{*}\),computes d P, v=d(b P), s e s s i o n k e y=h 1(v∥c∥u s e r n a m e u ) and \(Auth_{s}=h_{2}(v\|w_{u}^{*}\|c\|sessionkey)\). S sends challenge request {r e a l m,d P,c,A u t h s } to U.

  4. 4.

    For the received challenge request {r e a l m,d P,c,A u t h s }, U computes v=b(d P), s e s s i o n k e y=h 1(v∥c∥u s e r n a m e u ), \(Auth_{s}^{*}=h_{2}(v\|w_{u}\|c\|sessionkey)\). U compares \(Auth_{s}^{*}\) and A u t h s . If \(Auth_{s}^{*} = Auth_{s}\), S is authenticated. Then U computes A u t h u =h 2(v∥z u ||c+1∥s e s s i o n k e y) to send the challenge response {r e a l m,A u t h u }to S.

  5. 5.

    For the received challenge response {r e a l m,A u t h u }, S computes \(Auth_{u}^{*}= h_{2}(v\|zu^{*}\|c+1\|sessionkey)\). S compares \(Auth_{u}^{*}\) and A u t h u . If \(Auth_{u}^{*}=Auth_{u}\), U is re-authenticated with the assurance of no replay.

3.4 Password changing phase

In this phase, U can change his/her password with the help of the server S. For this, U first establishes a sessionkey with S by undergoing the login-authentication process. Then U executes the following steps to change his/her password:

  1. 1.

    U chooses a new password p w u n e w and two new random numbers a u n e w , \(e \in Z_{p}^{*}\). Then U computes m u = E n c s e s s i o n k e y (u s e r n a m e u ∥e∥h(p w u n e w ∥a u n e w )∥ h(u s e r n a m e u ∥e∥h(p w u n e w ∥a u n e w ))). Then U sends the password change request {m u ,e} to S.

  2. 2.

    For the received password change request {m u ,e}, S decrypts m u to obtain the embedded values u s e r n a m e u ,e,h(p w u n e w ∥a u n e w ), h(u s e r n a m e u ∥e∥h(p w u n e w ∥a u n e w )). S checks the validity of h(u s e r n a m e u ∥e∥h(p w u n e w ∥a u n e w )). If it passes the validity test, S computes r u n e w =(h(p w u n e w ∥a u n e w )+h(u s e r n a m e u ∥k))P and m s =E n c s e s s i o n k e y (r u n e w ∥h(u s e r n a m e u ∥e+1∥r u n e w )). S sends {m s } to U.

  3. 3.

    For the received {m s }, U decrypts m s as D e c s e s s i o n k e y (m s ) to obtain the embedded values r u n e w and h(u s e r n a m e u ∥e+1∥r u n e w ). U checks the validity of h(u s e r n a m e u ∥e+1∥r u n e w ).If it passes the validity test, U replaces r u n e w and a u n e w with r u and a u respectively.

4 Cryptanalysis of Farash’s scheme

In this section, we explain the vulnerabilities of Farash’s scheme. Our cryptanalysis is based on an adversary’s capability to intercept and transmit messages over the open channel, and extract values stored in a smart card [33, 34].

4.1 User impersonation attack

An adversary A can successfully impersonate a valid user to login the server in the following manner:

  1. 1.

    A obtains the u s e r n a m e u of U by intercepting the login request {u s e r n a m e u ,b P,z u } of U. A uses username u to achieve the secret parameter h(u s e r n a m e u ||k)P of U. For this A selects a simple value t A , computes its hash output h(t A ) and sends u s e r n a m e u ,h(t A ) to S. In response, A obtains a smart card containing r u A =(h(t A )+h(u s e r n a m e u ||k))P. A extracts r u A from his/her smart card and computes r u A −h(t A )P=h(u s e r n a m e u ||k)P.

  2. 2.

    Then A proceeds to impersonate U. A chooses a random number \(b_{A} \in Z_{p}^{*}\), computes b A P, w u A =b A h(u s e r n a m e u ||k)P and z u A =h(u s e r n a m e u ||b A P||w u A ). SC sends the login request {u s e r n a m e u ,b A P,z u A } to S.

  3. 3.

    For the received login request, S computes \(w_{uA}^{*} = h(username_{u}||k)b_{A}P\) and \(z_{uA}^{*}=h(username_{u}||b_{A}P||w_{uA}^{*})\). S compares \(z_{uA}^{*}\) and z u A . It is clear that \(w_{uA}^{*} = w_{uA}\), therefore \(z_{uA}^{*} = z_{uA}\) and hence S believes to be connected with the valid user U. Then S selects two random numbers c, \(d \in Z_{p}^{*}\), and computes d P, v A =d(b A P), s e s s i o n k e y A =h 1(v A ||c||u s e r n a m e u ) and \(Auth_{A}=h_{2}(v_{A}||w_{uA}^{*}||c||sessionkey_{A})\). S sends challenge request {r e a l m,d P,c,A u t h s A }.

  4. 4.

    A intercepts and blocks the challenge request r e a l m,d P,c,A u t h s A . A computes v A =b A (d P) and s e s s i o n k e y A =h 1(v A ∥c∥u s e r n a m e u ). A also computes A u t h A =h2(v A ∥z u A ∥c+1∥s e s s i o n k e y A ) and sends the challenge response {r e a l m,A u t h A } to S.

  5. 5.

    For the received challenge response {r e a l m,A u t h A }, S computes \(Auth_{A}^{*}= h2(v_{A}\|z_{uA}^{*} \|c+1\|sessionkey_{A})\). S compares \(Auth_{A}^{*}\) and A u t h A . It is clear that \(z_{uA}^{*} = z_{uA}\). Now both A and S compute the same value of v A , therefore \(Auth_{A}^{*} = Auth_{A}\). Therefore, S is assured that the connected entity is the valid user U and believes s e s s i o n k e y A is shared with U.

In this way, A impersonates a legal user U to login S and also establishes s e s s i o n k e y A with the server S.

4.2 Lacks user anonymity

User U sends the login request {u s e r n a m e u ,b P,z u } which contains U’s identity u s e r n a m e u in plaintext. Thus, an adversary A can easily pick u s e r n a m e u from the network and can misuse it. Presence of plaintext identity of a user in login request reveals user related information like login-frequency. Thus, A can have an idea of the purpose behind login. As a result, A can harm a legal user. But, Farash’s scheme overlooks these possibilities as it does not provide user anonymity.

4.3 Password guessing attack

If A finds the lost smart card of U then he can extract the values {r u ,a u } from it. Further, he can proceed to guess U’s password. A guesses p w p as U’s possible password and computes h(p w p ||a u ). A obtains u s e r n a m e u of U by intercepting the login request {u s e r n a m e u ,b P,z u} from the network. A chooses a random number \(b_{A} \in Z_{p}^{*}\), computes b A P, w u A =b A (r u −h(p w p ||a u )P) and z u A =h(u s e r n a m e u ||b A P||w u A ). A sends the login request u s e r n a m e u ,b A P,z u A to S. If A receives challenge response from S, then the guessed password p w p is correct otherwise A tries with some other guess.

4.4 Session-specific temporary information attack

According to Canetti and Krawczyk [35], this attack targets to compute the established session key of a particular session in case the random numbers of this session are leaked. In Farash’s scheme, suppose that the random number d is leaked. Then, an adversary A can take b P from an intercepted login request {u s e r n a m e u ,b P,z u } of U. Further, A can compute v=d(b P) and hence he can compute the session key s e s s i o n k e y=h 1(v||c||u s e r n a m e u ). In this way, sessionkey is vulnerable under the leakage of session-specific temporary information.

5 Proposed scheme

The proposed scheme consists of four phases: setup, registration, login-authentication, and password change phases. As an aid, we make Fig. 1 of the proposed scheme. The reason for the aforementioned vulnerabilities of Farash’s scheme is transmission of user’s plaintext identity u s e r n a m e u during login request and the design of user-specific value as h(p w u ||a u ). As a solution, we have hidden the identity u s e r n a m e u of U in such a way that only the valid server can obtain the real identity of the user. Besides, we have modified the design of user-specific value h(p w u ∥a u ) to h(u s e r n a m e u ∥p w u ∥a u ).

Fig. 1
figure 1

The Proposed Scheme

Full size image

5.1 Setup phase

The server S selects an elliptic curve E over the finite field F q and an additive group G of order p with P as generator. S selects a one-way hash functions h(.). S chooses a private key k, computes public key k P. Finally, S publishes the parameters {E(F q),P,p,G,h(.)}, and keeps k as secret key.

5.2 Registration phase

In this phase, a person who wishes to be a legal user U of the system registers itself at the server S over a secure channel. The steps involved are as follows:

  1. 1.

    U freely chooses his u s e r n a m e u , password p w u , and a random number \(a_{u} \in Z_{p}^{*}\). U computes h(u s e r n a m e u ||p w u ||a u ) and sends the registration request {u s e r n a m e u ,h(u s e r n a m e u ∥p w u ∥a u )} to S.

  2. 2.

    For the received registration request {u s e r n a m e u ,h(u s e r n a m e u ∥p w u ∥a u )}, S computes r u =(h(u s e r n a m e u ∥p w u ∥a u )+h(u s e r n a m e u ∥k))P. S stores r u in a smart card and issues S C={r u ,k P,h(.)} to U.

  3. 3.

    U inserts the random number a u in received SC, thus SC contains {r u ,k P,a u ,h(.)}.

5.3 Login-authentication phase

In this phase, U first initiates the login process and then interacts with S for mutual authentication. The steps involved are as follows:

  1. 1.

    U inserts his/her SC to a card reader and then inputs u s e r n a m e u and p w u .

  2. 2.

    SC chooses a random number \(b \in Z_{p}^{*}\), computes b P, v=b(k P) and w u =b(r u −h(u s e r n a m e u ||p w u ||a u )P). SC also computes f u =u s e r n a m e u ⊕v x and z u =h(u s e r n a m e u ∥b P∥v y ∥w u ) where v x and v y are x th and y th components of v respectively. SC sends the login request {f u ,b P,z u } to S.

  3. 3.

    For the received login request {f u ,b P,z u }, S computes v=k(b P) to retrieve u s e r n a m e u =f u ⊕v x . Then S computes \(w_{u}^{*}=h(username_{u}\|k)bP\) and \(z_{u}^{*}=h(username_{u}\|bP\|v_{y}\|w_{u}^{*})\). S compares \(z_{u}^{*}\) and z u . If \(z_{u}^{*} = z_{u}\), U is authenticated and S selects a random number \(c \in Z_{p}^{*}\), S computes \(sessionkey=h(w_{u}^{*}\|bP\|kP\|v\|c\|username_{u})\) and A u t h s =h(c||s e s s i o n k e y). S sends challenge request {r e a l m,c,A u t h s }to U.

  4. 4.

    For the received challenge request {r e a l m,c,A u t h s }, U computes s e s s i o n k e y=h(w u ∥b P∥k P∥v∥c∥u s e r n a m e u ), \(Auth_{s}^{*}=h(c\|sessionkey)\). U compares \(Auth_{s}^{*}\) and A u t h s . If \(Auth_{s}^{*} = Auth_{s}\), S is authenticated and U computes A u t h u =h(u s e r n a m e u ∥c+1∥s e s s i o n k e y) to send the challenge response {r e a l m,A u t h u } to S.

  5. 5.

    For the received challenge response message {r e a l m,A u t h u }, S computes \(Auth_{u}^{*}= h(username_{u}\|c+1\|sessionkey)\). S compares \(Auth_{u}^{*}\) and A u t h u . If \(Auth_{u}^{*} = Auth_{u}\), U is re-authenticated with the assurance of no replay.

5.4 Password changing phase

In this phase, U can change his/her password with the help of the server S. For this, U first establishes a sessionkey with S by undergoing the login-authentication process. Then U executes the following steps to change his/her password:

  1. 1.

    U chooses a new password p w u n e w and two new random numbers a u n e w , \(e \in Z_{p}^{*}\). Then U computes m u =E n c s e s s i o n k e y (u s e r n a m e u ∥e∥h(u s e r n a m e u ∥ p w u n e w ∥a u n e w )∥h(u s e r n a m e u ∥e∥h(u s e r n a m e u ∥p w u n e w ∥a u n e w ))) . Further U sends the password change request {m u ,e} to S.

  2. 2.

    For the received request {m u ,e}, S decrypts m u to obtain the embedded values. Then S checks the validity of h(u s e r n a m e u ∥e∥h(u s e r n a m e u ∥p w u n e w ∥a u n e w )). If it passes the validity test, S computes r u n e w =(h(u s e r n a m e u ∥p w u n e w ∥a u n e w )+h(u s e r n a m e u ∥k))P and m s =E n c s e s s i o n k e y (r u n e w ∥h(u s e r n a m e u ∥e+1∥r u n e w )). S sends {m s } to U.

  3. 3.

    For the received m s , U decrypts m s as D e c s e s s i o n k e y (m s ) to obtain the embedded values r u n e w and h(u s e r n a m e u ∥e+1∥r u n e w ). U checks the validity of h(u s e r n a m e u ∥e+1∥r u n e w). If it passes the validity test, U replaces r u n e w and a u n e w with r u and a u respectively.

6 Security analysis

We have performed formal as well as informal security analysis of our proposed scheme in following subsections.

6.1 Provable security model and proof

In this subsection, we prove that our scheme is secure with a formal security model based on [36, 37].

6.1.1 Security model

To make the discussion simple, we suppose that only two participants are in our protocol \(\mathcal {P}\): a user U and a server S. In the executing process, both U and S have many instances. Each instance is with a number k and it is an oracle. One instance is an execution of \(\mathcal {P}\). We define U i or S j as the instance for U or S with its own number i and j, respectively, or I k with differences eliminated. In this proof, three possible states can be the result of an oracle: accept, reject or ⊥. When the oracle receives a correct message, it reaches the accept state. Otherwise it reaches the reject state. If no decision has been reached or at last no result has been returned, the state ⊥ appears.

Before the instances start, U owns the identity u s e r n a m e u , a password p w u , the generator point P and a smart card containing r u , k P and a u . S has the private key k and the public key k P. The number of passwords is finite. And the passwords are in a special dictionary \(\mathcal {D}\) with total number \(|\mathcal {D}|\). \(\mathcal {P}\) can be executed many times by each instance. In this proof we consider the server S as secure.

According to the adversary’s model, the attacker A completely controls the public channel, and he aims to break privacy of the communication or the session keys. A can make some queries on oracles and get answers. We list the queries below:

  • h(s t r): This is the hash oracle. We suppose that the result is r. A record (s t r,r) is formed after that query. How to deal with the record is in the proof process.

  • S e n d(U i/S j,m/I N I T): This query models A’s active actions in communication, and will output the message that the instance would generate once receiving message m. If the second parameter is INIT, the result is the first message (f u ,b P,z u ) in the step 2 of Login-Authentication phase. The query is finished like the steps in the scheme.

  • E x e c u t e(U i,S j): It models passive attacks in the channel. A can obtain messages between U i and S j in normal executions. The query outputs the transcripts in execution.

  • R e v e a l(I k): This query denotes known-key attacks. After I k computes a session key, A can obtain it by this query.

  • C o r r u p t(s m a r t c a r d): A gets all data in U’s smart card after this query. It is for the guessing attack.

  • T e s t(I k): This query is corresponding for gaining the session key. After multiple queries, A should select a session to challenge. If no session key is generated for the instance I k, return ⊥. Otherwise, a coin ω will be flipped. If ω=1, the real session key is returned; if ω=0, a random string as long as the session key is returned. This query can be only asked on the fresh instance once. The notion fresh will be introduced below.

Here we give some definitions to show the security of the scheme:

  • P a r t n e r i n g: Each instance U i or S j has a partner identity \(pi{d_{U}^{i}}\) or \(pi{d_{S}^{j}}\), a session key \(s{k_{U}^{i}}\) or \(s{k_{S}^{j}}\) and a session identity \(si{d_{U}^{i}}\) or \(si{d_{S}^{j}}\) once it is accepted and forms a session key. U i and S j are partners if and only if \(pi{d_{U}^{i}}=S^{j}\), \(pi{d_{S}^{j}}=U^{i}\), \(si{d_{U}^{i}}=si{d_{S}^{j}}\) and \(s{k_{U}^{i}}=s{k_{S}^{j}}\).

  • fresh: The instance I k is thought to be fresh while R e v e a l(I k) or \(Reveal(pi{d_{I}^{k}})\) does not happen:

  • A K E−s e c u r i t y: The advantage of the adversary A breaking \(\mathcal {P}\) is the probability which A correctly guesses the coin ω produced in T e s t(I k) with I k accepted and fresh. If A outputs ω ′, the advantage is defined as

    $$Adv_{\mathcal{P}}^{AKE}(A)=|2Pr[\omega=\omega^{\prime}]-1|$$

    Our scheme is A K E−s e c u r e if \(Adv_{\mathcal {P}}^{AKE}(A)\) is negligibly greater than \(\frac {O(q_{s})}{|\mathcal {D}|}\), depending on security parameter l s . Here q s is the query times of S e n d.

Moreover, we list some computation assumptions.

  • Elliptic curve computational Diffie-Hellman (ECCDH) problem assumption: Given α P,β P∈G and α,β are positive integers, A can calculate α β P in polynomial time t. We define the probability A can solve the problem in t as \(Adv^{ECCDH}_{A}(t)\) and now \(Adv^{ECCDH}_{A}(t)\leq \epsilon \) where 𝜖 is a negligibly positive number.

6.1.2 Security proof

Theorem 1

The user employs password from dictionary \(\mathcal {D}\) with size \(|\mathcal {D}|\) . l s denotes the security length, which is for hash values. \(\mathcal {P}\) is our scheme. For an attacker A running with time t at most makes q s Send queries, q e Execute queries and q h hash oracle queries, we have

$$\begin{array}{@{}rcl@{}} Adv_{\mathcal{P}}^{AKE}(A)&\leq & \frac{(q_{s}+q_{e})^{2}}{p-1}+\frac{{q_{h}^{2}}}{2^{l_{s}}}+\frac{3q_{s}+2q_{h}}{2^{l_{s}-1}} \\ && + \frac{2q_{s}}{|\mathcal{D}|} + 4q_{h}Adv_{A}^{ECCDH}(t+(5q_{e}+3q_{s})t_{epm}) \end{array} $$

where t epm is the computation time of one scalar multiplication in G.

Proof

We define a series of games from Game G 0 to G 4. S u c c i is event that A guesses ω for G i successfully in T e s t. According to premises of our model, the attacker need not guess or compute the user’s identity due to only one user. The games are listed as follows:

  • Game G 0: This is the real scheme with the random oracle model. We see that \(Adv_{\mathcal {P}}^{AKE}(A)=2Pr[Succ_{0}]-1\). We choose a random bit ω ′ if the game aborts, stops without getting answer from A or A has not completed the games because he uses more queries or more time than predetermined upper bounds.

  • Game G 1: We simulate all oracles for queries. Also, three lists are used to store the record (s t r,r) formed after query mentioned in the security model. L h stores the answers to hash oracles. While the h oracle is queried by A, the record is in L A . And \(L_{\mathcal {P}}\) is for transcripts between U and S. We can not distinguish G 0 and G 1 via the simulation, so P r[S u c c 1]=P r[S u c c 0].

  • Game G 2: Some collisions should be avoided on the transcripts. b and c may be the same points in different transcripts. Also, hash values may collide. Note that b,c∈[1,p−1] and the lengths of hash values are l s . G 2 and G 1 are indistinguishable unless the above collisions appear. According to birthday paradox, we can see that

    $$|Pr[Succ_{2}]-Pr[Succ_{1}]|\leq \frac{(q_{s}+q_{e})^{2}}{2(p-1)}+\frac{{q_{h}^{2}}}{2^{l_{s}+1}}$$

  • Game G 3: In this game, we abort the game if A has luckily calculated correct messages without corresponding hash oracles. We divide the game into three cases according to three messages.

    1. 1.

      To forge S e n d(S j,(f u ,b P,z u )) query, A must make (u s e r n a m e u ||b P||v y ||w u ,z u ) hash query. Or we can say that (u s e r n a m e u ||b P||v y ||w u ,z u )∈L A should be true. If we have not found it as a role of server, the probability is up to \(\frac {q_{s}}{2^{l_{s}}}\). Note that S does not know p w u , so the record (u s e r n a m e u ||p w u ||a u ,∗) can not be checked. The probability is \(\frac {q_{h}}{2^{l_{s}}}\).

    2. 2.

      To forge S e n d(U i,(r e a l m,c,A u t h s )), A must make (w u ||b P||k P||∗||c||u s e r n a m e u ,∗) and (c||∗,A u t h s ). The probabilities are upper bounded by \(\frac {q_{h}}{2^{l_{s}}}\) and \(\frac {q_{s}}{2^{l_{s}}}\) respectively for the matter that the two records do not exist in L A .

    3. 3.

      To forge S e n d(S j,(r e a l m,A u t h u )), A must make (u s e r n a m e u ||c+1||∗,A u t h u ) and it is bounded by \(\frac {q_{s}}{2^{l_{s}}}\) for the matter that the record does not exist in L A .

    So the two games G 3 and G 2 are indistinguishable unless the messages are forged without hash queries. So we have

    $$|Pr[Succ_{3}]-Pr[Succ_{2}]|\leq \frac{3q_{s}+2q_{h}}{2^{l_{s}}} $$

  • Game G 4: In this game, ECCDH problem is brought in. A can use random oracles normally. If A can successfully gain the session key sessionkey and win the game, we think that we use A to solve the ECCDH problem. If A can compute the session key, he must ask a (w u ||b P||k P||v||c||u s e r n a m e u ,s e s s i o n k e y) query. If the above record correctly exists in the list L A , A breaks the ECCDH problem.

    We call this event G u e s s i n g. It is clear to see that

    $$|Pr[Succ_{4}]-Pr[Succ_{3}]|=Pr[Guessing] $$

    We divide G u e s s i n g into two cases: online guessing attack and off-line guessing attack.

    • Case 1: Suppose A uses C o r r u p t(s m a r t c a r d) to get the data in U’s smart card before online guessing. Since there are q s S e n d queries, the probability for this case is \(\frac {q_{s}}{|\mathcal {D}|}\).

    • Case 2: It is for off-line guessing attack. First A uses C o r r u p t(s m a r t c a r d), then the execution process are done by A. The record (w u ||b P||k P||v||c||u s e r n a m e u ,s e s s i o n k e y) is in L A with the probability \(\frac {1}{q_{h}}\). There are two ways for the aim. One is A asks E x e c u t e query, and the other is A asks S e n d queries in order like an E x e c u t e query. The probabilities for them are \(q_{h}Adv_{A}^{ECCDH}(t+5q_{e}t_{epm})\) and \(q_{h}Adv_{A}^{ECCDH}(t+3q_{s}t_{epm})\) respectively.

    From the above analysis, we can see G 4 and G 3 are indistinguishable unless G u e s s i n g happens. It seems that

    $$\begin{array}{@{}rcl@{}} |Pr[Succ_{4}]-Pr[Succ_{3}]|&\leq& \frac{q_{s}}{|\mathcal{D}|}+q_{h}Adv_{A}^{ECCDH}\\ &&\times(t+5q_{e}t_{epm})\\ &&+q_{h}Adv_{A}^{ECCDH}(t\,+\,3q_{s}t_{epm}) \\ &\leq& \frac{q_{s}}{|\mathcal{D}|}+ 2q_{h}Adv_{A}^{ECCDH}\\ &&\times(t+(5q_{e}+3q_{s})t_{epm}) \end{array} $$

Until now, A has no advantage in guessing ω and \(Pr[Succ_{4}]=\frac {1}{2}\). So the expression in Theorem 1 can be calculated. □

6.2 Further security discussion

6.2.1 Provides user anonymity and user un-traceability

In our scheme, user’s smart card stores r u ,k P,a u ,h(.) which does not contain the plaintext identity of the user. The value r u =(h(u s e r n a m e u ∥p w u ∥a u )+h(u s e r n a m e u ∥k))P. An adversary A cannot obtain U’s identity u s e r n a m e u from r u due to both ECDLP and the one-way property of hash function. The login request f u ,b P,z u also does not provide u s e r n a m e u of U directly. A cannot recover the random number b of U using bP due to ECDLP, therefore, A cannot compute v x to gain u s e r n a m e u from f u . Further, A cannot recover u s e r n a m e u from z u =h(u s e r n a m e u ∥b P∥v y ∥w u ) due to the one-way property of hash function. Any two login requests of U are totally different from each other as every time fresh values are computed using freshly chosen random numbers. As a result, A cannot trace a user by watching its login requests on the network. Hence, our scheme provides user anonymity and user un-traceability.

6.2.2 Resists user impersonation attack

For impersonating a legal user U, the knowledge of U’s identity u s e r n a m e u and the related secret value h(u s e r n a m e u ∥k) is essential. But the proposed scheme provides security against identity revelation as described in Section 6.2.1. A cannot obtain the secret parameter h(u s e r n a m e u ∥k)P of U by proceeding as in Farash’s scheme because there is no way for A to gain u s e r n a m e u of U. A can extract a u from stolen smart card of u but it is not possible to guess two values u s e r n a m e u and p w u simultaneously in real time polynomial. Thus, A cannot retrieve h(u s e r n a m e u ∥k)P from r u . A can select a new random number \(b_{A}\in Z_{p}^{*}\) and can compute v A =b(k P). However, computation of f u =u s e r n a m e u ⊕v x and z u A =h(u s e r n a m e u ∥b A P∥v y ∥b A h(u s e r n a m e u ∥k)P) is not feasible without the correct u s e r n a m e u and h(u s e r n a m e u ∥k). Since A is not capable of computing a workable login request to cheat S, user impersonation is not possible in the proposed scheme.

6.2.3 Resists password guessing attack

A can steal U’s smart card and can extract the values r u , k P and a u from it. A can guess p w p as the possible password of U and can use a u , he cannot verify the correctness of his guess using r u in the absence of correct u s e r n a m e u and secret value h(u s e r n a m e u ∥k). The identity u s e r n a m e u of U is always embedded in other values transmitted over open network such that no one except the valid server can obtain it. A is not capable of obtaining neither u s e r n a m e u nor h(u s e r n a m e u ∥k) of U as discussed in Sections 6.2.1 and 6.2.2. In the lack of correct u s e r n a m e u , A has no way to verify the accuracy of the guessed p w p by sending a trial login request to S and waiting for its response. As a result, password guessing is not feasible in our scheme as in Farash’s scheme. Thus, the proposed scheme is safe against password guessing attack.

6.2.4 Resists replay attack

An adversary A can replay the login request f u ,b P,z u of U to S. After receiving the challenge response from S, A needs to reply with correct A u t h u which requires the knowledge of u s e r n a m e u ,h(u s e r n a m e u ∥k) and random number b. It is not feasible to recover u s e r n a m e u and h(u s e r n a m e u ∥k) as discussed in Sections 6.2.1 and 6.2.2, so the value h(u s e r n a m e u ||k)b P cannot be computed by A. Random number b cannot be gained from b P due to ECDLP. Without having b, computation of b(k P) is not possible. Thus, A cannot compute the correct sessionkey corresponding to the session the login request of which is replayed. Due to lack of u s e r n a m e u ,h(u s e r n a m e u ∥k)b P and sessionkey, A cannot compute the correct response, therefore, he cannot clear the final authentication test in last step of the login-authentication phase. Thus, the replay of a login request is not useful for A and replay attack is not applicable in the proposed scheme.

6.2.5 Provides mutual authentication

When U sends the login request f u ,b P,z u , S authenticates U by itself computing \(z_{u}^{*}=h(username_{u}\|bP\|v_{y}\|w_{u}^{*})\) and comparing it with the received z u . For this, S itself computes v=k(b P) using its private key k, retrieves u s e r n a m e u =f u ⊕v x and again uses k to compute \(w_{u}^{*}=h(username_{u}\|k)bP\). The equality of \(z_{u}^{*}\) and z u validates U. When S sends the challenge request r e a l m,c,A u t h s , U authenticates S by computing \(Auth_{s}^{*}=h(c||sessionkey)\) and comparing it with the received A u t h s . For this, U computes s e s s i o n k e y=h(w u∗∥b P∥k P∥v∥c∥u s e r n a m e u) using his/her u s e r n a m e u and already computed v=b(k P). The equality of \(Auth_{s}^{*}\) and A u t h s validates S. Finally, S receives r e a l m,A u t h u and computes \(Auth_{u}^{*}= h(username_{u}\|c+1\|sessionkey)\) using already computed sessionkey, \(w_{u}^{*}\) and retrieved u s e r n a m e u . Then S compares \(Auth_{u}^{*}\) with the received A u t h u , the equality of these two values ensures that the legitimate user U is connected and the login request was not replayed by an adversary. In this way, the proposed scheme provides mutual authentication.

6.2.6 Resists man-in-the-middle attack

In this attack, an adversary A sits in the middle of the conversation of a user and the server, intercepts and blocks the messages transmitted between these two legal entities, itself connects with them and makes them believe that they are connected with each other. When U transmits the login request f u ,b P,z u to S, A can intercept and block this request. But A cannot compute v=k(b P) similar to b(k P) computed by U as it requires the knowledge of private key k of S. Further, A requires u s e r n a m e u and h(u s e r n a m e u ||k) to communicate with U acting as S and with S acting as U. Consequently, A cannot apply man-in-the-middle on the proposed scheme.

6.2.7 Resists session-specific temporary information attack

Assume that the random numbers b and c are leaked in our scheme. Then, A can compute v=b(k P) using the public key k P of the server, so A holds v x and v y . A can use f u from an intercepted login request f u ,b P,z u to retrieve u s e r n a m e u as u s e r n a m e u =f u ⊕v x . Thus, A obtains the values b P,c & u s e r n a m e u to compute sessionkey and k P is the public key of the server but the value h(u s e r n a m e u ||k)b P is missing. Although A holds b & u s e r n a m e u and P is public parameter but A cannot compute h(u s e r n a m e u ||k)b P due to involvement of the private key k of S. As a result, A cannot compute s e s s i o n k e y=h(h(u s e r n a m e u ||k)b P||b P||k P||v||c||u s e r n a m e u ) in spite of the compromise of random numbers b and c. Therefore, our scheme is free from session-specific temporary information attack.

7 Automated security verification using ProVerif

ProVerif is a toolkit used for verifying security properties for cryptographic protocols using a specification language based on an extension of pure Pi-calculus. We use ProVerif to prove that proposed scheme satisfies the mutual authentication and session key secrecy [38–41]. ProVerif supports a number of cryptographic primitives, including encryption and decryption (symmetric and asymmetric), digital signatures, and hash function, Diffie-Hellman key agreements, and so on. Initially we defined two channels, a secure channel SCh1 is used for the secure communication between user and the Server, and a public channel PCh2 is used for the public /insecure communication between user and the Server.

(* ————- Channels ——————–*)

free SCh1:channel [private]. (*secure channel between User and Server *)

free PCh2:channel. (*public channel between User and Server *)In this security analysis, session key is modeled as follows:

(* ————-Session Key—————*)

free sessionkey:bitstring [private].All public parameters are defined as follows:

(*————— Variables & Constants —————-*)

free usernameu:bitstring.

free sessionkey:bitstring [private].

free pwu:bitstring [private].

const k:bitstring [private].

const p:bitstring.

const q:bitstring.

const P:bitstring.One-way Hash, Multiplication, Concatenation, Exclusive OR, getx, gety, addition, Elliptic Curve Point Multiplication and Subtraction functions are modeled as constructors.

(*————— Constructors —————–*)

fun oneWH(bitstring):bitstring.

fun getx(bitstring):bitstring.

fun gety(bitstring):bitstring.

fun concat(bitstring,bitstring):bitstring.

fun add(bitstring,bitstring):bitstring.

fun ExcOR(bitstring,bitstring):bitstring.

fun multi(bitstring,bitstring):bitstring.

fun ECMP(bitstring,bitstring):bitstring.

fun subtract(bitstring,bitstring):bitstring.We also defined the following equation to benefit exclusive or property (a⊕b)⊕b=a.

(*————— Destructors & Equations —————–*)

equation forall a:bitstring,b:bitstring; ExcOR(ExcOR(a,b),b)=a.Following four events are defined to model the initiation and termination of both user and server processes.

(*——————— Events —————————*)

event User_begin(bitstring).

event User_end(bitstring).

event Server_begin(bitstring).

event Server_end(bitstring).Following three queries are applied, attacker(sessionkey) can verify the secrecy of the session key, while other two queries verifies the initiation and termination of both user and server events.

(*——————–queries—————————*)

query attacker(sessionkey).

query id:bitstring; inj-event(User_end(id)) ==> inj-event(User_begin(id)) .

query id:bitstring; inj-event(Server_end(id)) ==> inj-event(Server_begin(id)) .;We have modeled following two processes, one for user (procUsr) and one for server (procSrv).

(*———————-processes—————————*)

let procUsr =

in(PCh2,xkP:bitstring);

(* Registration *)

new au:bitstring;

let HunPa = oneWH(concat(usernameu,(pwu,au))) in

out(SCh1,(usernameu,HunPa));

in(SCh1,xSC:bitstring);

let SC = concat(xSC,au)in

(* Login *)

event User_begin (usernameu);

new b:bitstring;

let (xru:bitstring) = SC in

let bP = multi(b,P) in

let v = ECMP(b,xkP) in

let wu = multi(b,subtract(xru,ECMP(oneWH(concat(user nameu,(pwu,au))),P))) in

let fu = ExcOR(usernameu,getx(v)) in

let zu = oneWH(concat(usernameu,(bP,gety(v),wu))) in

out(PCh2,(fu,bP,zu));

in(PCh2,(xc:bitstring,xAuths:bitstring));

let sessionkey = oneWH(concat(wu,(bP,xkP,v,xc))) in

let Auths=oneWH(concat(xc,sessionkey)) in

if(Auths = xAuths) then

event User_end(usernameu) else 0.

let procSrv=

let kP = ECMP(k,P) in

out(PCh2,kP);

(* Registration *)

in(SCh1, (xusernameu:bitstring,xHunPa:bitstring) );

let ru = multi(add(xHunPa,oneWH(concat(xusernameu,k))),P )in

let SC = concat(ru,kP)in

out(SCh1,SC);

(* Login *)

in(PCh2,(xfu:bitstring,xbP:bitstring,xzu:bitstring));

event Server_begin(k);

let v = ECMP(k,xbP) in

let usernameu’ = ExcOR(xfu,getx(v)) in

let wu’ = ECMP(oneWH(concat(usernameu’,k)),xbP) in

let zu’ = oneWH(concat(usernameu’,(xbP,gety(v),wu’))) in

if(xzu = zu’) then

new c:bitstring;

let sessionkey = oneWH(concat(wu’,(xbP,kP,v,c))) in

let Auths=oneWH(concat(c,sessionkey)) in

out(PCh2,(c,Auths));

event Server_end(k)

else 0.

process ((!p r o c U s r)|(!p r o c S r v)) We execute the modeled processes in ProVerif 1.88 (the newest version). Following are the results:

  1. 1.

    inj-event(Server_end(id)) ==> inj-event(Server_begin(id)) is true.

  2. 2.

    inj-event(User_end(id_1964)) ==> inj-event(User_begin(id_1964)) is true.

  3. 3.

    not attacker(sessionkey[]) is true.

The results (1) and (2) verifies that both server and user processes started and terminated successfully, while (3) verifies that sessionkey is not revealed to adversary and secrecy is maintained.

8 Comparative analysis

We compare the performance of our scheme with Zhang et al.’s [27], Tu et al.’s [28], and Farash’s [29] schemes. Tables 2 and 3 display phase-wise computational cost/complexity and security features of these schemes respectively. We do not consider very lightweight operations such as XOR and string concatenation operations which contribute negligible computational cost. In Table 2, t e p m denotes the time complexity of elliptic curve scalar point multiplication, t s y m denotes the time complexity of symmetric key encryption/decryption, t m i n denotes the time complexity of a modular inversion, t e p a denotes the time complexity of an elliptic curve point addition, t h a s denotes the time complexity of a one-way hash function.

Table 2 Comparison of efficiency: computational cost/complexity
Full size table
Table 3 Comparison of efficiency: computational cost/complexity
Full size table

During registration phase, user computes one hash function in each of the four schemes. In the same phase, computational complexity on S is same in Tu et al.’s, Farash’s and our scheme whereas in Zhang et al.’s scheme S also requires to compute a modular inversion. In password change phase, the computational load of at both, user and the server side is same in all the four schemes except one modular inversion extra at S in Zhang et al.’s scheme. During login-authentication phase, highest computational load is on Zhang et al.’s scheme. Other two schemes [28, 29] and our scheme have almost same computational load, the only change is the addition of one hash operation and reduction of one elliptic curve scalar point multiplication on the server side. This is also exhibited by the total computational complexity during login-authentication. Since hash operation is quite lightweight as compared to elliptic curve scalar point multiplication, our scheme has slightly less computational cost than in schemes [28, 29].

There is remarkable difference in the security features offered by these schemes. Zhang et al.’s scheme with highest computational load suffers from user impersonation, password guessing attacks and does not provide user anonymity. Farash proposed improvement of Tu et al.’s scheme without adding any computational operation and succeeded in removing man-in-the-middle attack. However, both the schemes [28, 29] suffer from user impersonation, password guessing, session-specific temporary information attacks and neither of them provides user anonymity. Our scheme removes these weaknesses even with slightly less computation. Results from Tables 2 and 3 shows that our scheme is an efficient improvement of Farash’s scheme without any additional computational load.

9 Conclusion

In this paper, we analyzed Farash’s protocol for SIP security. We have shown that Farash’s protocol is vulnerable to impersonation attack, password guessing attack and temporary session specific information reveal attack. Furthermore, it does not provide user anonymity. Then we proposed an enhanced protocol to overcome security weaknesses of Farash’s protocol. The proposed protocol is provably secure. We have also analyzed the security of proposed protocol using automated verification tool ProVerif. The proposed protocol is more secure and more efficient as compared with existing protocols.