1 Introduction

The session initiation protocol (SIP) has got much attractiveness during recent times, as it can achieve sessions including IP callas, multimedia distribution and conferences. SIP works on the standards of hyper text transport protocol (HTTP), which is based on request-response messages between client and server. Authentication is considered as a true vital facet for SIP, because the tangled participants must be validated even before start of the session. In SIP, client initiates the request message, while server asks for the legality of client by sending a challenge message, which also contains built-in server authentication information. The client after authenticating the server, sends a response message. The server validates the client by examining the response message. The SIP authentication makes a use of password based authentication along with other public key cryptography methods. The former, however, is more cost efficient than later, but the later provides more security. So we need a trade off between the two. The first password based authentication scheme was proposed by Chang et al. [12]. Successively a number of password based authentication schemes were proposed [2–9, 13, 14, 16–19, 22–28, 30–34, 37, 39, 42]. In earlier password based schemes, the server needs to store a verifier table having an entry for each client. Such schemes were proved to be vulnerable to stolen verifier attack, scalability issues and having high computational costs, because server has to secure the verifier table from unauthorized access by internal as well as external attackers. Further server has to create a distinct entry for each client, which limits the number of clients and needs extra computation for storing and comparing verifier table entries.

Recently Zhang et al. [40] proposed an efficient authentication scheme, the scheme made an efficient use of elliptic curve cryptography. They introduced the notion of authentication without storing any verifier table on server. Further they claimed their scheme to provide resistance to known attacks. But Irshad et al. [26], Zhang et al. [41] and Tu et al. [35] independently mentioned a number of weaknesses in Zhang et al.’s scheme [40]. Irshad et al. [26] claimed the scheme [40] to be vulnerable to replay and denial of services attack, Further Irshad et al. [26] proposed an improved single round scheme, but their scheme was vulnerable to impersonation attack as mentioned by Arshad and Nikooghadam [8], they also proposed an improved scheme. Unfortunately Arshad and Nikooghadam’s scheme [8] once again introduced the verification tables on server side as well as having no provision for user anonymity. Zhang et al. [41] also proposed an improved scheme of [40], but their improved scheme was proved to be vulnerable to server impersonation attack by Farash [21]. Farash [21] then proposed an improved scheme, the scheme of Farash [21] once again does not provide user anonymity and is vulnerable to replay and denial of services attacks.

In 2014, Tu et al. [35] also proposed an improved scheme to improve the security of Zhang et al.’s scheme [40] and claimed it to be secure. However very recently Farash [20] mentioned that Tu et al.’s scheme is vulnerable to server impersonation attack, further Farash [20] proposed an improvement of Tu et al.’s scheme. In this paper we show that Tu et al.’s scheme [35] is vulnerable to server impersonation, replay and denial of services attacks as well as lacking user anonymity. Further, we analyze that Farash’s improvement [20] on Tu et al.’s scheme [35] is lacking user anonymity and is also vulnerable to replay attack. Then an anonymous authenticated key agreement is proposed which is more secure and suitable for all lightweight environments. The rest of the paper is organized as follows. In Section 2 the procedure for SIP authentication and background for ECC has been described. Section 3 reviews Tu et al.’s scheme [35] followed by Farash’s improvement [20] , while cryptanalysis of Tu et al.’s and Farash’s schemes is presented in Section 4. Section 5 describes our improved authentication scheme for SIP. In Section 6, we prove the security of the proposed scheme in random oracle model, we have also performed automatic security validation using automated tool ProVerif in same section. Section 7 presents the performance analysis of improved authentication scheme. Finally, we conclude in Section 8.

2 Preliminaries

In this section the SIP architecture [25] and the background for ECC [40] have been described.

2.1 SIP architecture

SIP is based on the request-response messages between client and server like HTTP. In SIP based authentication, a uniform resource identifier (URI) is used to identify users. The SIP design is compromising a number of contributors, including a client agent, redirect, proxy, registration and location servers. The client agent works as a terminal, the proxy server acts as an arbitrator amid the client and server, the caller location is notified by redirect server, while register server posts his new location to location server.

2.2 SIP authentication procedure

To get SIP services, a client initiates registration process with proxy server, the registration process includes a message from client containing his secret information like his identity/user name and password using some secure channel. After registration, the client is allowed to login with proxy server using pre-shared secrets and on some public channel. Then SIP session procedure is performed to locate an other SIP client to establish a session. The login/authentication procedure involves exchange of following messages among client and proxy server:

  1. 1.

    Client → Server: REQUESTA connection request is sent to server by client.

  2. 2.

    Server → Client: CHALLENGE (nonce, realm,info)For the received request, server sends a challenge message to client. The challenge message must contain some random nonce and realm, further it must also have some built in information to verify the legality of server.

  3. 3.

    Client → Server: RESPONSE (nonce, realm, username, info)The client after receiving a challenge message, first verifies sender’s legality then it spawns a response message.

  4. 4.

    For the received response message, the server using some pre-shared information verifies client’s legality, if it proves to be falsify the session is terminated by client. Otherwise, a unique session key is established between both.

2.3 Elliptic curve cryptography

In this subsection the concepts relating to elliptic curve cryptography (ECC) pertinent to the manuscript are illustrated. ECC is based on some chosen real elliptic curve E p (a,b):y 2=x 3+a x+b mod p where a,b∈Z p & 4a 3+27b 2 mod p≠0 for a large prime p. The integers a,b both defines the curve. A point (x,y) over E p (a,b) must verifies the former elliptic curve equation. The scalar multiplication is defined as the recurrent addition v R=R+R+R.....+R (v times), where R is a point over E p (a,b) and v∈F p . All the field parameters (p,a,b,R,n) are of the field F p . ECC provides same level of security as of traditional public key cryptography like RSA, DSA and DH with lesser parameters size [36].

