1 Introduction

Session Initiation Protocol (SIP) is a text-based signaling protocol which regulates communications over the Internet [6]. SIP is an ideal mechanism to establish, maintain and terminate the multimedia-media sessions carried over the Internet. SIP finds application in controlling multimedia communication sessions such as video calls, conferencing, voice calls, instantaneous messaging via Voice over Internet protocols (VoIP) like Simple Mail Transport Protocol (SMTP) and Hyper Text Transport Protocol (HTTP) [27]. VoIP has revolutionized the concept of conventional telephony of circuit-switch by introducing the notion of internet telephony and SIP is capable to deal with all type of signaling necessities of VoIP. Generally, SIP uses the HTTP-digest-authentication protocol mentioned in RFC2617 [11] to achieve identity authentication. As compared to other signaling protocols such as H.323, SIP is more lightweight and agile [6]. Like SMTP and HTTP, SIP is a request-response procedure carried over insecure network, making request of a server and then awaiting a response. For instance, when a client P (caller) wishes to establish a SIP voice call to the server Q (callee), P should be able to verify that he/she is connected to SIP user agent of Q and not to an adversary. Thus, mutual authentication between the requester and the responder at the opposite ends on the telephone line is very crucial in SIP. However, Internet is subject to various security threats owing to its open nature. Therefore, designing a secure user authentication scheme for SIP-based services is a challenge.

1.1 Related work

In 2002, Rosenberg et al. [26], a member in the Internet Engineering Task Force (IETF) of Multi-Party Multimedia Session Control (MMUSIC) Working Group proposed SIP. The Third-Generation Partnership Project (3GPP) has chosen SIP [26] as the protocol for multimedia applications in 3G mobile networks [12, 17]. Steep increase in multimedia services based on Voice over Internet Protocol (VoIP) has made SIP authentication schemes a preferred field of research.

So far, many SIP authentication schemes have been proposed in literature. Many studies such as [13, 27, 28] revealed the applicability of the server spoofing and the off-line password guessing attacks on the original HTTP-digest-authentication [11]. In 2005, Yang et al. designed a SIP authentication scheme [33] using the Diffie–Hellman key exchange algorithm [8]. Although, the security of their scheme relies on the difficulty of Discrete Logarithm Problem (DLP), it is inapt for devices with low computational power due to the high computational cost. But, according to Tang and Liu [29] and Yoon et al. [37], stolen verifier attack is applicable on Yang et al.’s scheme. Besides, Tang et al. [29] pointed out Denning-Sacco attack onYang et al.’s scheme.

Inspired with the design of Yang et al.’s scheme, in the same year Durlanik and Sogukpinar [9] designed a SIP authentication scheme using elliptic curve cryptosystem (ECC) [4, 14, 18, 23, 24]. The security of their scheme relies on the Elliptic Curve Discrete Logarithm Problem (ECDLP). ECC offers a security-level comparable to that of the classical cryptosystems which use quite larger key sizes. Thus, Durlanik and Sogukpinar’s scheme has considerably low computational cost and occupies less memory space as compared to Yang et al.’s scheme. In 2009, Wu et al. [31] designed an ECC-based SIP authentication scheme to overcome the security problems of various SIP authentication schemes. They claimed that their scheme provides mutual authentication, confidentiality of post authentication messages and perfect forward secrecy simultaneously. They also proved their scheme to be secure in the Canetti–Krawczyk (CK) security model [5]. In contrast to the earlier schemes [9, 33], Wu et al.’s scheme is suitable for low powered devices with limited memory space. Nonetheless, according to Yoon et al. [37], SIP authentication schemes proposed by Durlanik and Sogukpinar and Wu et al., both suffer from Denning-Sacco attack [7], off-line password guessing and stolen-verifier attacks. Moreover, Yoon et al. designed another improved scheme for SIP authentication [37]. However, according to Liu and Koenig [21], Yoon et al.’s scheme is prey to off-line password guessing attack. In 2009, Tsai [30] proposed a lightweight SIP authentication scheme based on nonce. Subsequently, Lee [20] identified password guessing and insider attacks on Tsai’s scheme. In 2013, Arshad et al. [2] demonstrated that Tsai’s scheme [30] does not resist stolen verifier, off-line password guessing, and Denning-Sacco attacks and fails to provide perfect forward secrecy, key agreement, and known-key secrecy. Further, they presented their own SIP authentication and key agreement scheme [2] based on ECC. In 2012, He et al. [15], and later, in 2013, Tang et al. [29] and Pu et al. [25], independently showed that Arshad et al.’s scheme [2] is vulnerable to off-line password guessing attack. Additionally, they modified the Arshad et al.’s scheme in terms of improved proposals of SIP authentication schemes. In 2010, Yoo et al. [36] proposed an ECC-based SIP authentication scheme to overcome the weaknesses of Tsai et al.’s scheme. In 2012, Xie [32] identified off-line password guessing and stolen-verifier attacks on Yoo et al.’s scheme. In 2013, Farash and Attari [10] exhibited impersonation and off-line password guessing attacks on Xie’s scheme [32].

In 2013, Yeh et al. proposed an ECC-based SIP authentication scheme [34] to overcome faults in the contemporary SIP schemes. They claimed their scheme to be secure for applications demanding high security. However, we observe user impersonation attack and insecure password update in the scheme. Besides, their scheme requires one and half round-trip to accomplish the authentication process. In the same year, Zhang et al. [38] pondered that most of the proposed SIP authentication schemes require the server to store user’s verifier(s) in the database which makes these schemes prone to server spoofing, password guessing and stolen verifier attacks. Therefore, they proposed a new password-based SIP authenticated scheme [38] without the need of maintaining a verification table. They claimed their scheme to be free from many known attacks. In the same year, Irshad et al. [16] pointed out that in Zhang et al.’s scheme, the messages transmitted between the user and the server are not fresh and hence can be replayed. Irshad et al. also visualized that one and half round of the Zhang et al.’s scheme could be cut short to a single round. Thus, Irshad et al. proposed a SIP authentication scheme with single round-trip. Recently, Arshad and Nikooghadam [3] showed that in Irshad et al.’s scheme an insidious user of the system can impersonate some other user. Then, they proposed a SIP authentication and key agreement scheme based on Irshad et al.’s scheme. They claimed that their scheme not only provides improved security, but is also quite efficient as compared to the previous SIP authentication schemes.

1.2 Our contributions

This research exposes the weaknesses of Irshad et al.’s [16] and Arshad and Nikooghadam’s [3] SIP authentication schemes for VoIP. We show that in addition to the attack mounted by Arshad and Nikooghadam, Irshad et al.’s scheme also suffers from other security pitfalls. We explain that in Irshad et al.’s scheme, the login-authentication phase is erroneous and a secret key of the server can be recovered by any legal user of the system. Further, a sensitive value generated from server’s second secret key and which is common for all registered users is not secure in the scheme. These weaknesses pave the way to other vulnerabilities like disclosure of user’s random key, password guessing, user impersonation and server spoofing attacks. Besides, we exhibit that in Arshad and Nikooghadam’s scheme, an adversary can spoof the legal server to cheat the user without requiring the user’s password or the server’s secret key. Further, the storage of users’ verifiers in server’s database makes the scheme open to the stolen verifier attack. In fact, both the schemes lack the attribute of mutual authentication. We observe that the scheme proposed by Arshad and Nikooghadam requires one and half round-trip to complete the authentication process which is contrary to the single round-trip in the original scheme by Irshad et al. To lift the security and to remove the design flaws of these schemes, we then propose a single round-trip SIP authentication scheme for VoIP using smart card, keeping the design originality of Irshad et al.’s scheme intact. We not only discuss conventionally the resistance of the proposed scheme to various attacks but also give formal security proof in random oracle. Further, we compare our scheme with some existent SIP authentication schemes to assess its efficiency. The overall analysis proves the utility of the scheme for SIP-services.

