Perfect forward secrecy in VoIP networks through design a lightweight and secure authenticated communication scheme

With the growth of the internet, development of IP based services has increased. Voice over IP (VoIP) technology is one of the services which works based on the internet and packet switching networks and uses this structure to transfer the multimedia data e.g. voices and images. Recently, Chaudhry et al., Zhang et al. and Nikooghadam et al. have presented three authentication and key agreement protocols, separately. However, in this paper, it is proved that the presented protocols by Chaudhry et al. and also Nikooghadam et al. do not provide the perfect forward secrecy, and the presented protocol by Zhang et al. not only is vulnerable to replay attack, and known session-specific temporary information attack, but also does not provide user anonymity, re-registration and revocation, and violation of fast error detection. Therefore, a secure and efficient two-factor authentication and key agreement protocol is presented. The security analysis proves that our proposed protocol is secure against various attacks. Furthermore, security of proposed scheme is formally analyzed using BAN logic and simulated by means of the AVISPA tool. The simulation results demonstrate security of presented protocol against active and passive attacks. The communication and computation cost of the proposed scheme is compared with previously proposed authentication schemes and results confirm superiority of the proposed scheme.


Introduction
What is VoIP 2 ?
VoIP stands for Voice over Internet Protocol and is also sometimes called the internet telephone or telephone IP 3 . This technology makes it possible to use the internet for making phone calls and unlike the traditional phones based on wire lines, uses digital technology. In fact, using the VoIP technology the voice is transmitted using IP information packets through the internet. IP-based networks are supported on all networks including organization networks, private networks, wired networks, and also wireless networks. VoIP is, in fact, applicable to all networks. In any case, any technology has its advantages and limitation. We have tried to mention these items briefly in this paper.
Introduction to the operation of SIP in the VoIP protocol As briefly presented in the following figure, the operation of the SIP protocol in the VoIP system is as follows: Registration: before starting a session, each one of the parties in the connection, register their current location by sending a REGISTER message to the register server. Making the call: in order to start a call, the client starting the connection sends an INVITE message to the server on which it has already registered 2 Voice over Internet Protocol 3 Internet Protocol and declares that it wants to call its intended number. Then, the server finds the location of the user on the other side of the call or the call destination and sends the INVITE message to it. Once the INVITE message reaches the other side of the connection, the OK, RINGING, and TYPING messages will be exchanged and finally, the connection destination returns the ACK message to the client. Data transmission: in this stage of the connection, the RTP protocol goes into action and the data get exchanged in an end-to-end manner. Ending the call: After transmitting the data, either one of the parties can send the BYE message to the other one in order to request the call to be terminated. Once the OK message is received in response, the connection will end.

SIP Authentication
In the SIP protocol, two-way authentication between the parties in a connection needs to be carried out in the following steps: Registration: At the registration step, the authentication mechanism must be used to prevent the registration of illegal users. Session setup: When making the call using the INVITE message, both parties need to authenticate the identity of the one on the other side. Session termination: When the session is being terminated by either one of the BYE or CANCEL messages, the identity of the party sending these messages should be confirmed for the user receiving the message.

Security requirements in SIP
1. Mutual Authentication: Mutual authentication means that both of the parties in the connection (client and the server) have their identity authenticated by the other party in a single protocol. It can be said that by performing correct and effective authentication in the initial steps on the server, wasting resources is prevented and the attacker will not be able to waste server resources using fake messages. 2. Session key security: This requirement is stated in the sense that at the end of the key exchange step, the session key should only be known to allowed entities, i.e. client and server, and the attacker should not be able to access the session key of either one of the parties in the session. 4 Session Initiation Protocol 3. Perfect forward secrecy: This is one of the important security requirements in protocols. It is defined in the sense that if any of the long terms (such as the user password or the server private key) are exposed, previous session keys do not end up in the attacker's hands. In order to meet this requirement, the session key should not be solely based on the long terms. Furthermore, it must be noted that the attacker has access to the public channel information as well. Therefore, the public channel parameters should not be directly used for the creation of the session key either. 4. Known key secrecy: This requirement ensures that if the attacker obtains the current session key for both of the parties in a connection, it will not be able to discover previous session keys of the protocol (independence of the session keys from each other). Generally, random numbers are used in security protocols in each session in order to achieve this security features. 5. Fast error detection: This requirement in the two-factor protocols declares that in case the user enters the wrong username and password to the ATM machine, the card can detect this mismatch with the correct username and password and prevent costly operations such as inner product calculation on the server side. With fast detection, wasting the resources on the server can be prevented and it can provide its services to real users. 6. Re-registration on the server: In the protocols where the user ID is sent overtly on the public channel, it is possible that the attacker might re-register on the server with the user's ID and different parameters without the server noticing this re-registration by the attacker using the user's ID.