3 Tu et al.’s scheme & Farash’s improvement

This section reviews Tu et al.’s [35] SIP authentication scheme using ECC and its improvement proposed by Farash [20]. Tu et al.’s scheme as illustrated in Fig. 1 consists of four phases: system initialization phase, registration phase, mutual authentication with key exchange phase and password changing phase. The notation guide for paper is described in Table 1.

Fig. 1
figure 1

Tu et al.’s scheme

Full size image
Table 1 Notation guide
Full size table

3.1 System initialization phase

At start Server \(\mathcal {S}\) selects an elliptic curve E p (a,b), then a point P as base point over selected curve. \(\mathcal {S}\) chooses three one way hash functions. Then \(\mathcal {S}\) selects a random private key \(d_{S}\in Z_{n}^{\ast }\) and calculates public key K S =d S P. Finally \(\mathcal {S}\) publishes {E p (a,b),P,K S ,h(.),h 1(.),h 2(.)} and keeps d S secret.

3.2 Registration phase

Registration phase consists of two steps firstly client \(\mathcal {U}\) choose a password P W i , selects a random integer \(a\in Z_{n}^{\ast }\). Then \(\mathcal {U}\) computes h(P W i ||a), and sends h(P W i ||a), u s e r n a m e to \(\mathcal {S}\) via some secure channel. When server \(\mathcal {S}\) receives h(P W i ||a) and username, \(\mathcal {S}\) computes R=(h(P W i ||a)+h(u s e r n a m e||d S )), then stores R in smart card, and delivers the smart card to \(\mathcal {U}\) through any secure channel. After receiving R, \(\mathcal {U}\) stores a in smart card. Now, smart card contains (R,a).

3.3 Mutual authentication and key exchange phase

  1. Step 1:

    The client \(\mathcal {U}\) initiates authentication process by inserting his smart card in reader and entering the password P W i , the smart card generate a random number \(b\in Z_{n}^{\ast }\), then computes V=b P, V ′=b(R−h(P W i ||a)P) and W=h(u s e r n a m e||V||V ′). Further \(\mathcal {U}\) requests authentication by sending username, V& W in a request message to \(\mathcal {S}\).

  2. Step 2:

    After receiving the request \(\mathcal {S}\) calculates V ″=h(u s e r n a m e||d S )V and W=h(u s e r n a m e||V||V ″). \(\mathcal {S}\) verifies \(W\overset {?}{=}W^{\prime }\), if not true \(\mathcal {S}\) aborts the session. Otherwise, \(\mathcal {S}\) choose two random number \( c,r \in Z_{n}^{\ast }\), and calculates C=c P, K=c V then \(\mathcal {S}\) computes the shared key S K=h 1(K||r||u s e r n a m e), and A u t h S =h 2(K||W||r||S K), finally it sends challenge message with (r e a l m,A u t h S ,C,r) to client via public channel.

  3. Step 3:

    \(\mathcal {U}\) compute K=b C and S K=h 1(K||r||u s e r n a m e) upon receiving the challenge message from \(\mathcal {S}\). \(\mathcal {U}\) further verifies \(Auth_{S}\overset {?}{=}h_{2}(K||W||r||SK)\), if the relationship proves to be falsify, the session is aborted by \(\mathcal {U}\). Otherwise, \(\mathcal {U}\) computes A u t h U =h 2(K||W||r+1||S K), it further sends the response message (r e a l m,A u t h S ) to \(\mathcal {S}\). \(\mathcal {U}\) keeps SK as shared key with \(\mathcal {S}\).

  4. Step 4:

    When \(\mathcal {S}\) receives the response message it checks \(h_{2}(K||W||r+1||SK)\overset {?}{=}Auth_{U} \), if relationship does not exist the session is aborted by \(\mathcal {S}\). Otherwise, \(\mathcal {S}\) stores session key SK.

3.4 Password change phase

A password change request is initiated after generation of a session key. Following steps are performed between \(\mathcal {U}\) and \(\mathcal {S}\) for successful password update.

  1. Step 1:

    \(\mathcal {U}\) selects a new password P W n and two random numbers \(a_{n},N_{n} \in Z_{n}^{\ast }\), then \(\mathcal {U}\) computes, C u =E S K (u s e r n a m e∥N n ∥h(P W n ∥a n )∥h(u s e r n a m e∥N n ∥h(P W n ∥a n ))). Finally \(\mathcal {U}\) sends password change request {C u ,N n } to \(\mathcal {S}\).

  2. Step 2:

    For the received password change request {C u ,N n }. \(\mathcal {S}\) first decrypts C u , then checks the validity of message tag h(u s e r n a m e∥N n ∥h(P W n ∥a n )). If it is valid \(\mathcal {S}\) computes R n =(h(P W n ||a n )+h(u s e r n a m e||d S ))P and C S =E S K (R n ∥h(u s e r n a m e∥N n +1∥R n )). Finally \(\mathcal {S}\) sends C S to \(\mathcal {U}\).

  3. Step 3:

    Upon receiving C S , \(\mathcal {U}\) decrypts it and verifies the tag h(u s e r n a m e∥N n +1∥R n ), if it is valid. \(\mathcal {U}\) stores R n and a n in smart card.

3.5 Farash’s improvement

This subsection reviews Farsh’s improvement on Tu et al.’s scheme. Farash slightly modified the authentication phase of Tu et al.’s scheme. Farash’s modification is an alternation in computation of A u t h S shown as follows:

$$Auth_{S}=h_{2}(K||V^{\prime\prime}||r||SK) $$

While there is no change in system initialization, registration and password change phases.

4 Cryptanalysis of Tu et al.’s scheme & Farash’s improvement