1.3 Arrangement of the paper

Here follows the layout of the remaining paper. Section 2 and 3 give review and cryptanalysis of Irshad et al.’s SIP authentication scheme respectively. Section 4 and 5 give review and cryptanalysis of Arshad and Nikooghadam’s SIP authentication scheme respectively. Our proposed SIP authentication is presented in Section 6. Section 7 and 8 respectively focus on the formal and conventional security analysis of the proposed scheme. Section 9 shows the comparisons of the proposed scheme with some related SIP authentication schemes. Finally, the paper is ended with conclusion in Section 10.

1.4 Useful preliminaries

1.4.1 Elliptic Curve Cryptography (ECC)

Here, we give a brief background of an elliptic curve and its computational problems [4, 14, 18, 23, 24]. In elliptic curve cryptography (ECC), the elliptic curve equation is given by E p (f, g) : y 2 = x 3 + ax + b (mod p) over a finite field F p of prime order p > 3, where, f, g∈ F p and 4a 3 + 27b 2 ≠ 0 (mod p). Given an integer r∈F p * and a point P∈E p (f, g), the elliptic curve point multiplication r∙P over E p (f, g) is defined as r∙P = P + P +… + P (r times). Normally, the following two intractable problems form the basis of the security of ECC:

  • Elliptic Curve Discrete Logarithm Problem (ECDLP): For two given points P and Q over E p (f, g), ECDLP says to find out an integer r∈F p * when Q = r∙P.

  • Elliptic Curve Diffie-Hellman Problem (ECDHP): For three given points P, r∙P, and s∙P over E p (f, g) for r, s ∈F p *, ECDHP says to find out the point r∙s∙P over E p (f, g).

1.4.2 Notations with their description

The notations and their description used throughout the paper are listed in Table 1.

Table 1 The notations with description useful throughout the paper
Full size table

2 Review of Irshad et al.’s scheme

The details of four phases, system setup phase, registration phase, login-authentication phase and password update phase of Irshad et al.’s scheme are reviewed as follows:

2.1 System setup phase

This phase is about defining the different parameters meant for public use or user’s interface with the system. The server S does the following preparations to setup the system. S chooses an elliptic curve equation E p (f, g) of order n and P as a base point, from security view point n and p are chosen to be two large prime numbers with high entropy. S randomly picks d 1, d 2 ∈ Z p * as two secret keys and computes the public key P ub = d 2 P. S chooses three one-way hash functions h(.) : {0,1}* → {0,1}k, h 1(.) : G × {0,1}* × {0,1}* → {0,1} k, h 2(.) : G × G× {0,1}* × {0,1}* → {0,1} k. Finally, S publishes the information {E p (f, g), P, P ub , h(.), h 1(.), h 2(.)} in a public directory.

2.2 Registration phase

In this phase, S validates U over a secure channel. The steps undergone by U and S for the purpose of registration are as listed below:

  1. 1)

    On affirmative verification at S, U randomly generates a key e, chooses a random integer i r  ∈ Z p * and her password Pw. Next, she computes h(Pw||i r ) and submits {(h(Pw||i r )||username), e} to S.

  2. 2)

    In response to the received information {(h(Pw||i r )||username), e} from U, S computes R = h(h(Pw||i r )||username) d 2 −1 P and I = (e||username)d 1 −1. S stores R in a smart card SC and securely provides SC = {R} & I to U.

  3. 3)

    U stores i r in SC and at the closing of the registration phase U owns SC = {R, i r } & I.

2.3 Login-authentication phase

When U wishes to log into S, she inserts her SC into a smart card reader and inputs her username and Pw. Subsequently, the procedure that takes place between U and S for the purpose of mutual authentication and session key agreement is listed below as a series of steps:

  1. 1)

    U selects a random integer a ∈ Z p * and acquires the current timestamp T l . Then U computes x = aR, X = ah(h(Pw||i r )||username)P ub and m u = MAC e (T l ). Next, it sends REQUEST = {realm, username, x, X, I, T l , h(m u )} to S over a public channel. Here MAC e is message authentication code with e as key, also known as keyed hash function since it takes as input a secret key and an a message of arbitrary length.

  2. 2)

    On receiving the REQUEST, S obtains e′ = d 1 I, computes m u ′ = MAC e′(T l ) and checks if h(m u ) ‗? h(m u ′). The success of this verification validates the freshness of T l and the REQUEST. After that, S computes X′ = d 2 2(x) and checks if X ‗? X′. On the success of this verification, it randomly selects two integers r, b ∈ Z p * and computes the following values: y = bP, K = bd 2 x, m s = MAC e′(T l + 1), sk = h 1(K||r||m s ||username) and Auth s = h 2(K||X′||r||sk). Finally, S answers back with RESPONSE = {realm, r, y, Auth s } to U.

  3. 3)

    On receiving the RESPONSE, U computes K′ = ah(h(Pw||i r )||username)y, m s ′ = MAC e (T l + 1), sk = h 1(K′||r|| m s ′||username) and checks if Auth s ‗? h 2(K′||h(h(Pw||i r )||username)aP ub ||r||sk). The success of this verification validates S and U can rely on sk = h 1(K′||r||m s ′||username) as the session key to establish confidential communication with S till next login.

2.4 Password update phase

This phase is initiated using a recent session key sk. The details of this phase are as given in the following steps:

  1. 1)

    U chooses a new random integer i rnew ∈ Z p * and a new password Pw new . Next, she computes h(Pw new ||i rnew ) and acquires the current timestamp T p . Then, U performs the encryption V = E sk (username||T p ||h(Pw new ||i rnew )||h(username||T p ||h(Pw new ||i rnew ))) using sk and submits PU-REQUEST = {V, T p } as a password update request to S.

  2. 2)

    On obtaining PU-REQUEST from U, S decrypts V. Next, S checks the validity of the message by computing the fresh value h(username||T p ||h(Pw new ||i rnew )) and comparing it with the received value recovered from V. For success of this verification, S computes the new parameter R new = h(h(Pw new ||i rnew )||username)d 2 −1 P and performs the encryption W = E sk (R new ||h(username|| T p + 1|| R new )). S answers back with PU-RESPONSE = {W} to U.

  3. 3)

    On obtaining PU-RESPONSE from S, U decrypts W and confirms its validity by computing the fresh value h(username|| T p + 1|| R new ) and comparing it with the received value recovered from W. For success of this verification, U replaces R and i r in her SC with R new and i rnew respectively.

3 Cryptanalysis of Irshad et al.’s scheme

3.1 Error in login-authentication phase

During the registration phase, S provides SC = {R} & I = (e||username)d 1 −1 to U. Then, U stores the random integer i r in SC owns SC = {R, i r } & I. At the time of login, U computes m u = MAC e (T l ) using her random key e and sends REQUEST = {realm, username, x, X, I, T l , h(m u )} containing I to S. Our concern is that the values {e, I} are neither stored in the memory of SC nor these are like password which can be easily memorized by the user. Besides, if SC = {R, i r , I}, U cannot obtain e out of I as it requires the knowledge of S’s secret key d 1. Consequently, U cannot initiate the login unless both e and I are stored in SC.

3.2 Server’s first secret is at risk

During the registration phase, U submits her registration request containing a randomly generated key e to S. Then S computes I = (e||username)d 1 −1 and provides it to U. The value I contains U’s key e protected with S’s secret key d 1. Since U knows her key e and username, she can obtain d 1 −1 from I as d 1 −1 = (e||username)−1 I and further obtains the secret key d 1 of S by computing (d 1 −1) −1. In this way, any legal user can get hold of the secret key d 1 of S and can use it to impersonate the other users as will be explained in Subsections 3.6.

