Ephemeral-Secret-Leakage Secure ID-Based Three-Party Authenticated Key Agreement Protocol for Mobile Distributed Computing Environments

: A three-party Authenticated Key Agreement (AKA) protocol in the distributed computing environment is a client that requests services from an application server through an authentication server. The authentication server is responsible for authenticating the participating entities and helping them to construct a common session key. Adopting the Authentication Protocol (KTAP) in such an environment, the authentication server is able to monitor the communication messages to prevent and trace network crime. However, the session key in the KTAP setting is created only by the authentication server and is vulnerable to the resilience of key control. On the other hand, with the rapid growth of network technologies, mobile devices are widely used by people to access servers in the Internet. Many AKA protocols for mobile devices have been proposed, however, most protocols are vulnerable to Ephemeral Secret Leakage (ESL) attacks which compromise the private keys of clients and the session key by an adversary from eavesdropped messages. This paper proposes a novel ESL-secure ID-based three-party AKA protocol for mobile distributed computing environments based on ESL-secure ID-based Authenticated Key Exchange (ID-AKE) protocol. The proposed protocol solves the key control problem in KTAP while retaining the advantages of preventing and tracing network crime in KTAP and also resists ESL attacks. The AVISPA tool simulation results conﬁrm the correctness of the protocol security analysis. Furthermore, we present a parallel version of the proposed ESL-secure ID-based three-party AKA protocol that is communication-efﬁcient.