SIP attacks
In this section, we present the possible attacks on the SIP protocol: 1. Stolen verifier attack: In most of the password-based protocols, the user password gets stored in the server database in order to enable user authentication. On one hand, these databases are the main target of the attackers. If an attacker manages to get its hand on the information stored in these databases, it can forge the identity of the legitimate user or the server. On the other hand, in the protocols which are based on smart cards and password, the smart card might get stolen or lost because of negligence. Therefore, the smart card must not include any important information because it is possible to extract the information stored in the card and the attacker can take action to find the session key using this information.
2. Password guessing attack: In this attack, the attacker records the messages between the server and the legitimate SIP user and then uses the obtained messages and a password dictionary to guess the password. If this process is carried out without the server's knowledge, it is called an offline password guessing attack. The attacker can then fake the user's identity after obtaining the password and receive its intended services from the server as a legitimate user. 3. Denning-Sacco attack: This attack is defined as the attack where the attacker obtains the key of a previous session and uses it to try and find other session keys or the long terms. 4. Modification attack: The attacker tries to modify the authentication variables in this attack. This attack endangers the integrity of the information and leads to the denial of service attack. 5. Man in the middle attack (MITM): In this attack, the attacker acts as the communication interface and gets the information from both sides and changes them however it wants and delivers it to the other side. The connection parties are unaware of the existence of the third party and thing that the information is being exchanged between themselves. It is possible that the attacker merely acts as the listener and only receives the information it needs 6. Replay attack: In this attack, the attacker obtains the transmitted messaged between two entities and sends them at a different time. The connection parties do not notice that the messages are old and treat them as new messages and session key agreement steps go through. By repeatedly sending these expired messages, server resources get used pointlessly and the server becomes unable to serve the legitimate user. 7. Privilege insider attack: In this attack, the attacker is a legitimate person from the server which has obtained the information transmitted on the secure channel. Using this information, the attacker either tries to guess the user's password or fakes its identity. 8. Server spoofing attack: In this attack, the attacker obtains the REQUEST message sent to the server by the user and modifies the calculations carried out on the server side in such a way that the user does not notice the modification made by the attacker on the calculations carried out on the server side. In fact, the user believes that it has connected to the real server while the attacker has placed itself in the server's place.
9. Known session-specific temporary information attack: If the random numbers of a session get disclosed, the key of that session should not be disclosed. In order to prevent this attack, the presented method should not depend merely on the random numbers of each session but also the existence of a parameter in the session key which both the legitimate user and the server are able to obtain is essential. 10. Database injection attack: This type of attack allows the attacker to read or modify the database data by injecting code to the software or installing malicious software on a system and running its desired commands.

Overview of Recent Work
In 2015, Zhang et al. [1] presented a password-based single factor protocol in SIP. However, Lew et al. in 2016 [2] showed that the method proposed by Zhang et al. [1] is vulnerable to privilege insider attack and inappropriate mutual authentication. In the same year, Arshad and Nikooghadam [3] also presented a single factor method. However, in 2016 Lin et al. [4] showed that the method proposed by Arshad and Nikooghadam [3] is vulnerable to privilege insider attack and server spoofing attack and does not provide user anonymity. Therefore, they presented a new single factor method. In 2016, Zhang et al. [5] presented a new two-factor method in SIP for VoIP networks. In the next section, we review this method and explain the possible attacks.

Analysis of the security flaws of the method presented by Nikooghadam et al.
In 2016, Nikooghadam et al. [3] presented a method for key agreement and two-way authentication. In this section, we present the complete steps for registration and key authentication in the proposed protocol. Then, we will show that if for any reason one of the long terms gets leaked then perfect forward secrecy, which according to definition states that if any of the main parameters gets leaked for any reason the attacker should not be able to obtain the session key, is violated and the attacker can get their hand on the session key.