3.3 Secret value generated from server’s second secret is at risk

It is observable that the value d 2 −1 P containing S’s secret key d 2 is used to compute the parameter R = h(h(Pw||i r )||username)d 2 −1 P for U and similar parameters for each of the registered user. Here, we show that any legal user can gain this sensitive value by undergoing password update phase. U chooses a new random integer i rnew ∈ Z p *, a new password Pw new and submits her password update request to S. In response, U receives the new parameter R new = h(h(Pw new ||i rnew )||username)d 2 −1 P from S. Then she can obtain d 2 −1 P from R new as (h(h(Pw new ||i rnew )||username)) −1 R new . In this manner, any legal user can get hold of d 2 −1 P, which is common for all users, without deploying any expensive method. Having d 2 −1 P in hand, one can mount password guessing and user impersonation threats on Irshad et al.’s scheme as the discussion follows in Subsections 3.5 and 3.6 respectively.

3.4 Attack on user’s random key

We have shown in Subsection 3.2 that an adversary A d , who is a malicious legal user, can obtain the value d 1 which is a secret key of S. Then he can obtain the value I = (e||username)d 1 −1 from an intercepted REQUEST = {realm, username, x, X, I, T l , h(m u )} of U. Using d 1, she can gain the random key e of U as (e||username) = d 1 I. Thus, A d can own the random secret key of any user of the system.

3.5 Password guessing attack

Suppose that the smart card of U is lost or stolen and an adversary A d , who is actually a malicious legal user, gains the information {R, i r , etc.} from its memory using techniques such as power consumption or side channel attacks [19, 22, 35]. Then A d can obtain the secret d 2 −1 P using his own smart card (as discussed in subsection 3.3) to guess the password of U. A d guesses Pw * as a possible password of U to compute R * = h(h(Pw *||i r )||username) d 2 −1 P, where username of U is on easy access from some previously intercepted U’s REQUEST. A d verifies if R ‗? R *, the success of this verification implies the correctness of the guessed value Pw *, else, A d repeats the computation and verification process with some another guess. Thus, password guessing is possible in Irshad et al.’s scheme.

3.6 User impersonation attack

In order to impersonate U, a malicious legal user A d first of all obtains the secrets d 1 −1 and d 2 −1 P using her own smart card (as discussed in subsections 3.2 and 3.3) and then continues further in the following manner:

  1. 1)

    A d selects a random key e A to compute I A = (e A||username u )d 1 −1. Then she selects a random integer a A ∈ Z p * and computes x A = a A d 2 −1 P, X A = a A P ub and m A = MAC eA (T A ) using the current value of the timestamp T A . Next, it sends REQUEST = {realm, username u , x A, X A, I A, T A , h(m A )} to S over a public channel.

  2. 2)

    On receiving the REQUEST, S obtains (e A)′ = d 1 I, computes m A ′ = MAC (eA)′(T A ) and checks if h(m A ) ‗? h(m A ′). Clearly, this verification will hold and the timestamp T A will pass the freshness test. Afterwards, S computes (X A)′ = d 2 2(x A) and checks if X A ‗? (X A)′. Clearly, this verification, will hold since (X A)′ = d 2 2(x A) = d 2 2(a A d 2 −1 P) = a A d 2 P = a A P ub = X A. Consequently, S randomly selects two integers r, b ∈ Z p * and computes the following values: y = bP, K A = bd 2 x A, m s = MAC (eA)′(T A + 1), sk = h 1(K||r||m s ||username u ) and Auth s = h 2(K||(X A)′||r||sk). Finally, S answers back with RESPONSE A = (realm, r, y, Auth s ) to U.

  3. 3)

    On receiving the RESPONSE A , A d computes K A = a A y, m s ′ = MAC eA (T A + 1), sk = h 1(K A||r||m s ′||username u ) and checks if Auth s ‗? h 2(K A||X A||r||sk). The success of this verification validates S and ensures the correctness of the computed session key sk. Now, A d can communicate with S using sk.

Thus, A d impersonates U to cheat S whereas S believes that he is communicating with the registered user U. It is noticeable that A d can apply a forgery attack by using an arbitrary username username A instead of username u in the above process. We can see that the forgery process goes on smoothly if we replace username u with username A in the whole process and S has no way to differentiate a registered user from a non- registered user.

3.7 Server spoofing attack

Here, we show the vulnerability of Irshad et al.’s scheme to the server spoofing attack. We show how a malicious legal user A d , after obtaining the secret d 1 of S using her own smart card (as discussed in subsections 3.2), can prove itself the legal server to the user. For this, A d performs the following steps:

  1. 1)

    A d intercepts a current login request REQUEST = {realm, username, x, X, I, T l , h(m u )} sent by U to S.

  2. 2)

    A d obtains (e A)′ = d 1 I = e and randomly selects two integers r A, b A ∈ Z p *. Then, she computes y A = b A P ub , K A = b A X, m A = MAC (eA)′(T l + 1), sk A = h 1(K A||r A||m A ||username) and Auth A = h 2(K A||X||r A||sk A ). A d answers back with RESPONSE A = (realm, r A, y A, Auth A ) to U.

  3. 3)

    On receiving the RESPONSE A , U computes K = ah(h(Pw||i r )||username)y A, m A ′ = MAC eA (T l + 1), sk = h 1(K||r A||m A ′||username) and checks if Auth A ‗? h 2(K||X||r A||sk A ). Clearly, this verification will hold since K = ah(h(Pw||i r )||username)y A = ah(h(Pw||i r )||username)b A P ub = b A ah(h(Pw||i r )||username)P ub == b A X = K A. This verification not only ensures the freshness of the extension T l + 1 of the timestamp T l but also makes U to believe that sk computed by her is equal to the session key sk A computed at the server side.

In this way, U is contented that the received RESPONSE A is fresh (free from any replay) and originated from the legal server. Moreover, A d shares a confidential communication channel with the user by means of the established session key.

3.8 Mutual authentication attack

As discussed in Sections 3.6 and 3.7, an adversary A d who is a malicious legal user can impersonate the user and can spoof the server, therefore mutual authentication is not achieved in the Irshad et al.’s scheme.

4 Review of Arshad et al.’s scheme

The detail of four phases, system setup phase, registration phase, login-authentication phase and password update phase of Arshad and Nikooghadam’s scheme is reviewed as follows:

4.1 System setup phase

This phase is exactly same as in Irshad et al.’s scheme except that S maintains only one secret key d ∈ Z p * with P ub = dP as the corresponding public key. S chooses a one-way hash functions h(.) : {0,1}* → {0,1}k. Finally, S publishes the information {E p (f, g), n, P, P ub , h(.)} in a public directory. We avoid mentioning the rest of the similar details to avoid the redundancy of the text.

4.2 Registration phase

In this phase, S validates U over a secure channel. The steps undergone by U and S for the purpose of registration are as listed below:

  1. 1)

    U chooses a random integer i r ∈ Z p * and her password Pw. She computes v i = h(ID||Pw||i r ) and stores i r in her memory device (portable HDDs, USB stick, etc.), where ID denotes the identity of U. Next, she submits {ID, v i } to S.

  2. 2)

    After receiving the information {ID, v i } from U, S checks if ID already exists in its database or not. If ID is absent in the database then S computes R = h(ID||d) ⊕ v i and stores {ID, R} in its database.

4.3 Login-authentication phase