This section shows that an adversary can easily launch impersonation attack on Tu et al.’s scheme. We show that the adversary can easily masquerade as a legitimate server to share a session key. Further, we show that Tu et al.’s scheme and Farash’s improvement both are lacking user anonymity and are vulnerable to replay attack and denial of services attacks.

4.1 Weaknesses of Tu et al.’s scheme

4.1.1 Server Impersonation Attack

By impersonation attack, an active adversary \(\mathcal {A}\) can easily badge itself as a legal server without knowing the private key of server. As illustrated in Fig. 2, adversary \(\mathcal {A}\) do following steps in order to masquerade the legal server \(\mathcal {S}\) to share the session key with the client \(\mathcal {U}\).

  1. Step 1:

    Initially when a legal client \(\mathcal {U}\) sendsR E Q U E S T(u s e r n a m e,V,W) to the server \(\mathcal {S}\), the attacker \(\mathcal {A}\) intercept the message and selects two random numbers \(c_{a},r_{a}\in Z_{n}^{\ast }\). \(\mathcal {A}\) further calculates C a =c a P, K=c a V, S K=h 1(K||r||u s e r n a m e) and A u t h S =h 2(K||W ′||r||S K)

    Fig. 2
    figure 2

    Server impersonation attack on Tu et al.’s scheme

    Full size image
  2. Step 2:

    \(\mathcal {A}\) sends C H A L L E N G E(r e a l m,A u t h S ,C a ,r a ) to \(\mathcal {U}\).

  3. Step 3:

    Upon receiving the message \(\mathcal {U}\) calculates K=b C and S K=h 1(K||r||u s e r n a m e), then \(\mathcal {U}\) checks \(Auth_{S}\overset {?}{=}h_{2}(K||W||r||SK)\), it is obvious that A u t h S hold. \(\mathcal {U}\) further computes A u t h U =h 2(K||W||r+1||S K).

  4. Step 4:

    \(\mathcal {U}\) sends R E S P O N S E(r e a l m,A u t h U ) to \(\mathcal {S}\).

  5. Step 5:

    \(\mathcal {A}\) intercepts the response message, the shared key between \(\mathcal {U}\) and \(\mathcal {A}\) is S K=h 1(K||r||u s e r n a m e).

Therefore, \(\mathcal {A}\) successfully launched server impersonation attack and exchanged the session key S K=h 1(K||r||u s e r n a m e) with legal user \(\mathcal {U}\).

4.1.2 No provision for user anonymity

Along with traditional security, user anonymity and privacy has emerged as an extremely important factor to be considered. Without privacy and anonymity user’s sensitive personal information can be accessed by an adversary by just analyzing the session information. Specially in mobile communication, the attacker may become able to identify \(\mathcal {U}\)’s login history, his movement patterns, current location and so on. Furthermore, such sensitive information may be misused by the adversary. Tu et al.’s scheme did not consider these loopholes hence lacking user anonymity.

4.1.3 Replay attack and denial of service attack

In Tu et al.’s scheme, an active attacker \(\mathcal {A}\) after intercepting a login request R E Q U E S T(u s e r n a m e,V,W) can replay it later on, because the request does not contain any time stamp. Off course \(\mathcal {A}\) will not be able to stake the session key as such replay will be fixed in response message R E S P O N S E(r e a l m,A u t h U ) by the attacker, but such attack can hoax \(\mathcal {S}\) and \(\mathcal {U}\) to perform step 2 and 3 of authentication phase resulting into a counterfeit utilization of computation power as well as communication and storage resources. A simultaneous execution of a large number of such attacks can even lead to denial of services attacks causing access prevention to the legal client.

4.2 Weaknesses of Farash’s scheme

4.2.1 No provision for user anonymity

Farash presented an improvement of Tu et al.’s scheme. Unfortunately in his improvement, Farash did not consider the the importance of user anonymity and just change the computation of A u t h S , while username is sent in plain text to server. Therefore Farash’s improvement is also lacking user anonymity, which can cause serious threats as discussed earlier in Section 4.1.2 .

4.2.2 Replay attack and denial of service attack

Similar to Tu et al.’s scheme, in Farash’s scheme an active attacker \(\mathcal {A}\) after intercepting a login request R E Q U E S T(u s e r n a m e,V,W) can replay it later on, forcing \(\mathcal {S}\) to process the request and send the challenge message to \(\mathcal {U}\), because the request does not contain any time stamp. Which not only burdens the system but can also cause denial of services to client.

5 Proposed scheme

The security breaches of Tu et al.’s and Farash’s schemes are because the security of their schemes relies on public parameters V, W and username transmitted on an insecure channel. In Tu et al.’s scheme V and W are also involved in the computation of SK and A u t h S . So an adversary can easily generate SK and A u t h S in order to masquerade itself as the legal server. Similarly, the absence of time stamp in both Tu et al.’s and Farash’s schemes resulted into burdening the system and replay as well as denial of service attacks. To improve Tu et al.’s scheme, we alternated the transmission of W and username by \(\overline {W}\) and \(\overline {username}\), which provides resistance to impersonation and replay attacks as well as provides proper user anonymity. We have amended only registration and mutual authenticated key exchange phases, proposed scheme works as follows:

5.1 Registration phase

Registration phase consists of two steps firstly client \(\mathcal {U}\) choose a password P W i , selects a random integer \(a\in Z_{n}^{\ast }\). Then \(\mathcal {U}\) computes h(P W i ∥a), and sends h(P W i ∥a), u s e r n a m e to \(\mathcal {S}\) via some secure channel. Upon reception of registration request message h(P W i ∥a),u s e r n a m e. Server \(\mathcal {S}\) selects random \(r \in Z_{n}^{\ast }\) and computes \(\overline {username}=Enc_{d_{S}}(username\|r)\), R=(h(P W i ∥a)+h(u s e r n a m e∥d S )). Further \(\mathcal {S}\) stores R and \(\overline {username}\) in smart card, and deliver the smart card to \(\mathcal {U}\) through any secure channel. After receiving smart card, \(\mathcal {U}\) stores a in it. Finally, smart card contains \((R,\overline {username},a)\).