Explanation of the protocol presented by Nikooghadam et al. in 2016
In this research, we have tried to explain the protocol proposed by Nikooghadam et al. in 2016 [3] correctly and completely because in the rest of the paper, we will address the problems present in this protocol.
In the registration step, all of the messages exchanged between the user and the server go through the secure channel. This means that the attacker cannot harm the information exchanged between the user and the server in the registration step. However, it should be noted that according to the Kerkhof laws, the encryption algorithm is public and the attacker knows how each parameter is calculated and using what other parameters. Therefore, we could say that the attacker cannot use the parameters sent and received through the secure channel during the registration step and the only thing it can do in the registration step is find out how the formulas are made and calculated. If the connection parties have saved any parameters in their databases, the attacker can infiltrate these databases and access the parameters saved in them. So, the main action by the attacker takes place at the authentication and key selection step.
In the registration step, the main objective of the user is to deliver its information to the server and get the information of the server. The mutual information of the parties is then stored in a smart card. In fact, this smart card acts as a receipt which the server gives to the user after registration. After the registration step, it is time for the authentication and session key agreement step. The parties are trying to agree on a session key so that they can be sure any information exchanged between them cannot be accessed by the attacker.
Any message sent either by the user or the server at the authentication step is first checked by the receiver to make sure if the message was sent by the other real party in the connection. In fact, the message needs to be verified. Once the message is verified (meaning that the message was sent by the other party and hasn't been modified on the way) the required actions and calculations are carried out on the message.
In the rest of this section, in order to help better understand the protocol, some parts are explained briefly. However, while reviewing other papers we will explain them comprehensively, for example: The equation Checks | − | ≤ ∆ which is seen in the above protocol is meant to stop the replay attack. It, in fact, uses time variables to prevent the attacker from capturing the message from the channel and resend it. Indeed, the message will be checked to see if it is new.
Unlike the registration step, in the authentication step, all of the messages between the user and the server are sent and received through the public channel. This makes it possible for the attacker to access some of the parameters and it is possible that it can work out the session key using these parameters. The main flaws of the main paper are presented in this section.

Explanation of the perfect forward secrecy attack on the Nikooghadam et al. method
We will prove that in the method presented by Nikooghadam et al. if the private key of the server (x) is revealed, according to the premise of this attack, for any reason then the attacker will be able to access the mutual session key of the parties In the first message sent in the authentication and key agreement phase, parameters 1 and are sent on the public channel. The attacker obtains the public channel information and uses the server private key (x) to decrypt and work out the parameters and using equation ( ) = ( ‖ ). Then, the attacker calculates parameter using equation = ℎ( ‖ ). Then, the attacker find gets the value of parameter by decrypting 1 and using equation In the second message transmitted in the authentication and key agreement phase, parameter 2 is sent to the user through a public channel. Then, the attacker decrypts parameter 2 and ) and gets the value of parameter . Considering the session key equation , now the attacker can work out the other parameters used to create the session key and obtain the mutual session key used by the parties, provided that it has the private server key (x). Therefore, it was proven that the attacker can obtain the session key of the parties and will have access to all of the messages which are exchanged between the server and the user. This makes the security of the proposed protocol be questioned completely.
So, it was proven in this stage that the idea proposed by Nikooghadam et al. [3] in 2016 is not fully valid and this idea has been unable to meet the perfect forward secrecy security requirement. If we search deeper in the papers in this field, we will realize that meeting the perfect forward secrecy is a difficult task. As mentioned in the paper presented by Nikooghadam et al. in 2018, it has been declared that the perfect forward secrecy security requirement has been met in VoIP networks. However, we will prove in the following sections that this idea has been unable to meet this security requirement.

Review of the paper presented by Zhang et al.
In this section, we review the steps of the two-factor protocol presented by Zhang et al. This protocol, like other protocols presented in the authentication and key agreement in SIP field, includes the following main steps: registration, authentication and key agreement (login), and password change. The steps of this method and details of each step, and also the security flaws of their presented method are reviewed in this section.
The symbols used in Zhang's protocol are presented in the following table