When U wishes to log into S, the following process takes place between U and S for the purpose of mutual authentication and session key agreement:

  1. 1)

    U chooses a random integer a∈Z p * and computes x = aP ub = adP. Then, it sends REQUEST = {ID, x} to S over a public channel.

  2. 2)

    On receiving REQUEST, S checks its database for the existence of ID. S terminates the session in case ID is absent in database. Otherwise, S randomly selects an integer b ∈ Z p *and computes y = bP, K = bd −1 x = baP and m s = h(ID||y||K). Then, S answers back with RESPONSE S = {realm, y, m s } to U.

  3. 3)

    On receiving RESPONSE S , U computes K′ = ay = abP and checks if m s ′ ‗? h(ID||y||K′). The success of this verification authenticates S. Thereby, U retrieves i r from her memory device to compute v i = h(ID||Pw||i r ). Next, she computes m u = h(ID||y||realm||K′||v i ), the session key sk = h(ID||y||K′||realm) and replies with RESPONSE U = {ID, realm, m u } to S.

  4. 4)

    On receiving RESPONSE U , S computes v i = R ⊕ h(ID||d) and checks if m u ′ ‗? h(ID||y||realm||K||v i ). The success of this verification authenticates U and thereby S computes the session key sk = h(ID||y||K||realm).

4.4 Password update phase

This phase is initiated using a recent session key sk. The details of this phase are as given in the following steps:

  1. 1)

    U chooses a new random integer i rnew ∈ Z p * and a new password Pw new . She retrieves i r from her memory device, to computes v inew = h(ID||Pw new ||i rnew ). Next, it computes z = h(ID||Pw||i r ) ⊕ v inew = v i ⊕ v inew , Z = z ⊕ h(ID||sk) = v i ⊕ v inew ⊕ h(ID||sk), V = h(ID||v inew ||sk||v i ) and submits PU-REQUEST = {ID, Z, V} as a password update request to S.

  2. 2)

    On obtaining PU-REQUEST from U, S computes v i = R ⊕ h(ID||d), v inew = Z ⊕ v i ⊕ h(ID||sk). Next, S checks the validity of the message by computing the fresh value h(ID||v inew ||sk||v i ) and comparing it with the received value V. For success of this verification, S computes the new parameter R new = R ⊕ z = h(ID||d) ⊕ h(ID||Pw||i r ) ⊕ h(ID||Pw||i r ) ⊕ h(ID||Pw new ||i rnew ) = h(ID||d) ⊕ h(ID||Pw new ||i rnew ) and replaces v i with v inew in its database. S answers back with PU-RESPONSE = {h(ID||v i ||accept||v inew ||sk)} to U.

  3. 3)

    On obtaining PU-RESPONSE from S, U checks the validity of the message by computing the fresh value h(ID||v i ||accept||v inew ||sk) and comparing it with the received value. For success of this verification, U replaces i r with i rnew in her memory device.

5 Cryptanalysis of Arshad et al.’s scheme

5.1 Server spoofing attack

Now, we show that Arshad et al.’s scheme is susceptible to an impersonation attack as an adversary A d can spoof the legal server to cheat any registered user of the system. Here follows the description of the attack:

  1. 1)

    When U wishes to log into S, she sends REQUEST = {ID, x} to S, where x = aP ub = adP with a as a random integer belonging to Z p *.

  2. 2)

    A d intercepts and blocks the REQUEST, and chooses a random integer b A ∈ Z p *. Computes y A = b A P ub = b A dP, K A = b A x = b A aP ub = b A adP and m A = h(ID||y A ||K A ). Sends RESPONSE A = {realm, y A , m A } to U.

  3. 3)

    On receiving RESPONSE A , U computes K A ′ = ay A = ab A P ub = ab A dP and checks if m A ′ ‗? h(ID||y A ||K A ′). Clearly, this verification will hold by virtue of the equality of K A ′ and K A . Thus, U believes that the received RESPONSE A originated from the legal S and proceeds further. Retrieves i r from her memory device to compute v i = h(ID||Pw||i r ). Next, she computes m uA = h(ID||y A ||realm||K A ′||v i ), the session key sk A = h(ID||y A ||K A ′||realm) and replies with RESPONSE UA = {ID, realm, m A } to S.

  4. 4)

    On receiving RESPONSE UA , A d computes the session key sk = h(ID||y A ||K A ||realm) to communicate with U.

Consequently, U believes that she is connected with the legal server whereas it is the adversary A d at the opposite end who is not only connected with U but has also established a secure communication channel with U. The noticeable thing about this attack is that for this the adversary A d neither requires U’s smart card or password nor needs S’s secret key d.

5.2 Stolen verifier attack

S stores {ID, R} in its database, where R = h(ID||d) ⊕ v i = h(ID||d) ⊕ h(ID||Pw||i r ) is used by S during the authentication to verify U. Assume the leakage of S’s secret key d, in such situation, an adversary A d can obtain U’s verifier h(ID||Pw||i r ) from R as h(ID||Pw||i r ) = R ⊕ h(ID||d). Further, if A d happens to access the memory device of U then he can extract the random integer i r from it to guess U’s password. He guess Pw g as U’s possible password and computes h(ID||Pw g ||i r ). Compares the two values h(ID||Pw||i r ) and h(ID||Pw g ||i r ) of the verifier, the equality yields the correct password otherwise he tries with another guess. He can keep guessing continue until success is achieved.

5.3 Lacks mutual authentication

As described in section 5.1, an adversary A d can cheat a legal user by spoofing as the legal server. Therefore, mutual authentication is shattered in Arshad and Nikooghadam’s scheme.

6 The proposed scheme

Here, we propose our improved scheme to conquer the weaknesses of Irshad et al.’s scheme. Similar to Irshad et al.’s scheme, our scheme is also divided into four phases as listed and detailed below along with figure:

6.1 System setup phase

This phase is exactly same as that of Irshad et al.’s scheme except that S maintains only one secret key d ∈ Z p * with P ub = dP as the corresponding public key. We avoid mentioning the rest of the similar details to avoid the redundancy.

6.2 Registration phase

In this phase, S validates U over a secure channel. The steps undergone by U and S for the purpose of registration are as listed below:

  1. 1)

    On affirmative verification at S, U randomly generates a key e, chooses a random integer i r ∈ Z p * and her password Pw. Next, she computes h(Pw) + i r and submits {username, h(Pw) + i r , e} to S.

  2. 2)

    In response to the received information {username, h(Pw) + i r , e} from U, S computes R′ = (h(Pw) + i r ) + h(username||d) and I = (e + h(d||username)). S stores I in a smart card SC and securely provides SC = {I} & R′ to U.

  3. 3)

    U computes R = R′ − i r = h(Pw) + h(username||d), Z = (e + h(username||Pw)) and stores them in her SC. At the closing of the registration phase, U owns SC = {I, R, Z}.

6.3 Login-authentication phase

When U wishes to log into S, she inserts her SC into a smart card reader and inputs her username and Pw. Subsequently, the procedure that takes place between U and S for the purpose of mutual authentication and session key agreement is listed below in a series of steps:

  1. 1)

    U selects a random integer a∈Z p * and acquires the current timestamp T l . Then U computes x = aP, X = a(R− h(Pw))P ub = ah(username||d)dP, e = Z− h(username||Pw) and m u = h(username||X||e||T l ). Next, it sends REQUEST = {realm, username, x, I, T l , m u } to S over a public channel.

  2. 2)

    On receiving the REQUEST, S obtains e′ = I − h(d||username), computes X′ = xh(username||d)d, m u ′ = h(username||X′||e′||T l ) and checks if m u ‗? m u ′. The success of this verification validates the freshness of T l , freshness of REQUEST and hence authenticates U. S randomly selects an integer b ∈ Z p * and computes the following values: y = bP, K = bx = abP, sk = h 1(K||X′||e′||username) and Auth s = h 2(K||sk||T l + 1). Finally, S answers back with RESPONSE = (realm, y, Auth s ) to U.

  3. 3)

    On receiving the RESPONSE, U computes K′ = ay = abP, sk = h 1(K′||X||e||username) and checks if Auth s ‗? h 2(K′||sk||T l + 1). The success of this verification validates S and U can rely on sk = h 1(K′||X||e||username) as the session key to establish confidential communication with S till next login.