5.2 Mutual authentication & key exchange phase

  1. Step 1:

    \(\mathcal {U}\rightarrow \mathcal {S}\): \(\{\overline {username}\), V ,\(\overline {W},t_{i}\}\)The client \(\mathcal {U}\) initiates authentication process by inserting his smart card (S C) in the reader and entering the password P W i . SC then generates a random number \(b\in Z_{n}^{\ast }\), and computes:

    $$\begin{array}{@{}rcl@{}} V&=&bP \end{array} $$
    (1)
    $$\begin{array}{@{}rcl@{}} V^{\prime}&=&b(R-h(PW_{i}||a)P) \end{array} $$
    (2)
    $$\begin{array}{@{}rcl@{}} W&=&h(username||V||V^{\prime}) \end{array} $$
    (3)
    $$\begin{array}{@{}rcl@{}} \overline{W}&=&h_{1}(W\oplus V\oplus t_{i}) \end{array} $$
    (4)

    where t i is freshly generated time stamp. Further \(\mathcal {U}\) requests authentication by sending \(\overline {username}\), V and \(\overline {W}, t_{i}\) in request message to \(\mathcal {S}\).

  2. Step 2:

    \(\mathcal {S}\rightarrow \mathcal {U}\): {r e a l m,A u t h S ,C,r,Z}After receiving the request \(\mathcal {S}\) first generates a new time stamp t s and then compares it with received t i . If the difference between both is with in a threshold time period Δ. \(\mathcal {S}\) considers the time stamp fresh and proceeds with the login request. Otherwise, \(\mathcal {S}\) aborts the session. For valid time stamp \(\mathcal {S}\) proceeds with login request as follows:

    $$\begin{array}{@{}rcl@{}} username\|r&=&Dec_{d_{S}}(\overline{username}) \end{array} $$
    (5)
    $$\begin{array}{@{}rcl@{}} V^{\prime\prime}&=&h(username||d_{S})V \end{array} $$
    (6)
    $$\begin{array}{@{}rcl@{}} W^{\prime}&=&h(username||V||V^{\prime\prime}) \end{array} $$
    (7)

    Further, \(\mathcal {S}\) verifies \(W\overset {?}{=}h_{1}(W^{\prime }\oplus V\oplus t_{i})\), if not true \(\mathcal {S}\) aborts the session. Otherwise, \(\mathcal {S}\) chooses three random numbers \( c,r,r_{n} \in Z_{n}^{\ast }\) and computes:

    $$ C=cP $$
    (8)
    $$\begin{array}{@{}rcl@{}} K&=&cV \end{array} $$
    (9)
    $$\begin{array}{@{}rcl@{}} SK&=&h_{1}(K||r||username\|t_{i}) \end{array} $$
    (10)
    $$\begin{array}{@{}rcl@{}} Auth_{S}&=&h_{2}(K\|W^{\prime}\|r\|SK\|t_{i}) \end{array} $$
    (11)
    $$\begin{array}{@{}rcl@{}} Z&=&Enc_{d_{S}}(username\|r_{n})\oplus W^{\prime} \end{array} $$
    (12)

    Finally \(\mathcal {S}\) sends {r e a l m,A u t h S ,C,r,Z} to client via public channel.

  3. Step 3:

    \(\mathcal {U}\) Compute K=b C and session key S K=h 1(K∥r∥u s e r n a m e∥t i ) upon receiving the challenge message from server, then it verifies \(Auth_{S}\overset {?}{=}h_{2}(K\| W||r||SK\|t_{i})\), if the relationship proves to be falsify, the session is aborted by \(\mathcal {U}\). Otherwise \(\mathcal {U}\) replaces \(\overline {username}=Z\oplus W\). Finally SK is set as shared key with \(\mathcal {S}\)

6 Security analysis

This section analyzes the security of proposed scheme, the scheme provides mutual authentication, resist user and server impersonation attacks and is secure against stolen verifier, man-in-middle and off line password guessing attack, the scheme also provides perfect forward secrecy. We have proved the security of proposed scheme in random oracle model as well by using automated tool ProVerif. Further we have also performed informal security comparisons with existing schemes.

6.1 Provable security model

To analyze the security of the proposed scheme, we adopted the formal security model introduced in [10, 11].

6.1.1 Security model

There are two participants in the proposed authentication protocol \(\mathcal {P}\): a client \(\mathcal {U}\) and a server \(\mathcal {S}\). During execution of \(\mathcal {P}\), there may be several instances of each participant, where each instance is linked with a number z and is termed as an oracle jumbled in a divergent execution of \(\mathcal {P}\). We outline U x as the x th instance of \(\mathcal {U}\), similarly S y is outlined as y th instance of \(\mathcal {S}\), we also term I z for both the instances U x and S y with eradication of differences. There can be three possible outcomes of an oracle, accept, reject or ⊥. An oracle ranges to an accept form, if it receives a righteous message. The wrong message lead to reject form, while ⊥ state appears if no decision is made or no result returned.

Even before execution of \(\mathcal {P}\), \(\mathcal {U}\) owns a u s e r n a m e, P W i , while the smart card SC contains \(R,\overline {username},a\). \(\mathcal {S}\) is having a private and public key pair d S and K S =d S P. There are finite number of password, while the password dictionary \(\mathcal {D}\) is of size \(|\mathcal {D}|\). \(\mathcal {S}\) is assumed to be secure.