Initial Step
Part one: The oval curve equation ( , ): 2 = 3 + + ( ) on the first order oval curve is selected by server SIP.
Part two: The server selects a random number as its private key and a hash function. Then, it calculates = .
Part three: The private key gets protected by the server and parameters { ( , ), , , ℎ(. )} get published publicly.

Registration Step
Step one: The user sends its ID and password and a random number . Then, it calculates 1 using equation 1 = ℎ( ⨁ ). Afterward, the user sends the parameters { , 1 } to the server through the secure channel.
Step two: Once the server has received the information, it calculates 2 and 3 using equations 2 = ℎ( ⨁ ) and 3 = 1 ⨁ 2 . Then, it stores parameter 3 in the smart card and sends the card to the user through the secure channel.
Step three: Once the user has received the smart card, it saves the random parameter in the card.
The registration step of Zhang's protocol is presented in the following figure.
The registration step in the protocol presented by Zhang et al.

Authentication and key agreement step
At the end of the authentication and key agreement step, connection parties, i.e. the server and the user, get the secure mutual session key.
First step: First, the user inserts its smart card into the ATM machine and enters its ID and password. Then, the smart card selects two random numbers 1 and 2 and carries out the following calculations. ( 5 ) ) .
( 5 ) points to point 5 on dimension while ( 5 ) points to point 5 on dimension . After carrying out the above calculations, message REQUEST { , 4 , 6 } is sent to the server by the user.
Step four: After the RESPONSE { , ℎ } message is received by the server, it checks whether the condition ℎ = ℎ(( ) ‖( 4 + 1)‖( ) ) is met. In case the condition was not met, the session ends. However, if the condition is satisfied, the session key for the parties will be equal to = 1 3 .
The authentication and key agreement step in Zhang's protocol is presented in the following table.

Changing the user password step
In this step, the user can change its password.
Step one: First, the user selects a new password ( * ) and a random number ( * ) and a nonce R. Then, the user enters its previous password ( ) and calculates parameters and using equations ℎ( ⊕ )⨁ 3 and ( ) (ℎ( * ⨁ * )|| ‖ ‖ ) , respectively. Then the user sends parameter to the smart card.
Step three: After the user has received , in order to verify the tag value (ℎ( 3 * ‖( + 1))), gets decrypted. If the value is correct, the smart card replaces the old value ( 3 , ) with the new value ( 3 * , * ).
The user password changing step of Zhang's protocol is presented in the following table.
User password changing step in the protocol presented by Zhang et al.

Review of the attacks on the scheme presented by Zhang et al.
Replay attack: While sending the REQUEST message, the server performs calculations for the repetitive requests sent by the attacker too. In fact, we could say that the server does not notice that the messages are duplicate and performs the calculation for these messages as well. As a result of various and repeated messages being sent by the attacker, the resources of the server get wasted and the server becomes unable to serve legitimate users. In fact, the replay attack leads to the denial of service attack and results in server failure.
Known session-specific temporary information attack: Since C 4 and C 7 are sent on the public channel, which is publicly audible, the attacker can obtain the information transmitted on this channel. Therefore, in case the random variables r 1 and r 3 get leaked, the attacker can obtain the mutual session key used by the parties in the connection. Re-registration: In protocols where the user ID is sent overtly through the public channel, it is possible for the attacker to re-register on the server using the user ID and reselecting other parameters without the server noticing the registration of the attacker using this duplicate user ID. In the method presented by Zhang et al., because of the user ID being sent overtly and the attacker's knowledge of it, a foreign attacker can re-register by selecting a new and r and using user's . The server does not notice the re-registration and issues a smart card for the attacker as well. Anonymity: Sending the user ID overtly on the public channel eliminates the user anonymity. In fact, by sending the user ID on the public channel, the attacker notices the times at which the user uses the server services and, in a sense, the user's privacy gets violated. Fast error detection: In the two-factor protocol presented by Zhang et al., the smart card is not able to detect if the user enters the incorrect ID and password. Therefore, the server needs to carry out the costly multiplication on the oval curve for each user in order to verify the validity of the information entered by the user. When the number of users or the number of their request grows, performing this calculation each time gets costly and leads to server failure and denial of service. By creating the denial of service attack, the server becomes unable to provide services to legitimate users.
In this section, we review the proposed two-factor protocol. The proposed protocol, like the other protocols presented in the authentication and key agreement in SID field, consists of the following main steps: registration, authentication and key agreement (login), and password changing. The steps of this method and the details of each step will be reviewed in this section. At the beginning of this section, we present the symbols used in the protocol in the following table. Then, the registration, login, and password changing steps and their details are reviewed [5].