6.4 Password update phase

This phase is initiated using a recently agreed session key sk immediately after the session key is establsihed. The details of this phase are as follows:

  1. 1)

    U chooses a new random integer i rnew ∈ Z p * and a new password Pw new . Next, it computes h(Pw new ) + i rnew and acquires the current timestamp T p . Then, U performs the encryption V = E sk (username||T p ||h(Pw new ) + i rnew ||h(username||T p ||h(Pw new ) + i rnew )) using sk and submits PU-REQUEST = {V, T p } as a password update request to S.

  2. 2)

    On obtaining PU-REQUEST from U, S decrypts V. Next, S checks the validity of the message by computing the fresh value h(username||T p ||h(Pw new ) + i rnew ) and comparing it with the received value recovered from V. For success of this verification, S computes the new parameter (R new )′ = (h(Pw new ) + i rnew ) + h(username||d) and performs the encryption W = E sk ((R new )′||h(username|| T p + 1||(R new )′)). S answers back with PU-RESPONSE = {W} to U.

  3. 3)

    On obtaining PU-RESPONSE from S, U decrypts W and confirms its validity by computing the fresh value h(username|| T p + 1||(R new )′) and comparing it with the received value recovered from W. For success of this verification, U computes R new = (R new )′ − i rnew = h(Pw new ) + h(username||d), Z new = Z − h(username||Pw) + h(username||Pw new ). Then U replaces R and Z in her SC with R new and Z new respectively.

7 Analysis of security properties of the proposed scheme

7.1 Secret key of the server is safe

During the registration phase, U submits her registration request containing a randomly generated key e to S. Then S computes R′ = (h(Pw) + i r ) + h(username||d), I = (e + h(d||username)) and provides SC = {I} & R′ to U. Although a malicious user can obtain h(username||d) from R′ as h(username||d) = R′ − (h(Pw) + i r ), he cannot obtain S’s secret key d from h(username||d) due to the one-way property of the hash function. Similar hindrance is posed by the value I for recovering d from it. Moreover, she needs to extract [19, 22, 35] I from her SC which is a costly method. Even though, an adversary A d can take I by intercepting a login request REQUEST = {realm, username, x, I, T l , m u } of U from the network, he cannot gain d from it without knowing U’s random secret key e and due to the one-way property of the hash function. In this way, neither a legal user nor an adversary can get hold of the secret key d of S.

7.2 Password guessing attack

Suppose that the smart card of U is lost or stolen and an adversary A d gains the information {I, R, Z} from its memory using techniques such as power consumption or side channel attacks [19, 22, 35]. Then A d has two choices, R & Z, for guessing U’s password. In order to guess user’s password from Z, A d requires the knowledge of U’s username and random secret key e. However, username can be taken from an intercepted login request; e is not obtainable by any means. On the other hand, guessing of Pw from R is not feasible as it additionally requires the knowledge of S’s secret key d. A d can take username from an intercepted login request and can guesses Pw *. Next, he computes e *← Z − h(username||Pw *), (h(d||username))* = I + e *. But, the value (h(d||username))* is of no help to verify the guessed Pw * from R = h(Pw) + h(username||d) as it contains h(username||d) which is different from h(d||username). Thus, password guessing is not possible in the proposed scheme.

7.3 User impersonation attack

In order to impersonate as U, A d should be able to compute a workable login request involving U’s specific secrets. A d cannot compute the correct value of X as he does not know S’s secret key d. A d cannot obtain e from I available in login request of U because it involves the secret key d of S. Further, he cannot obtain U’s random secret key e from her lost or stolen SC as it requires U’s password Pw. Thus, it is not possible to impersonate a legal user.

7.4 Server spoofing attack

To spoof the server, A d should be able to compute a valid RESPONSE in reply to a current REQUEST sent by U. For this purpose, A d requires S’s secret key d to compute X′ = xh(username||d)d, needs U’s random secret key e to compute sk = h 1(K||X′||e′||username) embedded in the authenticating value Auth s = h 2(K||sk||T l + 1). In the absence of d & e, A d cannot spoof the server.

7.5 Replay attack

The login request REQUEST = {realm, username, x, I, T l , m u } sent by U to S contains the fresh timestamp T l . The parameter m u = h(username||X||e||T l ) responsible for the verification of the REQUEST contains the timestamp T l . On obtaining the REQUEST, S computes e′ = I − h(d||username), X′ = xh(username||d)d, m u ′ = h(username||X′||e′||T l ) and checks if m u ‗? m u ′. The success of this verification validates the freshness of T l and ensures that the REQUEST has not been replayed. The response message RESPONSE = (realm, y, Auth s ) sent by S to U contains the extension T l + 1 of T l . The session key sk = h 1(K||X′||e′||username) is embedded in Auth s = h 2(K||sk||T l + 1) which is responsible for the verification of the RESPONSE = (realm, y, Auth s ). On obtaining the RESPONSE, U computes K′ = ay = abP, sk = h 1(K′||X||e||username) and checks if Auth s ‗? h 2(K′||sk||T l + 1). The success of this verification validates the freshness of T l +1 and ensures that the RESPONSE has not been replayed. Thus, the contribution of fresh timestamp and its extension in REQUEST and RESPONSE respectively, protects the scheme against replay attack.

7.6 Forward secrecy

Forward secrecy ensures the security of already established session keys even if long term secrets (user’s password or server’s secret key) of any of the communicating participants are compromised. If U’s password Pw or S’s secret key d or both are compromised, an adversary A d has to face the Elliptic Curve Discrete Logarithm Problem (ECDLP) to gain a or b from x = aP or y = bP respectively, otherwise, computation of K = bx = ay = abP is not feasible. Since the value of K = abP involved in the session key sk = h 1(K||X′||e′||username) = h 1(K′||X||e ||username) is independent of Pw and d, therefore, the proposed scheme provides strong forward secrecy.

7.7 Mutual authentication

The server S authenticates U by checking the freshness of T l and hence the validity of the received REQUEST = {realm, username, x, I, T l , m u } through the equivalence m u ‗? m u ′ after computing e′ = I−h(d||username), X′ = xh(username||d)d and m u ′ = h(username||X′||e′||T l ). On the other hand, U authenticates S by checking the freshness of the extension T l +1 of T l and hence the validity of received RESPONSE = (realm, y, Auth s ) through the equivalence Auth s ‗? h 2(K′||sk||T l + 1) after computing K′ = ay = abP, and sk = h 1(K′||X||e||username). Thus, both user and the server authenticate each other in the proposed scheme.

7.8 Insider attack

During registration phase, U submits h(Pw) + i r , where i r is a random integer chosen from Z p *. Thus, the insider of the system at the server has no knowledge of users’ passwords. Moreover, owing to the random choice of i r and the one-way property of hash function, he cannot reveal Pw from h(Pw) + i r . Therefore, insider attack is not applicable on the proposed scheme.

7.9 Stolen verifier attack

The server does not store any information of its registered users and completes the authentication process using the information possessed by it and received from the user. Therefore, an adversary A d has no way of stealing and misusing the information stored in some database at the server. Thus, the scheme is free from the stolen verifier attack.

7.10 Secure password update facility

To update her password, U inserts his smart card in a card reader to connect with the server. U uses the session key to communicate his encrypted password update request to S. In reply, S encrypts the parameters required to update the password with the same session key and transmits to U. An adversary A d cannot update the password of U using the lost/stolen smart card of U unless he knows the session key. Thus, the scheme provides a secure password update phase.

7.11 Denning-Sacco attack