According to adversary capabilities, the attacker \(\mathcal {A}\) is having full control over public communication channel. \(\mathcal {A}\) can initiate and arbitrate the session between \(\mathcal {U}\) and \(\mathcal {S}\). \(\mathcal {A}\) aims to violate communication privacy and session key secrecy. \(\mathcal {A}\) can make a number of queries in oracles and may get replies. The list of such queries is itemized below:

  • h(s/s1/s2,r e c): It is a hash oracle and it results into some arbitrary result r. Employment of this query builds a record (r e c,r), depending upon the first parameter, it generates three different hash lists h s l i s t ,h s1l i s t and h s2l i s t . Dealing of these records is in proof process.

  • S e n d(U x/S y,m s g/S C L D): This query replicates the active attack on communication, it yields the message that U x or S y generates upon reception of message msg, if second argument of S e n d query is SCLD, the output is the message \(\{\overline {username},V,\overline {W},t_{i}\}\) in step 1 of authentication phase. The query normally finishes as the steps in mutual authentication phase of \(\mathcal {P}\).

  • E x e c u t e(U x,S y): This query enables the attacker to perform a passive attack on the communication channel. By simulating E x e c u t e, \(\mathcal {A}\) can access the messages exchanged over insecure communication channel between U x o r S y.

  • R e v e a l(I x): This query designates the known session key attack. By this query, \(\mathcal {A}\) can acquire the computed session key between U x and S y.

  • C o r r u p t(S C): This query enables \(\mathcal {A}\) to obtain all the parameters stored in smart card (S C).

  • T e s t(I z): This query stands for obtaining the session key. The simulation of T e s t query results into ⊥, if I z did not generate a session key. Otherwise, it outputs into flipping of a coin Ω. If Ω=1, T e s t query outputs the existent session key, if Ω=0 uniform random string is returned, whose length is same as the actual session key. \(\mathcal {A}\) is allowed to ask T e s t query only once on the fresh oracle.

Following are some definitions used to prove the security of proposed scheme.

  • P a r t n e r i n g: Each participating instance U x S y is having a partner identity \(pi{d_{U}^{x}}\) or \(pi{d_{S}^{y}}\)alog with a session key \(s{k_{U}^{x}}\) or \(s{k_{S}^{y}}\) an identifier \(si{d_{U}^{x}}\) or \(si{d_{S}^{y}}\), which is accepted and agrees a session key. U x and S y are termed as partners if and only if \(si{d_{U}^{x}}=si{d_{S}^{y}}\), \(pi{d_{S}^{y}}=U^{x}\), \(pi{d_{U}^{x}}=S^{y}\) and \(s{k_{U}^{x}}=s{k_{S}^{y}}\).

  • fresh: Any instance I z is believed as fresh, if no R e v e a l query happened on I z.

  • P A P−s e c u r i t y: The advantage for \(\mathcal {A}\) to break the security of \(\mathcal {P}\) is defined as the probability that can acceptably guess the result of flipping of coin Ω by T e s t(I z), where I z is fresh as well as accepted. Let \(\mathcal {A}\) outputs Ω ′, the advantage is as follows:

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

    The proposed authentication protocol is designated as P A P−s e c u r e if \(Adv_{\mathcal {P}}^{PAP}(\mathcal {A})\) is negligible.

  • We define the Elliptic curve computational Diffie-Hellman (ECCDH) assumption as follows: Given three point α P,β P and P over an elliptic curve E p (a,b), where \(\alpha , \beta \in Z_{n}^{\ast }\), the probability \(\mathcal {A}\) can compute α β P in polynomial time t can be defined as \(Adv^{ECCDH}_{\mathcal {A}}(t)\). The ECCDH assumption implies that \(Adv^{ECCDH}_{\mathcal {A}}(t)\leq \epsilon \).

6.1.2 Security proof

Theorem 1

The password engaged by \(\mathcal {U}\) is from a password dictionary \(\mathcal {D}\) having size \(|\mathcal {D}|\) . Let l hs be the length of hash value, \(\mathcal {P}\) is the proposed authentication protocol. An adversary \(\mathcal {A}\) during polynomial time t can make maximum q snd Send queries, q exe Execute queries and q hs , q hs1 , q hs2 hash queries. \(\mathcal {A}\) ’s advantage is as follows:

$$\begin{array}{@{}rcl@{}} Adv_{\mathcal{P}}^{PAP}(\mathcal{A}) &\leq& \frac{q^{2}_{hs} + q^{2}_{hs1} + q^{2}_{hs2}}{2^{l_{hs}}} + \frac{(q_{snd}+q_{exe})^{2}}{2(p-1)}\\ &+&\! 2q_{exe} \cdot Adv_{\mathcal{A}}^{ECCDH}(\overline{W})\! +\! 2\max\left\{\frac{q_{hs1}}{2^{l_{hs}}}, \frac{q_{snd}}{|D|}\right\} \end{array} $$
(14)

Proof