Registration step
The user and the server carry out the following steps in a face to face meeting and at the end of this step, the server presents the smart card to the user.
Step one: At first, the user selects a user ID and a password along with two random numbers and . Then, it calculates the values of and with respect to previously selected parameters using their formulas.
m is a number between 2 8 and 2 16 that makes it impossible for the attacker to guess the user ID and the password simultaneously. Then, the user sends parameters { , , } to the server through the secure channel.
Step two: After parameters { , , } are received by the server, it calculates parameters , , and using the following equations.
Afterward, the server selects timestamp 1 and calculates parameter using equation ( ‖ ‖ 1 ). The server puts parameters and inside the smart card and sends it to the user through the secure channel. The server also saves parameters 〈 , , 〉 in its database. When the user logs into the server, the field is set to one and once the user logs out, this field is set to zero on the server's database.
Step three: After the smart card is received by the user, the following calculations are carried out.
Step two: Immediately after the REQUEST { , , 2 } message is received by the server, the freshness of the message is verified using equation | 3 − 2 | ≤ ∆ . In case the message is new, the server decrypts parameter using its private key according to equation ، ( ) = ( * ‖ * ‖ 1 ) . Then, it calculates parameter * = ℎ( ‖ ‖ ‖ ). Then, parameter is decrypted using the calculated * parameter and parameters ، ، 2 ′ are obtained.
Afterward, the server compares parameter with parameter * and verifies the validity of equation | 3 − 2 ′ | ≤ ∆ . In case the parameters are not equal, the session gets terminated. However, if the parameters are equal, the user gets authenticated by the server. Afterward, the server calculates * using equation ⨁ and queries its database for parameter * . Then, it extracts 〈 , , 〉 information pertaining to . If the field is equal to one, the session gets terminated because it means that the user is currently receiving a service from the server. Otherwise, timestamp 4 and random number are selected by the server. After performing the above operation, the following calculations are carried out and finally the CHALLENGE { , 4 , 2 } message is sent.
Step three: After the CHALLENGE { , 4 , 2 } message is received by the user, it uses equation | 5 − 4 | ≤ ∆ to ensure the freshness of the message. In case the equation is not valid, the session gets terminated. However, if the equation stands, the smart card decrypts parameter 2 using parameters and obtains the ( * , * , * , 4 ) values which might have been modified. Then, it checks the validity of equations * = and * = . In case the above equations stand, the server gets authenticated by the smart card and the session key and parameter are calculated. Then, parameter replaces parameter ′ .
Then, the smart card sends the RESPONSE { * } message through the public channel.
Step four: After the server receives the RESPONSE { * } message, it verifies the validity of parameter * =? and sets the value of the field to one. After calculating the session key, resets to zero. The authentication and key agreement step of the proposed method is presented in the table.
The authentication and key agreement step of the proposed protocol
Step two: Immediately after the server receives the REQUEST { , , 2 } message, the freshness of the message is verified using equation | 3 − 2 | ≤ ∆ . Doing so prevents the replay attack and avoids the extra calculations on the server. In case the message is new, the server decrypts parameter using its private key according to ، ( ) = ( * ‖ * ‖ 1 ) . Then, it calculates parameter * = ℎ( ‖ ‖ ‖ ). Then, parameter is decrypted and parameters , , 2 ′ , and are obtained using * . Afterward, the server calculates parameter using parameter * and checks the validity of equation | 3 − 2 ′ | ≤ ∆ . In case the parameters are not equal, the session gets terminated. However, if the equation stands, the user gets authenticated for the server. Then, the server calculates * using equation ⨁ and searches its database for parameter * and extracts the 〈 , , 〉 information according to . If the field is equal to one, the session gets terminated. Otherwise, the server selects a timestamp 4 and a random number . After doing the above operations, the following calculations are carried out. Finally, the CHALLENGE { , 4 , 2 } message is sent.
Step three: Once the user receives the CHALLENGE message at time 5 , first it checks the freshness of the message using equation  messages, it should not be able to find the user's ID.
In order to obtain the user ID, the attacker needs to know the server's private key while the server's private key is confidential. Therefore, the proposed protocol provides user anonymity.
2) Perfect forward secrecy: If the user's or the server's private key gets leaked, the user should not be able to access the session key. In this protocol, the attacker cannot obtain the correct session key even if the server's private key gets leaked because only the user and the server are aware of the random number . On the other hand, in equation ) is hidden and working out parameter is not possible provided that the user's gets leaked. Therefore, the attacker does not obtain the session key.
3) Known-key secrecy: Random parameters and are selected by the parties. Also, they are different for each session and do not depend on previous and . Therefore, leakage of the user's previous session keys does not enable the attacker to obtain the new session key. 4) Session key security: In this protocol, only the parties, i.e. the user and the server, will be able to obtain the session key. Considering the inability of the attacker to obtain parameters , , and and its lack of access to random parameters and , the attacker is not able to work out the session key. 5) Leakage of the temporary parameters of a session: In case temporary parameters , , and get leaked, the attacker should not be able to obtain the correct session key. Considering that the attacker's unawareness of parameters , , and , it cannot access the right session key. 6) Offline password guessing attack: In case the attacker obtains the REQUEST, CHALLENGE, and RESPONSE messages, it will not be able to guess the user's password because: Considering each one of the messages, the attacker is unable to guess the user's password. Even if the attacker steals or find the smart card and extract its information, because of it will be unable to guess the user's ID and password. 1) Impersonation: a. Impersonating the user: In order for the attacker to impersonate the user and its REQUEST messages, the attacker needs to send reliable messages to the RESPONSE server. Therefore, the attacker needs to know * and * values. In order to calculate the valid * value, , , and values are needed. But these values are kept confidential by the user. Also, the attacker must know the ، ، , and values in order to calculate the valid * value. However, as proven in part 4 of section 6-1, the attacker cannot obtain the mutual session key of the user and the server, because it does not know parameters and . b. Impersonating the server: In order to impersonate the server, the attacker must be able to create the valid { * , 4 * , 2 * } CHALLENGE message and send it to the user. To obtain 2 * , the attacker needs to know parameters , and the random number generated by the user. However, as mentioned in part 6 of section 6-1, the attacker is not able to simultaneously guess the user's ID and password. Moreover, the attacker does not know parameter which is the server's private key and . Therefore, the attacker is unable to impersonate the server.
2) Stealing the verifiers: Since hidden parameters, i.e. server's private key and user's password, are not stored in the server's database, the attacker is not able to obtain the session key even if it can access the server's database. In case the smart card gets stolen or lost and the attacker extracts the information stored inside it, the attacker has the { , , , , , (0)/ (0), ℎ(0) } information. Due to the random numbers generated by the user and the server, i.e. and , and their influence in the calculation of the session key, = ℎ( ‖ ‖ ‖ ‖ ), the attacker cannot find the session key even if it has the smart card information.
3) Denning-Sacco attack: The attacker cannot access the server's private key parameters or the user's password by having previous session keys. Considering the session key formula in this protocol, i.e. = ℎ( ‖ ‖ ‖ ‖ ) , and presence of random numbers and which are selected by the server and the client respectively and are different for each session, it is impossible for the attacker to find the key for new sessions using previous session keys. On the other hand, one can't find the user's password or the server's private key by having the session key since they are not explicitly stated in the session key formula. 4) Replay attack: Imaging the attacker wants to send a duplicate REQUEST { , , 2 } message to the server. Since equation | 3 − 2 | ≤ ∆ is verified on the server, the session gets terminated if the message is duplicate. In case the attacker tries to change timestamp 2 to 2 * and send the { , , 2 * } message to the server, the server calculates parameter * and calculates the timestamp by decrypting . By comparing the calculated timestamp to the timestamp 2 * sent through the public channel, it notices the change to the timestamp. Therefore, the attacker is unable to send duplicate messages or modify the timestamp.