In Denning-Sacco attack [7] an adversary A d attempts to guess the secret keys (such as server’s secret key or user’s password or a current session key) of any of the communicating participants from some previously disclosed session key. The proposed scheme utilizes the one-way hash function and ECC to compute the session key sk = h 1(K||X||e||username) = h 1(abP||ah(username||d)dP||e||username). Since sk is independent of the user’s password and server’s secret key is protected under the one-way of hash function, an attacker A d cannot obtain any secret key used in the protocol using a compromised previous session key. If A d tries to guess the value d from sk, he requires to possesses the random secret key e of the user along with the random values a and b. However, to reveal a and b from x = aP and y = bP respectively, A d has to face the intractable ECDLP. Therefore, the proposed scheme resists the Denning-Sacco attacks.

8 Formal security analysis of the proposed scheme

In this section, we show that our protocol is secure in the random oracle model. We start with the formal security model and the algorithm assumption that will be used in our proof.

8.1 Security model

In order to make our scheme resist the known attacks to the authentication protocols, we use the method of provable security. The security proof is based on the model proposed by Abdalla and Pointcheval [1]. The model that we use is as follows:

8.1.1 Participants

An authentication protocol Π runs in a network of a number of interconnected participants where each participant is either a client U \( \epsilon\ \mathcal{U} \) or a trusted server S ℱ. The set ℱ is assumed to involve only a single server for simplicity. Each of the participants may have several instances called oracles involved in distinct executions of the protocol Π. We refer to i-th instance of U (respectively S) in a session as Π i U (resp. Π j S ). Every instance Π i U (resp. Π j S ) has a partner ID pid i U (resp. pid j S ), a session ID sid i U (resp. sid j S ), a session key sk i U (resp. sk j S ). pid i U (resp. pid j S ) denotes the set of identities that are involved in this instance. sid i U (resp. sid j S ) denotes the flows that are sent and received by the instance Π i U (resp. Π i S ). An instance Π i U (resp. Π i S ) is said to be accepted if it holds a session key sk i U (resp. sk j S ), a session identifier sid i U (resp. sid j S ), and a partner identifier pid i U (resp. pid j S ). Two instances Π i U  and Π i S are considered partnered if and only if (i) both of them have accepted, (ii) pid i U  = pid j S , (iii) sid i U  = sid j S , (ii) sk i U  = sk j S .

8.1.2 Adversary model

The communication network is assumed to be fully controlled by an adversary \( \mathcal{A} \), which schedules and mediates the sessions among all the parties. The adversary \( \mathcal{A} \) is allowed to issue the following queries in any order:

  • Execute(Π i U , Π j S ): This query models passive attacks in which the attacker eavesdrops on honest executions among the client instance Π i U and trusted server instance Π j S . The output of this query consists of messages that were exchanged during the honest execution of the protocol Π.

  • SendClient(Π i U , m): The adversary makes this query to intercept a message and then modify it, create a new one, or simply forward it to the client instance Π i U . The output of this query is the message that the client instance Π i U would generate upon receipt of message m . Additionally, the adversary is allowed to initiate the protocol by invoking SendClient(Π i U , start).

  • SendServer(Π i U , m): This query models an active attack against a server. The adversary makes this query to obtain the message that the server instance Π j S would generate on receipt of the message m.

  • Reveal(Π i U ): This query models the known session key attack. The adversary makes this query to obtain the session key of the instance Π i U .

  • Corrupt(U): This query returns to the adversary the long-lived key Pw U for participant U.

  • Test(Π i U ): Only one query of this form is allowed to be made by the adversary to a fresh oracle. To respond to this query, a random bit bϵ{0,1} is selected. If b = 1, then the session key held by Π i U is returned. Otherwise, a uniformly chosen random value is returned.

8.1.3 Fresh oracle

An oracle Π i U is called fresh if and only if the following conditions hold: (i) Π i U has accepted, and (ii) Π i U or its partner (if exists) has not been asked a Reveal query after their acceptance.

8.1.4 Protocol security

The security of an authentication protocol Π is modeled by the game (Π, \( \mathcal{A} \)). When playing this game, the adversary \( \mathcal{A} \) can make many queries mentioned earlier to Π i U and Π j S . If \( \mathcal{A} \) asks a single query, Test(Π i U ), where Π i U has accepted and is fresh, then \( \mathcal{A} \) outputs a single bit b′. The aim of \( \mathcal{A} \) is correctly guessing the bit b in the test session. More precisely, we define the advantage of \( \mathcal{A} \) as follows:

$$ Ad{v}_{\varPi, D}\left(\mathcal{A}\right)=\left|2 Pr\left[b^{\prime }=b\right]-1\right| $$

The protocol Π is said to be secure if \( Ad{v}_{\varPi,\ D}\left(\mathcal{A}\right) \) is negligible.

8.2 Computational assumption

We define the Decisional Diffie-Hellman (DDH) assumption which we use in the security proof of our scheme.

Definition 1

The DDH assumption can be precisely defined by two experiments, Exp ddh − real P,p (W) and Exp ddh − rand P,p (W). An adversary W is provided with uP, vP and uvP in the experiment Exp ddh − real P,p (W), and uP, vP and wP in the experiment Exp ddh − rand P,p (W), where u, v and w are drawn at random from Z p *. Define the advantage of W in violating the DDH assumption, Adv ddh P,p (W), as follows:

$$ Ad{v}_{P,p}^{ddh}(W)= \max \left\{\left| Pr\left[ Ex{p}_{P,p}^{ddh- real}(W)=1\right]- Pr\left[ Ex{p}_{P,p}^{ddh- rand}(W)=1\right]\right|\right\} $$

8.3 Security proof

Theorem 1

Let D be a uniformly distributed dictionary of passible passwords with size |D|. Let Π describes the improved authentication protocol defined in Fig. 1. Suppose that DDH assumption holds, Then,

$$ Ad{\upsilon}_{\varPi, D}\left(\mathcal{A}\right)\le \frac{q_h^2+{q}_{h1}^2+{q}_{h2}^2}{2^k}+\frac{{\left({q}_s+{q}_e\right)}^2}{p^2}+2{q}_e\cdot Ad{\upsilon}_{P,p}^{ddh}(W)+2 \max \left\{\frac{q_{h1}}{2^k},\frac{q_s}{\left|D\right|}\right\}, $$

where qs denotes the number of Send queries; qe denotes the number of Execute queries; qh, qh1 and qh2 denote the number of hash queries to h, h1 and h2, respectively.

Fig. 1
figure 1

The proposed scheme

Full size image

Proof