Introduction
With the rapid growth of network technologies, portable mobile devices (e.g., mobile phone, notebook and tablet) are widely used by people to access remote servers on the Internet. Due to the limited computing capability and power energy of mobile devices, many Authenticated Key Agreement (AKA) protocols are based on the traditional public key cryptography system [1][2][3] and the ID-based AKA (ID-AKA) protocols [4][5][6] for mobile devices. Imbalanced computation is used to shift the computational burden to a powerful server using an online/offline computation technique to further reduce the mobile device computational load. If an AKA protocol adopted an online/offline computation technique, the ephemeral secrets are generally generated by an external source that may be controlled by an adversary. The ephemeral secrets are also involved in the offline pre-computation server is responsible for participating entities' authentication and helps the user and the application server construct a common session key. In the centralized authentication server model an inspection mechanism is provided to prevent and trace network crime, permitting users to access the services provided by the application servers legally. The Key Transfer Authentication Protocol (KTAP) is adopted in this system [22]. In a KTAP setting the session key is created by the authentication server and secretly transmitted to the user and the application server. The authentication server can therefore monitor the transferred messages [23][24][25][26]. However, the disadvantage of KTAP is that the session key is only created by the authentication server and the client and the application servers are unable to participate in constructing the common session key. KTAP is therefore vulnerable to key control resilience attacks [27].
With the rapid growth of network technologies, portable mobile devices (e.g., mobile phone, notebook and tablet) are widely used by people to access remote servers on the Internet. Due to the limited computing capability and power energy of mobile devices, many AKA protocols are based on the traditional public key cryptography system [1][2][3] and the ID-based AKA (ID-AKA) protocols [4][5][6] for mobile devices. Imbalanced computation is used to shift the computational burden to a powerful server using an online/offline computation technique to further reduce the mobile device computational load. If an AKA protocol adopted an online/offline computation technique, the ephemeral secrets are generally generated by an external source that may be controlled by an adversary. The ephemeral secrets are also involved in the offline pre-computation and stored in the insecure memory of mobile devices. If ephemeral secrets are compromised, an adversary can reveal the private keys of clients and the session key would turn out to be known from the eavesdropped messages. This phenomenon is called Ephemeral Secret Leakage (ESL) attacks. To solve this security vulnerability, Tseng et al. [7] proposed the first ESL-secure ID-based Authenticated Key Exchange (ID-AKE) protocol for mobile client-server environments.
Most KTAPs [20,[23][24][25] are password-based authentication protocols. In these protocols the users need to share their own passwords with the authentication server and employ the authentication server public keys to ensure the identities of the participants. These protocols also use symmetric cryptosystems to encrypt the transferred messages. For password-based authentication protocol security a strong password should consist of letters (uppercase letters, lowercase letters), numbers and special punctuations to resist various attacks, such as password guessing attacks and dictionary attacks, etc. However, most mobile devices do not employ standard QWERTY keyboards for users to conveniently enter strong passwords. Instead, these mobile devices often use numeric passwords for user authentication, which is called Personal Identification Number based (PIN-based) authentication. The PIN-based authentication provides a small password space size and thus is vulnerable to various attacks [28]. Otherwise, using the authentication server public keys and the symmetric cryptosystems for the user authentication requires expensive computation, which is not applicable to mobile devices with limited computing capability. This paper improved Tseng et al.'s scheme [7], to propose an ESL-secure ID-based three-party AKA protocol which is more suitable for mobile distributed computing environments. The proposed protocol adopts imbalanced computation to shift the computational burden to the powerful server and an online/offline computation technique to further reduce the computational cost required for mobile devices. The offline pre-computation is executed prior to protocol execution to achieve better performance. The proposed protocol keeps all of the merits of KTAP regarding security including the authentication server is able to monitor the communication messages to prevent and trace network crime and solves the session key problem, which is only created by the authentication server. All participants can contribute information to derive the common session key. In the security analysis, the proposed protocol resists ESL attacks and also satisfies the security attributes required for AKA protocols: known-key security, partial forward secrecy, key-compromise impersonation resilience, unknown key-share resilience and key control resilience [29]. Furthermore, the proposed protocol is validated by Automated Validation of Internet Security Protocols and Applications (AVISPA) [30] formal validation tool to show its security against various active and passive attacks. In addition, a parallel version of the proposed protocol is proposed to enhance the protocol run performance. This paper is organized as follows. Section 2 gives a brief review of the basic bilinear pairing concept, the related mathematical assumptions and the security attributes required for AKA protocols and notions used in the proposed protocol. The proposed ESL-secure ID-based three-party AKA protocol is presented in Section 3. In Section 4 the proposed protocol security and performance analyses are conducted. Conclusions are given in Section 5.

Preliminaries
In this Section the basic bilinear pairings concept, the related mathematical assumptions, the security attributes required for AKA protocols, and the notations used in the proposed protocol are briefly introduced.

Bilinear Pairings
Let P denote a generator of G 1 , where G 1 is an additive cyclic group of large prime order q and let G 2 be a multiplicative group of the same large prime order q. G 1 is a subgroup of the group of points on an elliptic curve E defined over a finite field. G 2 is a subgroup of the group of the multiplicative cyclic group defined over a finite field. A bilinear pairing is defined as a map:ê : The mapê is called an admissible bilinear map if it satisfies the following properties.

Computational Problems
The security of the proposed protocol is based on the following two computational problems. There is no polynomial time algorithm to solve these computational problems with non-negligible probability:

1.
Discrete Logarithm Problem (DLP): Give P, Q ∈ G 1 ; find an integer a such that Q = aP whenever such integer exists.

2.
Computational Diffie-Hellman Problem (CDHP): Given P, aP, bP ∈ G 1 for unknown a, b ∈ Z * q , the CDHP is to compute the value abP ∈ G 1 .

Security Attributes
Here, A, B and S are going to agree upon a common session key and communicate to each other securely. An AKA protocol should provide implicit key authentication for A, B and S, so there are additional security attributes defined for AKA protocols.

•
Known-Key Security. A unique session key should be constructed in each round of an AKA protocol. An adversary cannot derive other previous session keys if knowledge of the previous session keys has been compromised. The main purpose of known-key security is to ensure that the compromising of one session key will not compromise other or future session keys. • Forward Secrecy. If the long-term private keys of one or more of the participants are compromised, the secrecy of previously established session keys will not be obtained by an adversary. The main purpose of forward secrecy is to provide complete protection for the previous transferred messages.
If all long-term private keys of the participants are compromised without compromising previous established session keys, that means an AKA protocol still provides protection for the previously transferred messages. We say that the AKA protocol offers perfect forward secrecy. • Key-Compromise Impersonation Resilience. Suppose that A's private key has been revealed to an adversary. The adversary only can impersonate A to cheat S and B. It is desired that the compromise of A's private key does not allow the adversary to impersonate S or B to cheat A. • Unknown Key-Share Resilience. After the session key has been established, A believes the session key is shared with S and B, while S and B mistakenly believe that the session key is instead shared with an adversary. Therefore, a desirable AKA protocol should be resistant to unknown key-share attacks. None of the participants can force A to establish a session key with a participant that he does not know but A believes he is sharing the session key with the participants that he knows. • Key Control Resilience. The session key should be determined jointly by all participants (e.g., A, S and B). None of the participants can control the session key construction procedure alone. The main purpose of key control resilience is to ensure session key construction fairness and security. It should not be possible for any participants or adversaries to predict or predetermine the session key value.
Constructing a desirable AKA protocol must conform to these desirable security attributes: known-key security, forward secrecy, key-compromise impersonation resilience, unknown key-share resilience, key control resilience. Thus, an AKA protocol is able to resist various active and passive attacks.

Notations
The system parameters, notations and functions used in the whole proposed protocol are defined as follows: • G 1 : an additive cyclic group. • G 2 : a multiplicative cyclic group. •ê: a bilinear map,ê : • P: a generator of the group G 1 . • s: the private key of the authentication server, s ∈ Z * q . • P pub : the public key of the authentication server, P pub = s · P. • ID S : the identity of the authentication server. • ID A : the identity of the client. • ID B : the identity of the application server. • DID A/B : the private key of ID A /the private key of ID B .
where n is a fixed length and 2 n < q.

The Proposed Protocol
We present the proposed ESL-secure ID-based three-party AKA protocol for mobile distributed computing environments in this section. The proposed protocol consists of three phases: the system setup phase, the key extract phase and the mutual authentication and key agreement phases. We also present a parallel version of the proposed protocol to enhance the protocol run performance.

System Setup Phase
The proposed protocol system consists of an authentication server S, an application server B and a mobile client A. The client A refers to a user with handheld device and communicates with the authentication server S and the application server B through open channels such as wireless networks. The application server B provides services or applications to the client A. The authentication server S is responsible for computing private keys according to the application server B and the client A' identities and distribute the private keys to them via a secure channel. The authentication server S is also responsible to generate the systems parameters.
In the system setup phase the authentication server S first generates two cyclic groups G 1 and G 2 of a large prime order q, an admissible bilinear mapê : G 1 × G 1 → G 2 , and a random generator P of G 1 , where G 1 and G 2 are additive and multiplicative cyclic groups of large prime order q, respectively. The authentication server S then performs the following tasks: 1.
Randomly select a system private key s ∈ Z * q . 2.
Compute the system public key P pub = s · P.

3.
Choose two map-to-point hash functions H 1 , where n is a fixed length and 2 n < q.

Key Extract Phase
In the key extract phase client A and the application server B separately submit their identities ID A and ID B to the authentication server S and receive their corresponding private keys DID A and DID B , respectively. The key extract phase is depicted in Figure 1. To the client A as an example, the detailed procedures are presented as follows: 1.
The client A submits its identity ID A to the authentication server S.

2.
Upon receiving the client A with identity ID A , the authentication server S chooses an ephemeral secret value l A ∈ Z * q , and compute QID A1 Set DID A = (DID A1 , DID A2 , QID A1 , QID S ) as the client A's private key and send it to the client A via a secure channel. The authentication server S also set DID B = (DID B1 , DID B2 , QID B1 , QID S ) as the application server B's private key in the same procedures.

Mutual Authentication and Key Agreement Phase
Suppose that the client A would like to communicate with the authentication server S and request services or applications from the application server B. As depicted in Figure 2, the detailed interactions between the three participants are presented as below: Step The client A with identity ID A performs the following off-line computations in advance: Step >, the authentication server S authenticates the client A by performing the following tasks: If the equation holds, then the authentication server S accepts the request. Otherwise, the authentication server S terminates it.
, V SB >, the application server B authenticates the authentication server S by performing the following tasks: (2) Check whetherê(V SB , P) =ê U S + h SB · QID S , P pub or not. If the equation holds, then the application server B accepts the request. Otherwise, the application server B terminates it.
, QID B1 >, the authentication server S authenticates the application server B by performing the following tasks: If the equation holds, then the authentication server S accepts the application server B. Otherwise, the authentication server S terminates it.
authenticates the authentication server S by performing the following tasks: or not. If the equation holds, then the client A accepts the authentication server S. Otherwise, the client A terminates it.
(4) Send < N B , Auth SB , Auth AB > to the application server B.
Step 6. B → A : < Auth BA > Upon receiving < N B , Auth SB , Auth AB >, the application server B authenticates the client A and the authentication server S by performing the following tasks: If the equation holds, then the application server B accepts the authentication server S. Otherwise, the application server B terminates it.
(4) Check whether Auth AB = f 4 (ID A , ID B , U S , K BA ) or not. If the equation holds, then the application server B can be sure that the client A has the ability to compute the session key. Otherwise, the application server B notifies the authentication server S that the authentication has been failed and terminates it. (5) Compute On the other side, upon receiving < Auth BA >, the client A checks whether Auth BA = f 5 (ID A , ID B , U S , K AB , Auth AB ) or not. If the equation holds, the client A can be sure that the application server B has the ability to compute the session key, then the client A computes the session key SK AB = f 6 (ID A , ID B , U S , K AB , Auth AB , Auth BA ). Otherwise, the client A notifies the authentication server S that the authentication has been failed and terminates it. After transferring the messages in the above six steps, the client A and the application server B can authenticate each other via the authentication server S and agree upon the session key. The authentication server S also can compute K AB =ê(s · U A1 + K SA , U SA1 + U SA2 ) or K BA =ê(U SB1 + U SB2 , s · U B1 + K SB ) to compute the session key SK AB = f 6 (ID A , ID B , U S , K AB , Auth AB , Auth BA ) which is shared with the client A and the application server B. The session key is created by the three participants and not created by the authentication server S alone. Therefore, the proposed protocol can solve the problem in the resilience of key control of the KTAP while the authentication server S still can monitor the communication messages to prevent and trace network crime.
In Steps 2 and 4, the correctness of the equations that the authentication server S uses to authenticate the client A and the application server B can be proved by the bilinear pairings feature operation. To the client A as an example, the correctness ofê(P, V A ) =ê(U A1 + QID A1 , W A ) · e P pub , h A · W A + QID A2 in Step 2 is presented as follows: In Step 3, the correctness of the equation that the application server B uses to verify the message sent from the authentication server S. The correctness ofê(V SB , P) =ê U S + h SB · QID S , P pub is presented as follows:ê In Steps 5 and 6, the equations Auth SA and Auth SB that the client A and the application server B use to authenticate the authentication server S, respectively. If K SA = K AS and K SB = K BS , we say that Auth SA and Auth SB are valid, the equations hold because of K SA = s · U A2 = s · r A · QID A2 = r A · DID A2 = K AS and K SB = s · U B2 = s · r B · QID B2 = r B · DID B2 = K BS .
In Step 6, if K AB = K BA , we say that Auth AB and Auth BA are valid. The client A, the application server B and the authentication server S have established a common session key SK AB . The correctness of K AB = K BA is presented as follows:

The Parallel Version
Chen et al. [31] pointed out that to enhance the performance and reduce latency of an AKA protocol, the communication steps in the protocol should be as parallel as possible. To enhance the proposed protocol performance, a parallel version of the protocol is presented. We reordered the steps in the proposed protocol as shown in Figure 3. It can be obviously seen that the steps are reordered but the message exchange contents are the same as those in the preceding protocol. In the parallel version of the proposed protocol, the protocol can be executed in four rounds.

Preventing and Tracing Network Crime
In a distributed computing environment preventing and tracing network crime often consists of mechanisms to prevent, detect and deter security violations that involve the transmission of messages. Authentication, Authorization, Accounting (AAA) services are the commonly used mechanisms to protect the security of networks in distributed computing environments [32][33][34]. The authentication service is the first inspection mechanism that prevents and traces network crime. The authorization service is based on the security primitives of the authentication service. The authentication service and the authorization service are usually performed together to ensure that a client requesting access to the services is in fact the client to whom entry is authorized. It is able to prevent services access by a client that is not authorized and trace which services were accessed by which client. After authentication and authorization, a common session key is constructed using symmetric encryptions. These are most effective techniques to protect transferred messages from being intercepted, disclosed and forged by an adversary. The AAA services also provide accounting services that are used to collect resources usage information for billing. In the generic AAA services, the authentication, authorization and accounting services are provided by an authentication server referred to as AAA server.
The proposed protocol is an ID-based three-party AKA protocol that provides mutual authentication and establishes a common session key between three participants. The authentication server in the proposed protocol is responsible for the authentication of participating entities and restricts access to authorized clients. Both clients and the application servers must send their identities to the authentication server and retrieve the private keys computed by the authentication server in the key extract phase. A client or an adversary without the private key is unable to request and access the services provided by an application server. An application server without the private key is unable to be accepted by the authentication server and the clients. The authentication server needs to authenticate the clients and the application servers but also needs to be authenticated by the clients and the application servers. The proposed protocol is able to prevent unauthorized access and detect, deter an adversary who constructs a forged identity as the real authentication server or application server to acquire useful information from the clients.
The proposed protocol allows three participants to establish a common session key to protect the transferred messages and also ensures the authenticity. The common session key of the proposed protocol is derived from the authentication server, the client and the application server's private keys and their ephemeral secrets in the mutual authentication and key agreement phase. The three participants are able to ensure that no other participants or adversaries can learn or determine the value of the common session key and the authentication server could use the common session key to monitor the transferred messages. The common session key of the proposed protocol is able to protect and guarantee the authenticity of the transferred messages and also trace which client has accessed the services provided by which application server. None of the clients are able to deny that the client has requested and accessed the services provided by the application server.
In the proposed protocol the authentication server provides authentication service, authorization service and uses the common session key to prevent and trace network crime. However, the authentication server does not provide accounting services. The most important aspect in the AAA services is the authentication service and the purpose of the accounting service is to collect information on resource usage for billing, auditing and trend analysis [35][36][37][38]. Hence, the proposed protocol is suitable for various communication systems in the distributed computing environments in terms of protecting the security of network, preventing and tracing network crime.

Security and Performance Analysis
In this Section we discuss the security analysis of the proposed protocol. The simulation results were performed using the AVISPA tool. The methodology used in our performance analysis and the metrics utilized to evaluate the results of the proposed protocol.

Security Analysis
In this Section we present the security analysis of the proposed protocol to show the security attributes required for AKA protocols are satisfied and the simulation results by the AVISPA tool.

Mutual authentication and Ephemeral-Secret-Leakage Resistance.
The proposed protocol adopted Tseng et al.'s ESL-secure ID-AKE protocol [7] to achieve the client-to-server authentication. The authentication server S authenticates the client A and the application server B by checking whetherê(P, V A ) =ê(U A1 + QID A1 , W A ) · e P pub , h A · W A + QID A2 andê(P, V B ) =ê(U B1 + QID B1 , W B ) ·ê P pub , h B · W B + QID B2 or not. To the client A as an example, the message < ID A , The application server B authenticates the authentication server S by checking whether e(V SB , P) =ê U S + h SB · QID S , P pub or not. The message V SB , where V SB = r S · P pub + h SB · DID S , h SB = f 2 (ID A , ID B , U S , U SB1 , U SB2 ) and DID S = s · QID S , can be viewed as a signature on a message < ID A , U S , U SB1 , U SB2 >. Without knowledge of the authentication server S's private key s, none of the participants or adversaries can forge the message and compute a valid signature. To forge a valid message < ID A , U S , U SB1 , U SB2 , V SB >, an adversary must have obtained the authentication server S's private key s from P pub , where P pub = s · P. It is a discrete logarithm problem to the adversary.
The proposed protocol provides the server-to-client authentication that is also based on Tseng et al.'s ESL-secure ID-AKE protocol. The client A and the application server B authenticate the authentication server S by checking whether Auth SA = f 3 (ID A , ID B , U A1 , U A2 , V A , N A , K AS , U S , U SA1 , U SA2 ) and Auth SB = f 3 (ID A , ID B , U B1 , U B2 , V B , N B , K BS , U S , U SB1 , U SB2 ) or not. Even though an adversary could obtain the client A's ephemeral secret r A by the ESL attacks. Since < Auth SA > and < Auth SB > are derived from K SA = s · U A2 = r A · DID A2 = K AS and K SB = s · U B2 = r B · DID B2 = K BS , respectively. To violate the server-to-client authentication, the adversary has to solve the computational Diffie-Hellman problem to obtain DID A2 and the discrete logarithm problem to compute the application server B's ephemeral secret r B and the computational Diffie-Hellman problem to obtain DID B2 from the transferred messages. Otherwise, the adversary only can compute the authentication server S's private key s from P pub , in which the adversary needs to solve the discrete logarithm problem.
The application server B can be sure that the client A has obtained the session key by checking whether Auth AB = f 4 (ID A , ID B , U S , K BA ) or not. The client A checks whether Auth BA = f 5 (ID A , ID B , U S , K AB , Auth AB ) or not to be sure that the application server B also has obtained the session key and both of them with the authentication server S can agree upon the common session key SK AB = f 6 (ID A , ID B , U S , K AB , Auth AB , Auth BA ). For computing a valid message < Auth AB > or < Auth BA >, we assume that the client A's ephemeral secret r A has been compromised by an adversary. Since the messages < Auth AB > and < Auth BA > are derived from K AB =ê r A · P pub + K AS , U SA1 + U SA2 =ê U SB1 + U SB2 , r B · P pub + K BS = K BA , where K AS = r A · DID A2 and K BS = r B · DID B2 , the adversary must solve the computational Diffie-Hellman problem to compute DID A2 or the discrete logarithm problem to compute r B and the computational Diffie-Hellman problem to compute DID B2 from transferred messages. Otherwise, the adversary only can compute the authentication server S's private key s from P pub , in which the adversary needs to solve the discrete logarithm problem.
Without knowledge of the private key of a participant (e.g., the client A's private key DID A ). An adversary cannot impersonate the participant since the adversary is unable to forge a valid signature. The proposed protocol employs the signature to authenticate the participants' identities and one way hash function to protect the integrity of the transferred messages. Even though the ephemeral secret of the client has been compromised, each participant can be sure that none of the adversaries can impersonate other participants to violate the verification procedures and corrupt the participants' private keys and the session key. • Known Key Security. Suppose that an adversary can eavesdrop on the transmitted messages to learn the previous session keys. However, the session key of the proposed protocol is unique and dependent of each participant's ephemeral secrets r A , r B and r S and private keys DID A2 , DID B2 and s. Therefore, knowledge of the previous session keys does not enable the adversary to derive other session keys and does not give the adversary any information that the adversary could use to derive other session keys. Even though the client A's ephemeral secret r A has been compromised. If an adversary would like to compute K AB =ê r A · P pub + K AS , U SA1 + U SA2 , where K AS = r A · DID A2 from the transferred messages, the adversary needs to solve the computational Diffie-Hellman problem to compute the client A's private key DID A2 or the discrete logarithm problem from P pub , where P pub = s · P to obtain the authentication server S's private key s. Otherwise, the adversary only can solve the discrete logarithm problem and the computational Diffie-Hellman problem to compute the application server B's corresponding ephemeral secret r B and private key DID B2 . In the proposed protocol, even if one of the session key has been compromised, the security of the other or future session keys is not endangered. • Partial Forward Secrecy. The proposed protocol session key is dependent on each participant's private key and corresponding ephemeral secret. In the proposed protocol, if the private key of client A or the application server B has been compromised, an adversary also needs to obtain the corresponding ephemeral secrets to compute the session key. Suppose that the adversary would like to compute the corresponding ephemeral secrets from the transferred messages, the adversary needs to solve the discrete logarithm problem. However, if the adversary corrupts the private key s of the authentication server S, it is obvious that all of the previous session keys can be recovered from the transferred messages. Since the adversary is indeed able to compute K SA = s · U A2 , K AB =ê(s · U A1 + K SA , U SA1 + U SA2 ) or K SB = s · U B2 , K BA =ê(U SB1 + U SB2 , s · U B1 + K SB ) and SK AB = f 6 (ID A , ID B , U S , K AB , Auth AB , Auth BA ). The proposed protocol offers partial forward secrecy. • Key-Compromise Impersonation Resilience. To discuss the key-compromise impersonation resilience property, we assume that client A's private key DID A is compromised to an adversary who tries to impersonate the application server B to cheat the client A and the authentication server S. When the client A requests service from the application server B, the adversary only can choose < ID B , U B1 , U B2 , V B , QID B1 > and < Auth BA > from the previous sessions and send them to the authentication server S and the client A, respectively. Since the adversary cannot derive the application server B's private key DID B2 and the corresponding ephemeral secret r B from the transferred messages to compute K BA =ê U SB1 + U SB2 , r B · P pub + K BS , where K BS = r B · DID B2 . The adversary only can violate the verification procedures of the authentication server S. If the adversary tries to derive the ephemeral secret r B and the private key DID B2 from the transferred messages to compute Auth BA = f 5 (ID A , ID B , U S , K BA , Auth AB ) and construct the session key, the adversary needs to solve the discrete logarithm problem and the computational Diffie-Hellman problem. • Unknown Key-Share Resilience. To implement such an attack, the adversary is required to obtain the private key of client A or the application server B. In the proposed protocol, both of the client A and the application server B have to be authenticated by the authentication server S. Only the participant that has the private key distributed from the authentication server S could compute the valid signature and thus pass the verification procedures and compute the session key. To the client A as an example, the client A with its private key DID A and the ephemeral secret r A can compute V A = (r A + DID A1 ) · W A + DID A2 and K AB =ê r A · P pub + K AS , U SA1 + U SA2 to pass the verification procedures of the authentication server S and the application server B. The ephemeral secret r A with DID A2 are able to compute the session key SK AB = f 6 (ID A , ID B , U S , K AB , Auth AB , Auth BA ). Hence, the proposed protocol can withstand an unknown key-shared attack. • Key control Resilience.
In the proposed protocol, the session key SK AB = f 6 (ID A , ID B , U S , K AB , Auth AB , Auth BA ), where K AB =ê r A · P pub + K AS , U SA1 + U SA2 = e U SB1 + U SB2 , r B · P pub + K BS = K BA is determined by all participants' private keys and corresponding ephemeral secrets. None of the participants can force a session key to be predetermined or predict the value and control the outcome of the session key. Hence, the proposed protocol ability to prevent the session key is created only by the authentication server S or other two participants.

Formal Analysis Using AVISPA
Besides the above analysis we also provide a formal analysis of the proposed protocol using AVISPA. AVISPA is a push-button tool which is one of the commonly used automated security validation tools for Internet security-sensitive protocols and applications [19]. AVISPA was developed based on the Dolev-Yao intruder model [35]. In this model, the intruder has full control over the network and the intruder can intercept, inject, analyze and modify messages in transit. In addition, the intruder can play the role of a legitimate participant and gain knowledge of the compromised participant, but he is not allowed to crack the underlying cryptography. The first step in using AVISPA is to implement the analyzed protocol in High-Level Protocol Specification Language (HLPSL) that is an expressive, modular, role-based formal language for security protocol description and specifying their security properties. The HLPSL presentation of the analyzed protocol is translated into a lower level language called Intermediate Format (IF) using HLPSL2IF. IF the analyzed protocol is used as an input to different back-ends, the current version of AVISPA tool comprises four back-ends that implement a variety of automatic analysis techniques, namely, On-the-fly Model-Checker (OFMC), Constraint-Logic-based Attack Searcher (CL-AtSe), SAT-based Model-Checker (SATMC), and Tree Automata based on Automatic Approximations for the Analysis of Security Protocols (TA4SP) [30]. The four back-ends perform the analysis and output the results in precisely defined output format stating whether problems exist in the protocol or not. Thus, AVISPA is appropriate for the analysis of large-scale security protocols and applications.
To evaluate the proposed protocol security using AVISPA, we implemented the proposed protocol using the HLPSL and the role specifications of the client, the application server and the authentication server are given in Appendix A. We simulated the proposed protocol using the AVISPA web tool [36]. The proposed protocol is analyzed in the OFMC and CL-AtSe back-ends. Both of the two back-ends are helpful for the verification of the proposed protocol and detection of attacks. Note that intruder knowledge of the proposed protocol comprises the ephemeral secret r A of the client. After executing the code in AVISPA web tool, both OFMC and CL-AtSe back-ends outputs were generated and shown in Figures 4 and 5. From the simulated results, there are no major attacks to the protocol and the simulated results also confirm the correctness of the protocol security analysis. The security goals of the proposed protocol are achieved and thus the proposed protocol confirms security against various active and passive attacks.

Performance Analysis
In this section, the performance and the simulation results of the proposed protocol are analyzed. For convenience, the following notations are used to analyze the computational cost: • TG e : the execution time for a bilinear pairing operationê : TG mul : the execution time for points in G 1 multiplication operation. • T exp : the execution time for a modular exponential operation in G 2 . • TG H : the execution time for a map-to-point hash function in G 1 . • TG add : the execution time for an addition operation of points in G 1 or a multiplication operation in G 2 . • T H : the execution time for a one-way hash function.
The total computational cost for the client side in this proposed protocol is TG e + 5TG mul + TG H + 3TG add + 4T H . However, the computation in Step 1 of the mutual authentication and key agreement phase for the client side can be pre-computed using offline computation. The total cost for on-line computation on the client side is TG e + 2TG mul + 2TG add + 4T H . The total computational cost for the application server side is 3TG e + 6TG mul + TG H + 4TG add + 5T H . On the other hand, the authentication server side performs Steps 2 and 4 to authenticate the client, the application server and constructs the session key. The total computational cost for the authentication server side is Note that compared with TG add and T H , TG e , TG mul , T exp and TG H are more time-consuming [31]. The proposed protocol adopts an imbalanced computation technique and an online/offline computation technique to reduce the computational load for the client side. From the analysis result mentioned above, the computational burdens are major on the authentication server and the application server which are powerful servers and the offline pre-computation reduces the computational cost required for the client side. Although, bilinear pairing operations are still required for the client side, the proposed protocol captures all basic desirable security attributes including the ESL resistance and the authentication server is able to monitor the transferred messages to prevent and trace network crime. The required computation cost of the proposed protocol is also reasonable.

Software Performance
Scott et al. [37] and Oliveira et al. [38] implemented the related pairing-based operations for low-power computing devices (i.e., smartcards and sensor nodes) in 2006 and 2011, respectively. Scott et al. used the processor on the Philips HiPersmart card offers the maximum clock speed of 36 MHz for related pairing-based operations. Scott et al. pointed out that for the security level of the Ate pairing system, a popular and valid choice would be to use a supersingular curve or non-supersingular curve over a finite field E F p , with p = 512 bits and a large prime order q = 160 bits. The simulations are performed with a simulator implemented in Android system. We used the Jpair library to execute the simulations, which is a Java implementation of bilinear pairings to implement the software and a mobile device (Android 5.0 and 2.3 GHz Intel Atom with 4 GB of RAM) for the client side. Since the Weil pairing evaluation is more time-consuming than the Tate pairing [39], simulations are provided based on the Tate pairing on a supersingular elliptic curve. In the proposed protocol security level, the parameters will be the same as Scott et al.'s experimental data mentioned above. Table 1 lists the simulations data for related pairing-based operations on the client side. The execution time results for the client side have an average of 1000 simulations. Table 2 lists the computational cost and the execution time (in seconds) on the client side, where the execution time is measured using Table 1. The proposed protocol adopts an online/offline computation technique in which the online execution time on the client side requires 0.553 s. Although, the bilinear pairing operations are still required for the client side, the proposed protocol is still efficient and suitable for mobile distributed computing environments.

Conclusions
We proposed an ESL-secure ID-based three-party AKA protocol for mobile distributed computing environments. The proposed protocol employs Tseng et al.'s ESL-secure ID-AKE protocol [7] against ESL attacks. The proposed protocol keeps all of the merits of KTAP regarding security including the authentication server is able to monitor the communication messages to prevent and trace network crime and solves the problems of KTAP in which the session key is only created by the authentication server. Each participant can contribute information to derive the common session key. In the security analysis, the proposed protocol resists ESL attacks and also satisfies the security attributes required for AKA protocols: known-key security, partial forward secrecy, key-compromise impersonation resilience, unknown key-share resilience and key control resilience. In addition, the formal validation of the proposed protocol is performed using an automated validation tool AVISPA. The simulations results show that the proposed protocol is secure against active and passive adversaries. In the performance analysis, the proposed protocol adopted an imbalanced computation technique to shift the computational burden to the powerful servers. The software performance simulation result shows that the mobile client could perform offline pre-computation to reduce the online computation cost. Furthermore, a parallel version of the proposed protocol is proposed to enhance the protocol run performance.
In the future, we will implement the proposed in the "To Say" APP. The "To Say" APP allows users store the last words (text, image, audio, and video) in the application server and send the last words to the designated receivers in a secure channel. The authentication server is responsible for authenticate the users and helps them to construct a common session key with the receivers. When the APP detects the users are not active, the server will automatically send the last words to the designated receivers.