Overview of the avispa software
The Avispa simulation software is a formal security verification tool which is used to show the security or lack of security of a protocol. Avispa provides a language named HLPSL 5 for security description of protocols and presenting their security specifications and verifies them as a formal toolkit. Structure and user interface of this tool is presented in the figure. [6] By reviewing the paper presented by Nikooghadam et al. in 2018 we will prove that the Perfect forward secrecy security need will not be satisfied.
The perfect forward secrecy security requirement is defined as: if any of the long terms (such as the user's password or the server's private key) gets leaked, the attacker does not get previous session keys at its disposal. In order to provide this requirement, the session key should not merely depend on the long terms. Moreover, it should be noted that the attacker has full access to the public channel information. Therefore, the parameters sent through the public channel should not be directly used while creating the session key. As mentioned in the paper's title, this requirement is not provided in the method. This means that if the database on the server is infiltrated, the attacker will access some parameters which make it possible for him to work out the session key and question the Perfect forward secrecy security requirement.
Imagine that the private key , which is a long term, is leaked and the attacker was able to infiltrate the database and obtain parameters and . Since the attacker has private key and since was also sent over the public channel, equation ( ) = ( * ‖ * ‖ 1 ) can be used to obtain and . Also, because SID is also public and in fact the server's ID, the attacker has all of the * = ℎ( ‖ ‖ ‖ ) parameters. Therefore, it is able to create . The attacker also has the and values and can use * = ⨁ to obtain . Now, it can use ( 2 )= ( * , * , * , 4 ) to calculate the rest of the values in the session key. This way, we were able to prove that the perfect forward secrecy security requirement is not met.