This proof consists of a sequence of hybrid games, starting at the real attack G 0 and ending up at game G 4 where the adversary has no advantage. For each game G i (0 ≤ i ≤ 4), we define Succ i as the event that \( \mathcal{A} \) correctly guesses the bit b in the test session.

  • Game G 0: This game is the real protocol, in the random-oracle model. In this game, all the instances of U and the trusted server S are modeled as the real execution in the random oracle. By definition of event Succ i , which means that the adversary correctly guesses the bit b involved in the Test-query, we have

    $$ Ad{v}_{\varPi,\ D}\left(\mathcal{A}\right) = 2\left| Pr\left[Suc{c}_0\right]-\frac{1}{2}\right| $$
    (1)

  • Game G 1 : This game is as the same as the game G 0 except that we simulate the hash oracles h, h 1 and h 2 as usual by maintaining hash lists h List , h 1List and h 2List with entries of the form (Inp, Outp). On hash query for which there exists a record (Inp, Outp) in the hash list, return Outp. Otherwise, randomly choose Outp ϵ {0, 1}k, send it to \( \mathcal{A} \) and store the new tuple (Inp, Outp) into the hash list. We also simulate all the instances, as the real players would do, for the Send-query and for the Execute, SendClient, SendServer, Reveal, Corrupt and Test queries. From the viewpoint of the adversary, we easily see that the game is perfectly indistinguishable from the real attack. Hence

    $$ Pr\left[Suc{c}_1\right]= Pr\left[Suc{c}_0\right] $$
    (2)

  • Game G 2 : In this game, we simulate all the oracles in game G 1, except we cancel the game in which some collisions appear on the partial transcripts (x,y) and on hash values. According to the birthday paradox, the probability of collisions in output of hash oracles are at most q 2 h /2k + 1, q 2 h1 /2k + 1 and q 2 h2 /2k + 1 where q h , q h1 and q h2 denote the maximum number of hash queries. Similarly, the probability of collisions in the transcripts is at most (q s  + q e )2/2p 2, where q s represents the number of queries to the SendClient and SendServer oracles and q e represents the number of queries to the Execute oracle. So we have

    $$ Pr\left[Suc{c}_2\right]- Pr\left[Suc{c}_1\right]\le \frac{q_h^2+{q}_{h1}^2+{q}_{h2}^2}{2^{k+1}}+\frac{{\left({q}_s+{q}_e\right)}^2}{2{p}^2} $$
    (3)

  • Game G 3: In this game, we consider the probability of the attacker forging all hash results without hash queries. We divide the game to two cases:

    • Case 1: To forge the message {realm, username, x, I, m u }, h(Pw), h(username||Pw) and h(username||X||e||T l ) should be queried. The probability for h(username||X||e||T l ) is \( \frac{q_s}{2^k} \), while the other two are \( \frac{q_h}{2^k} \).

    • Case 2: To forge the message{realm, y, Auth s }, sk = h 1(K||X′||e′||username) and Auth s = h 2(K||sk||T l + 1) should be asked. The probability for the former is \( \frac{q_{h1}}{2^k} \) and for the latter is \( \frac{q_s}{2^k} \) since Auth s is transmitted as part of the message.

    So, it can be easily seen that this game is perfectly indistinguishable from the previous game G 2. Hence,

    $$ \left| Pr\left[Suc{c}_3\right]- Pr\left[Suc{c}_2\right]\right|\le \frac{2{q}_h+{q}_{h1}+2{q}_s}{2^k} $$
    (4)

  • Game G 4: In this game, we consider that the adversary can ask the random oracles. Also we assume \( \mathcal{A} \) can solve CDH problem with the advantage Adv cdh P,p (t).Two cases can be divided to analyze this game:

    • Case 1: It is the online password guessing attack. Since the passwords are retrieved from D and there are q s times for the attacker to try, the probability for this case is \( \frac{q_s}{\left|D\right|} \).

    • Case 2: It is the off-line password guessing attack. \( \mathcal{A} \) should query the h1 query with asking K and that denotes the adversary breaks the CDH problem. We can find K by the bound \( \frac{1}{q_{h1}} \) . \( \mathcal{A} \) can use two ways to finish that attack.

      • SubCase 1 : The first is querying Execute(Π i U , Π j S ). Since there are 6 scalar multiplications in one Execute process, the probability for this subcase is q h1 Adv cdh P,p (t + 6q e t em ).

      • SubCase 2: The second is querying Send queries successively. Since there are 3 scalar multiplications at most in one Send query, the probability for this subCase is q h1 Adv cdh P,p (t + 3q s t em )

        So we can see that Game G4 is indistinguishable from G3, and

        $$ \begin{array}{c}\hfill \left| \Pr \left[{\mathrm{Succ}}_4\right]- \Pr \left[{\mathrm{Succ}}_3\right]\right|\le \frac{q_s}{\left|D\right|}+{q}_{h1} Ad{v}_{P,p}^{cdh}\left(t+6{q}_e{t_e}_m\right)+{q}_{h1} Ad{v}_{\left(P,p\right)}^{cdh}dh\left(t+3{q}_s{t_e}_m\right)\hfill \\ {}\hfill \le \frac{q_s}{\left|D\right|} + 2{q}_{h1} Ad{v}_{P,p}^{cdh}\left(t+\left(6{q}_e+3{q}_s\right){t}_{em}\right)\hfill \end{array} $$
        (5)

  • Game G 5 : In this game, we consider the forward security. According to the notion of Fresh, Corrupt queries can only be asked after Test query. So we use the old games. Like the SubCase 2 of Game G4, the probability for we find x,y, K in the same session is bounded by \( \frac{1}{{\left({q}_s+{q}_e\right)}^2} \). We have

    $$ \left| \Pr \left[{\mathrm{Succ}}_5\right]- \Pr \left[{\mathrm{Succ}}_4\right]\right|\le 2{q}_{h1}{\left({q}_s+{q}_e\right)}^2 Ad{v}_{P,p}^{cdh}\left(t+\left(6{q}_e+3{q}_s\right){t}_{em}\right) $$
    (6)

    \( \mathcal{A} \) has no advantage in guessing b and Pr[Succ5] = 1/2. Combining the above games, the theorem can be obtained.

9 Formal verification with Proverif