For proof, we mark a sequence of games ranging from G 0 to G 4, the event S u c c i means that \(\mathcal {A}\) correctly gausses Ω during G i effectively in T e s t. As per the requirements for our model, there is no need for \(\mathcal {A}\) to compute identity of the client because there is only one user. The games for our proof are listed below:

  • Game G 0: It is the real protocol in random oracle model. Here, we selected random coin flipped value Ω′. We realize that \(\mathcal {A}\)’s advantage to guess Ω correctly is as follows:

    $$ Adv_{\mathcal{P}}^{PAP}(\mathcal{A})=2Pr[Succ_{0}]-1 $$
    (15)

  • Game G 1: We simulate all oracles for queries. Also, three lists are used to store the record (r e c,r) formed after query mentioned in the security model. h s l i s t ,h s1l i s t and h s2l i s t are used to store answers to h oracle. On hash query, if there exists a record (r e c,r) in corresponding hash list, r is returned, otherwise a random value r ′ is returned to \(\mathcal {A}\) and a record is added to corresponding hash list against r ′. When h oracle is queried by \(\mathcal {A}\) then the record in h A l i s t .From \(\mathcal {A}\)’s view point G 0 and G 1 are not distinguishable through the simulation, so

    $$ Pr[Succ_{1}]=Pr[Succ_{0}] $$
    (16)

  • Game G 2:Some of the collisions are avoided during G 2, which is aborted when some collisions ensued on transcripts (V,C) and on hash values. As b,c∈[1,p−1] and the length of each hash value is l h s . Referring the birthday paradox, the the maximum collision probability in result of hash oracles are \({q^{2}_{hs}}/{2^{l_{hs}+1}}\), \({q^{2}_{hs1}}/{2^{l_{hs}+1}}\) and \({q^{2}_{hs2}}/{2^{l_{hs}}}\). Similarly, the maximum collision probability in the transcripts is (q s n d +q e x e )2/2(p−1). So we have

    $$\begin{array}{@{}rcl@{}} |\text{Pr}[Succ_{2}]-\text{Pr}[Succ_{1}]|&\leq& \frac{q^{2}_{hs} + q^{2}_{hs1} + q^{2}_{hs2}}{2^{l_{hs}+1}}\\ &+&\frac{(q_{snd}+q_{exe})^{2}}{2(p-1)} . \end{array} $$
    (17)

  • Game G 3: This game is aborted, if \(\mathcal {A}\) computes correct messages with out hash oracles, the game is divided into two cases according to two messages

    1. 1.

      To forge \(Send(S^{y},(\overline {username},V,\overline {W},t_{i}))\) query, \(\mathcal {A}\) must make (W⊕V⊕t i ) and V ′ queries, Or we can say that (W⊕V⊕t i )∈h A l i s t should be true. If we have not found it as a role of server, the probability is up to \(\frac {q_{snd}}{2^{l_{hs}}}\). Note that \(\mathcal {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_{hs}}{2^{l_{hs}}}\).

    2. 2.

      To forge S e n d(U i,(r e a l m,A u t h S ,C,r,Z)), A must make (K∥W ′∥r∥S K∥t i ). The probabilities are upper bounded by \(\frac {q_{hs1}}{2^{l_{hs}}}\) and \(\frac {q_{snd}}{2^{l_{hs}}}\) respectively for the matter that the two records do not exist in h A l i s t .

    Hence 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{2q_{snd}+2q_{hs1}}{2^{l_{hs}}} $$
    (18)

  • Game G 4: For this game, ECCDH is brought in, \(\mathcal {A}\) is allowed to make oracles normally. \(\mathcal {A}\) can acquire session key SK, if he win this game. To win this game \(\mathcal {A}\) has to solve ECCDH. To compute SK, \(\mathcal {A}\) must ask (k P∥r∥u s e r n a m e u ) query. If this record exists in the list h A l i s t , \(\mathcal {A}\) breaks ECCDH problem. The difference between the game G 4 and the game G 3 is as follows:

    $$\begin{array}{@{}rcl@{}} |\text{Pr}[Succ_{4}]\! -\! \Pr[Succ_{3}]|\leq q_{exe} \cdot Adv_{\mathcal{A}}^{ECCDH}(\overline{W}). \end{array} $$
    (19)

    There are two possible cases where the adversary distinguishes the real session key SK and the random key as follows:

    1. Case 1.

      the adversary queries (K,r,u s e r n a m e) to h s1. The probability that this event occurs is \(\frac {q_{hs1}}{2^{l_{hs}}}\).

    2. Case 2.

      the adversary asks S e n d(U x query and successfully impersonates U to S. The adversary is not allowed to reveal static key P W i of \(\mathcal {U}\). Thus, in order to impersonate \(\mathcal {U}\), the adversary has to obtain some information of the password P W i of \(\mathcal {U}\). The probability is 1/|D|. Since there are at most q s n d sessions of this kind, the probability that this event occurs is lower than q s n d /|D|

      As a conclusion,

      $$ \text{Pr}[Succ_{4}]=\frac{1}{2}+\max\left\{\frac{q_{hs1}}{2^{l_{hs}}}, \frac{q_{snd}}{|D|}\right\}. $$
      (20)

    Combining the equations (15), (16), (17), (18), (19) and (20) the announced result as follows:

    $$\begin{array}{@{}rcl@{}} Adv_{\mathcal{P}}^{PAP}(\mathcal{A})\! &=&\! \text{Pr}[Succ_{0}]- 1|\\ &=&\! 2\! \left|\text{Pr}[Succ_{0}]\! -\! \text{Pr}[Succ_{4}]\! +\! \max\left\{\frac{q_{h1}}{2^{l_{hs}}}, \frac{q_{snd}}{|D|}\right\}\right|\\ &\leq&\! 2\! \left(\! |\text{Pr}[Succ_{0}]\! -\! \text{Pr}[Succ_{4}]|\! +\! \max\left\{\frac{q_{hs1}}{2^{l_{hs}}},\! \frac{q_{snd}}{|D|}\right\}\! \right)\\ &\leq&\! 2\! \left({\vphantom{\left\{\frac{q_{hs1}}{2^{l_{hs}}}, \frac{q_{snd}}{|D|}\right\}}}|\text{Pr}[Succ_{1}]- \text{Pr}[Succ_{2}]| + |\text{Pr}[Succ_{3}]\right.\\ &-&\! \left.\text{Pr}[Succ_{4}]| +\max\left\{\frac{q_{hs1}}{2^{l_{hs}}}, \frac{q_{snd}}{|D|}\right\}\right)\\ &\leq&\! \frac{q^{2}_{hs} + q^{2}_{hs1} + q^{2}_{hs2}}{2^{l_{hs}}} + \frac{(q_{snd}+q_{exe})^{2}}{2(p-1)} \\ &+&\! 2q_{exe} \cdot Adv_{\mathcal{A}}^{ECCDH}(\overline{W})\! +\! 2\max\left\{\frac{q_{hs1}}{2^{l_{hs}}}, \frac{q_{snd}}{|D|}\right\}. \end{array} $$

□

6.2 Automated security verification

In this subsection, we have performed the automated security analysis of the proposed scheme using the widespread automated tool ProVerif [1]. ProVerif can verify privacy and security of authentication schemes [15, 38]. ProVerif is constructed over the well known applied π calculus, which can support many cryptographic primitives including one way functions, encryption, digital signatures, Diffie-Hellman and many more. In-order to prove the security of the proposed scheme, we have imprinted the steps as mentioned in Section 5 and shown in Fig. 3, to model the message exchanged, we have introduced two channels for communication among \(\mathcal {U}\) and \(\mathcal {S}\), a secure channel C H1_S e c for registration phase and a public channel C H2_P u b for login and authentication phase.

Fig. 3
figure 3

Proposed scheme

Full size image

Constants and variables used in proposed scheme are defined as follows:

We have modeled \(\mathcal {U}\)’s password P W i and \(\mathcal {S}\)’s private key as private, while username, \(\mathcal {S}\)’s public key Ks, ECC parameters p,q and base point P are declared as public and accessible to all participants including adversary. ProVerif defines cryptographic primitives as constructors, destructors and equations. We have defined the constructors H,H1,H2, concat, add, ExcOr, multi, ECMP, subtract and syme for three hash functions, a point addition, exclusive or, integer multiplication, point multiplication, subtract and symmetric key encryption respectively. While symmetric decryption is defined by the destructor symd. To exploit the property of exclusive or, (a⊕b)⊕b=a, we have defined an equation (ExcOR).

Following four events are defined to analyze the security of our proposed scheme.

We have modeled two events for each \(\mathcal {U}\) and \(\mathcal {S}\), begin_User(bitstring). and end_User(bitstring). for start and end of \(\mathcal {U}\), similarly two events are defined for \(\mathcal {S}\) begin_User(bitstring). and end_User(bitstring). to start and end of \(\mathcal {S}\). Protocol’s authenticity can be proved by revealing the corresponding relation ship between each participant’s begin and end event.

We have defined two distinct processes to model the participants, the process pClientU symbolizes \(\mathcal {U}\), while the process pServerS models \(\mathcal {S}\). The process pClientU first registers by selecting a and HUPa and sends username along with HUPa to \(\mathcal {S}\) on the secure channel CH1_Sec. After registration pClientU pledges the login & authentication process by computing V,V ′,W,x_W. Then pClientU sends pseudo username x_username, V,x_W,ti to pServerS. Further pClientU computes K,SK after receiving response message xAuths,xC,xr,xZ from pServerS. Then pClientU verifies the validity of xAuths, if validity holds server is authenticated, then pClientU further replaces X_username with new value sent by server.

The server process pServerS frights after receiving registration message from pClientU, it computes pseudo user name X_username,R. Then sends both X_username,R to pClientU. Then after pServerS computes V ″,W ′ and checks the validity of x_W, if its valid pServerS computesC,K,SK,Auths after receiving login request message from pClientU. Finally pServerS computes Z and sends Auths,C,r,Z to pClientU.

The modeled protocol is replicated as the unbounded parallel execution of three processes shown as follows:

We have defined following queries to verify the security and correctness of our protocol.

The query attacker(Z) models the attacker capabilities, where Z is unknown to attacker, if the predicate not attacker(Z) results into false, then Z is revealed to attacker hence authenticity and secrecy is not maintained, if it results into true, the protocol is secure.The attacker knows all public parameters. The attacker query is applied on SK I (the session key). Further two queries on inj-event verifies that each event started and terminated successfully and the protocol possesses the correctness property.

The results are as follows:

  1. 1.

    inj-event(end_Server(id)) ==> inj-event(begin_Server(id)) is true.

  2. 2.

    inj-event(end_User(id_1780)) ==> inj-event(begin_User(id_1780)) is true.

  3. 3.

    not attacker(SK[]) is true.

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

6.3 Further security discussion

This subsection analyzes the security of proposed scheme. The analysis verifies that proposed scheme resists all known attacks, while ensuring user anonymity and untraceability. Table 2 illustrates the security comparisons of proposed scheme with related existing schemes. It is evident from Table 2 that only proposed scheme provides user anonymity and untraceability, while all other schemes are lacking user anonymity and untraceability. Similarly, only proposed scheme and Irshad et al.’s scheme [26] provides resistance against replay and denial of service attacks. The provable security analysis is provided by proposed and Farash’s scheme [20] only, likewise only Farash [20, 21], Arshad et al. and proposed schemes are resistant to impersonation attacks, In short except proposed scheme, all other schemes are lacking at least two security requirements.

Table 2 Security comparisons
Full size table

6.3.1 Mutual authentication

In proposed scheme, initially the user sends \(\{\overline {username}, V,\overline {W}\}\), where \(\overline {W}\) involve user’s password P W i , the adversary with out knowing the user password can not generate valid V and \(\overline {W}\) pair. Similarly without the knowledge of server secret key d S the adversary can not generate valid W. Further, A u t h S can be generated after having valid W. So the user is authenticated by checking \(\overline {W}=h_{1}(W\oplus V\oplus t_{i})\), while the server by verifying A u t h S =h 2(K∥W∥r∥S K∥t i ). Hence proposed scheme provides mutual authentication.

6.3.2 Impersonation attack

The adversary may impersonate as a legal user if it successfully generate valid V, W pair, but it requires user P W i and information stored in smart card, so the scheme resist user impersonation attack, similarly the adversary can not impersonate as a legal server, if it become able to generate valid A u t h S , but A u t h S involves the computation of V ″=h(u s e r n a m e∥d S )V and W ′=h(u s e r n a m e∥V∥V ″), both of these require the secret key d S of the server.

6.3.3 Privileged insider attack

Instead of password we just send h(P W i ||a) during registration phase, so privileged insider can not have access to user password P W i .

6.3.4 Stolen verifier attack

In proposed scheme no verifier table is maintained for user’s password, \(\mathcal {S}\) makes use of his secret key d S for authentication. Therefore, the proposed scheme is secure against stolen verifier attack.

6.3.5 Man-in-middle attack

In proposed scheme, valid V ′ can only be generated by using user password, while V ″ can only be computed by server master key d S . Therefore, the scheme withstand the man-in-middle attack.

6.3.6 Replay attack

The adversary can easily intercept the request message \(\{\overline {username},V,\overline {W},t_{i}\}\). Also the adversary can easily replicates the request message. When such replicated request reaches, the server simply verifies the freshness of t i , as t i is old dated, server will know its a replay message. Further Adversary can generate new time stamp t a and can replay request after changing t i by t a , as time stamp is fresh, server after computing V ″ and W ′, checks \(\overline {W}\overset {?}{=}h_{1}(W^{\prime }\oplus V\oplus t_{a})\). The adversary will not pass this test, because \(\overline {W}\) contains in built t i . Similarly adversary will not be able to computeom session key S K=h 1(K||r||u s e r n a m e∥t i ) without knowing user password P W i and either the value of b or c obtaining b from V=b P and c from C=c P, the adversary has to solve untraceable elliptic curve discrete logarithm problem. Similarly if the adversary intercept {r e a l m,A u t h S ,C,r} and sends it to user, the replayed message can not pass the \(Auth_{S} \overset {?}{=} h_{2}(K\|W\|r\|SK\|t_{i})\) test. Therefore the scheme is secure against replay attack.

6.3.7 Off-line password guessing attack

Assuming the adversary get smart card and obtained the secret information (R,a). Further the adversary intercept the message \(\{\overline {username},V,\overline {W},t_{i}\}\). In order to guess user password P W i , the adversary still need server secret key d S to check password validity from V ″=h(u s e r n a m e||d S )V. Therefore the proposed scheme resist off-line password guessing attack.

6.3.8 Perfect forward secrecy

Perfect forward secrecy means that if long term secret keys of one or more legal users are compromised, the secrecy of old session keys will not be affected. For estimating an old session key, the attacker needs to guess more than one session parameters, the random number b is separately generated by the client \(\mathcal {U}\) for each session, while server generates random number c exclusive for each session. In order to find b from V=b P or c from C=c P, the adversary has to solve a hard problem ECDLP. Hence, the attacker could not estimate the previous session keys out of compromised current session key and/or the password.

7 Comparative performance analysis

7.1 Computation cost analysis

Following notations are used for computation cost analysis,

  • T e c p m : Time for Elliptic curve point multiplication

  • T e c p a : Time for Elliptic curve point addition

  • T h : Time for one way hash function

  • T s e d : Time for a symmetric encryption/decryption operation

According to Kilinc and Yanik [29], T e c p m : takes 2.226 ms, T e c p a takes 0.0288 ms, T s e d : takes 0.0046 ms, while T h : takes 0.0023 to complete their processing on a personal computer with Dual CPU E2200 2.20 GHz processor, 2048 MB of RAM and the Ubuntu Operating system by using PBC Library.

Computation cost of proposed scheme as compared with schemes proposed [8, 20, 21, 26, 35, 40, 41] is summarized in Table 3, the proposed scheme over casted [21, 26, 40, 41]. Arshad et al.’s [8] scheme takes least computation resources because in their scheme the verifier is stored at server. The proposed scheme incurs only 2T s e d more on server side as compared with Tu et al.’s and Farsh’s schemes [20, 35].

Table 3 Computational cost analysis
Full size table

7.2 Storage & communication cost analysis

We have also compared the storage and computation costs of proposed scheme with recent related schemes [8, 20, 21, 26, 35, 40, 41]. We selected hash function SHA-1, whose out put is 160 bit long, further we employed AES as symmetric key algorithm of block size 128 bits. We selected 64 bits username length, while size of realm is 32 bits. The NIST recommended size for ECC operations is 160 bits. The storage and communication cost analysis is illustrated in Table 4. Proposed scheme incurs some extra storage in smart card and having some more communication overhead as compared with schemes [8, 20, 21, 35, 40, 41], while it is having equal storage and less communication cost as compared with [26]. Further Only proposed scheme and Irshad et al.’s scheme [26] achieves authentication in only 2 messages, while rest of the schemes [8, 20, 21, 35, 40, 41] achieves same in 3 messages. Hence proposed scheme is more suitable for practical environments.

Table 4 Storage & communication cost analysis
Full size table

8 Conclusion

This paper analyzed Tu et al.’s authentication and key agreement scheme for SIP and Farash’s improvement on Tu et al.’s scheme. We have shown that Tu et al.’s scheme is vulnerable to server impersonation attack. Further, we have also analyzed that both Tu et al.’s scheme and Farash’s improvement do not provide user anonymity and are vulnerable to replay as well as denial of services attack. To overcome the weaknesses, we have proposed an improved privacy preserving scheme, which ensures mutual authentication and is secure against all known attacks.