The proposed solution:
The proposed protocol consists of the following steps: Registration, authentication, and changing the password. We will explain every step at length.
First, the user selects a password, and ID, and three random numbers. Then, in order to prevent the insider attack, the user creates parameter = ℎ( || || ) and carries out the following calculations. Finally, it sends parameters , , , , , ( ) , , , RB to the server. One of these parameters is its own public key. It is worth noting that the messages exchanged between the user and the server at the registration step are sent through the secure channel.

RB=h( || )
= ℎ(ℎ( || ||RB) ) TN=h(RB|| ) Immediately after the server receives the user's message, it uses the user ID to create a temporary ID named using the following operations. It also creates parameter according to the new temporary ID. Then, the server carries out the following calculations and finally sends a smart card containing parameters , , , , ( ), and to the user.
Upon receiving the smart card, the user will delete some of the parameters in it and add some parameters to it. In the end, the smart card contains parameters , , , .
Overview of the registration step is presented in the following figure.
In the authentication step, first, the user inserts the smart card into the ATM machine and enters its user ID and password. Then, the following calculations are carried out by the smart card and parameters 1 , 2 , 1 are sent to the user through the public channel. Once the server receives the message, it checks the freshness of the message Check | 2 − 1 | ≤∆ . This is done to prevent the replay attack. Then, the server decrypts parameter 1 , which has been encrypted with the server's public key, with its private key and creates * = * ⊕ * and compares it to the ′ resulting from the encryption of 1 . In fact, this authenticates the received message. Then, since the * resulting from decryption of 1 has been encrypted by its own public key, the server decrypts it with its private key and creates the initial session key. Afterward, the server calculates parameter = ( ) ( || ) and finally, it sends 3 , to the other party. Once the other party receives message , it checks the freshness of the message Check | 4 − 3 | ≤∆ to eliminate the possibility of a replay attack. Since has been encrypted with its own public key, the user decrypts it using its private key and obtains the initial session key. Then, it creates parameter and authenticates the received message using equation * = . Since parameter GF was encrypted using the user's public key, the user decrypts it with its private key and creates a new session key. Finally, the user calculates the following parameters and also calculates and 5 and sends them to the other party. The server checks the freshness of the message immediately after receiving it. Then, it decrypts using its private key. Afterward, the server creates parameter and compares it to the resulting from the decryption of . By doing so, the server authenticates the message. At this point, the parties in the connection have agreed on the session key.
Overview of the authentication and key agreement step is presented in the following figure.