We give the formal verification of our scheme via the popular tool Proverif. Following codes can be checked via the reference (http://proverif.rocq.inria.fr/index.php)

(*--------channels----------*)

free ch: channel. (*public channal*)

free sch: channel [private]. (*private channel*)

(*-------shared keys--------*)

free sku: bitstring [private].(*the user’s session key*)

free sks: bitstring [private]. (*the server’s session key*)

(*------S’s secret key------*)

free d:bitstring [private].

(*-----constants------------*)

free username:bitstring.

free PW:bitstring [private].

const P:bitstring. (*the base point*)

const realm: bitstring.

const one: bitstring. (*for replacing 1 in the authentication process*)

table t(bitstring). (*table stored in S for auditing U*)

(*-------functions----------*)

fun h(bitstring):bitstring. (*hash function*)

fun h1(bitstring):bitstring. (*hash function*)

fun h2(bitstring):bitstring. (*hash function*)

fun mul(bitstring,bitstring):bitstring. (*scalar multiplication*)

fun add(bitstring,bitstring):bitstring. (*addition*)

fun sub(bitstring,bitstring):bitstring. (*substraction*)

fun con(bitstring,bitstring):bitstring. (*string concatenation*)

(*------equations-----------*)

equation for all m:bitstring,n:bitstring; mul(m,(n,P)) = mul(n,(m,P)).

equation for all m:bitstring,n:bitstring; sub(add(m,n),n) = m.

(*----------aims for verification---------*)

query attacker(sku).

query attacker(sks).

query id:bitstring; inj-event(UserAuth(id))==>inj-event(UserStart(id)).

(*-----------event----------*)

event UserStart(bitstring). (*User starts authentication*)

event UserAuth(bitstring). (*User is authenticated*)

(*------User’s process------*)

let User=

new se:bitstring;

new ir:bitstring;

out(sch,(username,add(h(PW),ir),se));

in(sch,(rI:bitstring,rR’:bitstring,Pub:bitstring));

let R = sub(rR’,ir) in

let Z = add(se,h(con(username,PW))) in

!

(

event UserStart(username);

new a:bitstring;

new Tl: bitstring;

let x = mul(a,P) in

let X = mul(a,mul(sub(R,h(PW)),Pub)) in

let e = sub(Z, h(con(username,PW))) in

let mu = h(con(con(con(username,X),e),Tl)) in

let Request = (realm,username,x,rI,Tl,mu) in

out(ch,Request);

in (ch,(rrealm:bitstring,ry:bitstring,rAuths:bitstring));

let K’ = mul(a,ry) in

let sku = h1(con(con(con(K’,X), e), username)) in

if rAuths = h2(con(con(K’,sku),add(Tl,one))) then

0

).

(*------S’s process-------*)

let SReg =

in(sch,(rusername:bitstring,rr1:bitstring,re:bitstring));

let sPub = mul(d,P) in

insert t(rusername);

let R’ = add(rr1,h(con(rusername,d))) in

let I = add(re,h(con(d,rusername))) in

out (sch,(I,R’,sPub)).

let SAuth =

in (ch,(xrealm:bitstring,xusername:bitstring,xx:bitstring,xI:bitstring,xTl:bitstring,xmu:bitstring));

let e’ = sub(xI,h(con(d,xusername))) in

let x’ = mul(xx,mul(h(con(xusername,d)),d)) in

let mu’ = h(con(con(con(username,x’),e’),xTl)) in

if xmu = mu’ then

get t(=xusername) in

event UserAuth(xusername);

new b:bitstring;

let y = mul(b,P) in

let K = mul(b,xx) in

let sks = h1((con(con(con(K,x’), e’), xusername))) in

let Auths = h2(con(con(con(K,sks),sks),add(xTl,one))) in

let Response = (xrealm,y,Auths) in

out(ch,Response).

let S = SReg | SAuth.

process !User | !S

The results for the codes are listed as follows:

-- Query inj-event(UserAuth(id)) ==> inj-event(UserStart(id))

nounif mess(sch[],(rusername_4217,rr1_4218,re_4219))/-5000

Completing…

Termination warning: begin(UserStart(username[]), @sid_301 = @sid_5119, Pub = Pub_5120, rR' = rR'_5121, rI = rI_5118, @sid = @sid_5122, @occ9 = @occ_cst) && mess(sch[],(rI_5118,rR'_5121,Pub_5120)) -> attacker(rI_5118)

Selecting 1

200 rules inserted. The rule base contains 177 rules. 14 rules in the queue.

Starting query inj-event(UserAuth(id)) ==> inj-event(UserStart(id))

RESULT inj-event(UserAuth(id)) ==> inj-event(UserStart(id)) is true.

-- Query not attacker(sks[])

nounif mess(sch[],(rusername_12050,rr1_12051,re_12052))/-5000

Completing…

Termination warning: mess(sch[],(rI_12947,rR'_12948,Pub_12949)) -> attacker(rI_12947)

Selecting 0

200 rules inserted. The rule base contains 142 rules. 11 rules in the queue.

Starting query not attacker(sks[])

RESULT not attacker(sks[]) is true.

-- Query not attacker(sku[])

nounif mess(sch[],(rusername_18830,rr1_18831,re_18832))/-5000

Completing…

Termination warning: mess(sch[],(rI_19727,rR'_19728,Pub_19729)) -> attacker(rI_19727)

Selecting 0

200 rules inserted. The rule base contains 142 rules. 11 rules in the queue.

Starting query not attacker(sku[])

RESULT not attacker(sku[]) is true.

So our scheme passes the verification.

10 Comparisons of performance with some related SIP schemes

Here, we compare the proposed scheme for its strength with schemes proposed by Zhang et al. [38], Yeh et al. [34], Irshad et al. [16] and Arshad and Nikooghadam [3]. First of all, Table 2 introduces the notations with description for the purpose of comparison. Afterwards Tables 3 and 4 compare these schemes for computational complexity and security features respectively.

Table 2 Notations used in comparison
Full size table
Table 3 Comparison of efficiency: memory space, communication cost and computational cost/complexity
Full size table
Table 4 Comparison of performance: security characteristics
Full size table

We begin the efficiency comparison of these schemes from the very first phase, that is, registration phase. During this phase, our scheme adds only one one-way hash operation at the user as compared to other four schemes [3, 16, 34, 38]. While at the server, our scheme remarkably cuts the computational cost in relation to the schemes [16, 34, 38] and adds only one extra one-way hash operation than in Arshad and Nikooghadam’s scheme. Computational complexity/cost at the user during password update phase is least in Yeh et al.’s scheme, higher and quite same in schemes [3, 16, 38], and only two one-way hash operations are more in our scheme than in [3, 16, 38]. For the same phase, the computational complexity/cost at the server is least in Yeh et al.’s scheme, slightly more in Arshad and Nikooghadam’s scheme, highest and exactly same in schemes [16, 38], for our scheme it is higher than in schemes [3, 34] but lower than in schemes [16, 38]. Although registration phase is deployed only when a user has to register at the server and password update phase is deployed only when a user wishes to update a new password in her smart card or memory device, most frequently used phase is the login-authentication phase. Computational complexity/cost for login-authentication phase at the user is least in Arshad and Nikooghadam’s scheme, and noticeably higher in schemes [16, 34, 38]. In our scheme, at the user there is only one elliptic curve scalar point multiplication and one one-way hash operations extra than in Arshad and Nikooghadam’s scheme. At the server, computational complexity/cost for this phase in our scheme is quite same to that in Arshad and Nikooghadam’s scheme and least among the considered schemes. If we look at the overall computational complexity/cost of these schemes, we observe the least load in Arshad and Nikooghadam’s scheme. Our scheme uses two elliptic curve scalar point multiplication and two one-way hash operations extra than in [3] but it does not make use of costly modular inversion. Collectively, it can be stated that our scheme adds only little computational load and offers promising security features as the discussion along with Table 4 follows.

The extra computational load at some places at user/server in our scheme is justified as displayed in Table 4. Our scheme is safe from various potential attacks to which the other considered schemes are victim. None of the schemes [3, 16, 34, 38] except our’s provides mutual authentication, the reason being the applicability of either the user impersonation attack or the server spoofing attack or both. Arshad and Nikooghadam’s scheme has least computational load at most of the places (as shown in Table 3) but it is insecure to server spoofing and stolen verifier attack. Besides, this scheme requires one and half round-trip to complete the authentication process unlike Irshad et al.’s scheme. On the other hand, our scheme follows the single round-trip design of Irshad et al.’s scheme. Like other four schemes in Table 3, the security of our scheme is based on ECDLP and hence it exhibits the virtue of forward secrecy. It is clear from this table that our scheme is superior as compared to other schemes for different security attributes. The increased efficiency and security of our scheme over the other schemes [3, 16, 34, 38] is evident from the results displayed by Tables 3 and 4.

Like predecessor schemes given by Irshad et al.’s and Arshad and Nikooghadam’s, in our scheme also, a user cannot freely change his/her password without server’s assistance. In order to update a new password in his/her smart card, a user is required to interact with the server. On one hand, this is an additional load on the server and on the other hand this is a limitation for user. Since server has sufficiently large computational capacity and a user has to occasionally change his password, this does not affect our scheme much.

11 Conclusion

In this paper, we have focused on the shortcomings of both Irshad et al.’s and Arshad and Nikooghadam’s ECC-based SIP authentication schemes for VoIP. We have revealed that Irshad et al.’s scheme not only suffers from user impersonation attack but threats like password guessing and server spoofing also exist. Further, we have exhibited that some secrets of both user and the server are at the risk of disclosure in their scheme. Next, Arshad and Nikooghadam’s scheme is shown to be inflicted with server spoofing and stolen verifier attack. With a view to settle the security weaknesses of these schemes, we have designed an efficient SIP authentication scheme for VoIP based on Irshad et al.’s scheme. It has been displayed that the proposed scheme resists all the attacks and is free from all the weaknesses present in two aforementioned schemes. Like most of the SIP authentication schemes, the security of our scheme is also based on the Eliptic Curve Discrete Logarithm Problem (ECDLP) and offers forward secrecy. Our scheme is simple, high in performance and has provable security; hence it offers a viable authentication mechanism for SIP-services for VoIP.

In future, we would try to propose a SIP authentication scheme facilitating user to change his/her password freely without interacting with the server and yet preventing any unauthorized person to update a false password in user’s smart card.