Password changing step
First, the user inserts its smart card to the device and enters its old password, i.e. * * . Then, it submits the request to change the password along with the new password. * = ℎ( * || * || ) * =ℎ (ℎ ( || * || * || ) ) * = * ⊕ * =h( || * ) RB=? * If the above equation stands, the smart card belongs to the person using it and it has not been stolen. Now, if we imagine the new password to be * * , the following parameters will be calculated again and finally, * * will replace * on the smart card. * * = ℎ( * || * * || ) * * =ℎ (ℎ ( || * * || * || ) ) * * = * * ⊕ * * =h( || * * ) Security analysis of the proposed method Anonymity: Since in the registration step, the user sent its ID to the server and the server used it to create a temporary ID which was used from that point on, the attacker cannot obtain the primary ID and anonymity requirement is satisfied.
Perfect forward secrecy: Since the private keys of both parties are used to create the steps of creating the session key, the attacker cannot obtain the mutual session key and this security requirement is satisfied.
Tracking: Once again, since the server creates temporary ID * and sends it to the user at the registration step which is used at all of the steps, the attacker cannot identify the user by listening to the public channel at the authentication step. Therefore, it will not be able to track the user.
Replay attack: At every step of the authentication process where messages are sent through the public channel, timestamps are used. Once a message is received, its freshness is verified. therefore, the attacker cannot take a message and simply resend it. Impersonation attack: Since the messages are authenticated at every step of their transmission, as presented in the protocol, the attacker cannot impersonate the user or the server for the other party.
Temporary parameter leakage attack: In this attack, it is assumed that if all of the random session parameters get leaked, the attacker should still be unable to work out the session key. Since parameters * * are involved in the creation of the session key and it does not merely depend on the random parameters, the session key is not vulnerable to the temporary parameter leakage attack.
Insider attack: Since the user sends its password to the other party as = ℎ( || || ) and not directly, insider attack is not possible.
Denning-Sacco attack: This attack expresses that if the attacker obtains session key, it should not be able to use the session key parameters and the parameters sent over the public channel to obtain the user's password. Because of the * = ℎ( * || * || ) structure, this type of attack is impossible for the attacker to carry out.
Analysis of the proposed method using the formal Scyther tool In this section, the resistance of the proposed method against some of the famous attacks was reviewed. In the following sections, the analysis of the proposed method's correctness using the Scyther tool will also be presented.

Conclusion
In the VoIP technology, two types of protocols are used. These protocols are as follows: session initiation protocol (SIP) and real-time transfer protocol.
Considering the importance of correct authentication and key agreement in the SIP field and the connections among two users or more, several protocols have been presented in this field. The recently presented protocols for correct authentication are often in one of the following categories: 1-password-based 2-smart card and password-based. The security protocols in SIP must satisfy security requirements including mutual authentication, session key security, forward secrecy, known key secrecy. They also need to be resistant to various attacks including stolen verifier, password guessing, Denning-Sacco, modification, man in the middle, insider, server spoofing, and temporary session parameters attacks.
As mentioned in the recent work review section, the presented one-factor and two-factor methods have usually been unable to fully satisfy the security aspects and utilize suitable measures to prevent the attacks from happening. Therefore, after a while since presenting the new method, we addressed the security flaws of the proposed method and presented an improved method. Since in addition to the above items, lower execution and connection time are of importance in the communications, the presented protocols reviewed this important factor as well.
In this paper, the method presented by Nikooghadam et al. and the one presented by Zhang were studies comprehensively and all of their flaws were reviewed in length. The outcome was that these papers were unable to prevent replay and temporary parameter leakage attacks. Also, they were unable to provide some security requirements such as anonymity, fast error detection, and some others. In this regard, Zhang et al. solved these problems in a new method but Nikooghadam et al. proved that Zhang was unable to satisfy all of the security requirements. Therefore, in 2018 they presented a new scheme in order to provide every security requirement. However, we proved in this paper that Nikooghadam et al. at 2018 were unable to provide some of the security requirements with their idea. Therefore, some attacks were inflicted on it such as impersonation, denial of service, etc.
Results of informal analysis of the proposed method demonstrated its resistance to various attacks described in SIP. Moreover, security requirements including anonymity, fast error detection, and re-registration are satisfied in the presented method. However, it was informally proven in this paper that these results are faulty and the method cannot satisfy all of the security requirements.
Since the proposed method does not require costly operation such as multiplication on an oval curve, and exponentiation and using symmetrical encryption methods and hash functions, the proposed method is considered a light method compared to other methods. The proposed method has also improved with regard to computational cost and number of transferred messages on the public channel compared to previous methods. Although the connection cost of some presented protocols is lower than the connection cost of the proposed method, none of them are able to provide all of the security aspects. It is worth noting that providing security is far more important than computational and executive costs.