A heterogeneous user authentication and key establishment for mobile client–server environment

Abstract

In a mobile client–server environment, a low-power mobile device wants to access a strong server to get some kind of services. User authentication and key establishment are two basic security requirements for this environment. Without the user authentication, an unauthorized user can access the server and gets the services. Without the key establishment, the communication between the user and the server will be disclosed. Recently, some user authentication and key establishment protocols were designed. However, all of them are homogeneous since the client and the server belong to the same cryptosystem. That is, both the client and the server belong to public key infrastructure or identity-based cryptosystem or self-certified cryptosystem. Such design does not comply with the characteristic of mobile client–server application. In this paper, we design a heterogeneous user authentication and key establishment protocol using a signcryption scheme. In this protocol, the client uses identity-based cryptosystem and the server uses the public key infrastructure. As compared with existing works, our protocol has the lowest cost in computation and communication.

1 Introduction

With the rapid evolvement of wireless communication technology, more and more mobile devices (i.e., mobile telephone and personal digital assistant) are used to access the Internet and to carry out the electronic commerce. A typical network architecture is the Mobile Client–Server (MCS) environment [1]. In this environment, a user (client) with low-power mobile device accesses a strong server to get some kind of services. The MCS architecture has become one of the basic models of mobile network computing. Many types of mobile applications have used the MCS architecture, such as mobile e-mails, mobile web access and mobile social networks [2, 3]. For example, both Facebook and Twitter use the MCS architecture [4]. The security of this architecture plays a pivotal role for users applications [5]. To prevent unauthorized users from accessing the server’s service, we need to authenticate the users. In addition, the transmitted messages between the client and the server may be sensitive. Therefore, a session key is required to be established between them. Hence the user authentication and the key establishment are two basic security requirements for this environment. However, it is not easy to develop such protocols since the computational power of mobile devices and the communication bandwidth are limited. Therefore, we should try our best to reduce the computational task of mobile devices and to shorten exchanged messages.

According to the public key authentication method, the public key cryptosystem can be divided into three types: Public Key Infrastructure (PKI) [6], Identity-Based Cryptosystem (IBC) [7] and Self-Certified (certificateless) Cryptosystem (SCC) [8]. In the PKI, each user sets a private key and a matching public key. A Certificate Authority (CA) issues a digital certificate to authenticate this public key because this certificate binds the user identity and the public key. The PKI may not be a good candidate for the mobile communication since the certificates management (i.e., generation, distribution, use, query, storage and revocation) is too heavy for the low power mobile devices. In the IBC, a user selects a binary string as its public key. A trusted party called Private Key Generator (PKG) computes the corresponding private key using the binary string and a master key. The merit of the IBC is that we can explicitly check the validity of a public key without an attached certificate. So the IBC is very lightweight and is a good candidate for wireless communication. However, the flaw of IBC is that the PKG holds anyone’s private key [7]. Therefore, the IBC only fits the small-scale networks and does not fit the large-scale networks, for instance the Internet. In the SCC, the PKG first computes a partial private key using the identity information and a master key. Then the user sets its full private key by uniting the partial private key and a chosen secret value. The SCC eliminates both certificates and key escrow problem.

Yang and Chang [9] gave an Identity-Based Authentication Protocol (IBAP) with key agreement using Elliptic Curve Cryptography (ECC) technique. The ECC can use a smaller key size to achieve a comparable security level to the other cryptographic scheme such as RSA [10]. However, Yoon and Yoo [11] showed that [9] can not satisfy the authentication property by launching an impersonation attack. Chou et al. [12] designed two IBAPs with key agreement. The first protocol sets up a session key between the client and server and the second protocol sets up a session key between two users. Farash and Attari [13] (hereafter called FA) showed that [12] is not secure under the impersonation attack and gave an improvement. Shi et al. [14] pointed out a weakness in the registration phase of [12, 13]. In this weakness, an authorized user is able to impersonate the server to generate a correct private key for the other users. Qi and Chen [15] solved the clock synchronization issue in the authentication key exchange by applying the challenged-response handshake method.

Wu and Tseng [16] (hereafter called WT) designed an Identity-Based User Authentication Protocol (IBUAP) with key exchange for MCS environment using bilinear pairings. The WT reduces the computational cost of the client by transferring the computation to the powerful server. He [17] (hereafter called He) further improved the performance of WT. In addition, He et al. [18] (hereafter called HCH) gave an IBUAP with key agreement for MCS environment without using MapToPoint function. The MapToPoint is a special hash function that maps an identity into a point on an elliptic curve and is slower than a general hash function. Unfortunately, Wang and Ma [19] pointed out that HCH is vulnerable to the reflection attack and parallel session attack. Hassan et al. [20] gave a SCC-based user authentication and key exchange protocol for the MCS environment.

Chuang and Tseng [21] (hereafter called CT) gave an IBUAP for mobile multi-server environment. The multi-server means that there are multiple servers. Many organizations, such as a university, a company and a hospital may have multiple servers that include a file server, an e-mail server, a web server, etc. The multi-server environment introduces a Registration Center (RC) that is in charge of the registration of clients. If a client has registered at the RC, it can access the multiple servers. Such an approach avoids repeated registration at every server. Liao and Hsiao [22] (hereafter called LH) designed a SCC-based authentication protocol for mobile multi-server environment. However, Hsieh and Leu [23] (hereafter called HL) pointed out that LH is not secure under the trace attack and presented an improvement.

From the above discussion, we know that all user authentication and key establishment protocols are homogeneous since the client and the server belong to the same cryptosystem. That is, both the client and the server belong to PKI or IBC or SCC. Such design does not conform to the characteristic of MCS environment. The characteristic of MCS is that the client is weak and the server is strong. Therefore, a good method is that the client uses the IBC and the server uses the PKI. Such design requires our protocol is heterogeneous. In this paper, we design a heterogeneous user authentication and key establishment protocol using a signcryption scheme. In this protocol, the client belongs to the IBC and the server belongs to the PKI. As compared with previous related protocols, our protocol has the least computational cost and communication overhead.

2 Preliminaries

In this section, we give the network model and bilinear pairings.

2.1 Network model

Figure 1 gives the overview of the MCS model. The model consists of three kinds of entities, a RC, a server and some clients. The clients want to access the server to get some kinds of services by WiFi, 3G or 4G wireless communication technique. The RC is in charge of the registration for clients and the server. That is, the RC acts as the role of the PKG in the IBC and the CA in the PKI. The clients are low-power and the server is powerful. Of course, the low-power devices are a relative and evolving process. For example, mobile phones are low-power devices 10 years ago, but now they are getting stronger and stronger. Sensors, wearable devices [24], smart meters are low-power now, but they may become powerful in the future. We assume that the RC is believable and can never be compromised. When a client hopes to access the server, it will send an authentication message to the server and the server will verify the client has been authorized or not. If the client has been authorized, a session key will be established between them. Otherwise, the server will send a rejection message to the client. If the RC is compromised, the adversary can learn the private keys of clients and forge the certificate of the server. So it is a basic assumption that the RC can not be attacked. In addition, the key escrow problem exists since the RC learns the private keys of clients. To mitigate the RC compromise and key escrow problem, we can use distributed RC [7].

Fig. 1

Network model

There are two main security goals for the MCS environment. The first goal is the authentication that assures that only authorized clients can access the server. The second goal is the key establishment that sets up a session key between a client and the server.

Table 1 Notations

2.2 Bilinear pairings

Let $G_1$ be a additive cyclic group (the generator is P) and $G_2$ be a multiplicative group. Both groups have the same prime order p. A bilinear pairing is a special map ${\hat{e}}:G_1 \times G_1 \rightarrow G_2$ that satisfies the following properties [7]:

• 1. Bilinearity${\hat{e}}(aP,bQ)={\hat{e}}(P,Q)^{ab}$ holds for all elements $P,Q\in G_1$ and $a,b\in {\mathbb{Z}}_p^*$.

• 2. Non-degeneracy${\hat{e}}(P,Q)\ne 1_{G_2}$ ($1_{G_2}$ is the identity element of $G_2$) holds for some $P,Q \in G_1$.

• 3. Computability${\hat{e}}(P,Q)$ can be efficiently implemented for all P,$Q \in G_1$.

The modified Weil pairing and Tate pairing can supply such maps [7].

3 Our protocol

In this section, we design a heterogeneous user authentication and key establishment protocol using Li et al.’s signcryption (hereafter called LZT) [25]. Our protocol has four phases: initialization, registration, authentication and key establishment, and revocation. The main notations in our protocol are summarized in Table 1.

3.1 Initialization phase

Given a security parameter sp, RC selects $(G_1,G_2,p,{\hat{e}},P)$ defined in Sect. 2.2 and three secure hash functions $H_1:\{0,1\}^{\ell _3+\ell _4}\rightarrow {\mathbb{Z}}_p^*$, $H_2:G_2\rightarrow \{0,1\}^{\ell _1+\ell _2+\ell _3+\ell _4}$ and $H_3:\{0,1\}^{\ell _1+\ell _2+\ell _3+\ell _4+\ell _5}\rightarrow {\mathbb{Z}}_p^*$. Then the RC selects a master key $s\in {\mathbb{Z}}_p^*$ and sets the public key $P_{pub}=sP$ and $g={\hat{e}}(P,P)$. Finally, the RC releases the system parameters $\{p,G_1,G_2,{\hat{e}},P,g,P_{pub},H_1,H_2,H_3\}$ and retains s secret.

3.2 Registration phase

The clients and the server should register at the RC. For the registration of a client, the client first submits its identity ID to the RC. Then the RC sets an expiration date ED, computes the private key

$$\begin{aligned} S_{ID}=\frac{1}{H_1(ID||ED)+s}P \end{aligned}$$

and sends $(S_{ID},ED)$ to the client in a secure way. Similar to [16], we can adopt off-line approach or on-line Transport Layer Security (TLS) approach to deliver the private key. The registration process of the client is summarized in Fig. 2.

Fig. 2

Registration process of a client

For the registration of the server, the server first chooses a random w from ${\mathbb{Z}}_p^*$ and sets $SK=(1/w)P$ as its private key and $PK=wP$ as its public key. Then the server submits its identity and public key PK to the RC. The RC generates a digital certificate Cert for the server by using a digital signature algorithm (here we recommend using Elliptic Curve Digital Signature Algorithm (ECDSA) [26]). Finally, the RC sends the digital certificate to the server. Note that the digital certificate can be delivered in an open channel. The registration process of the server is summarized in Fig. 3.

Fig. 3

Registration process of the server

Fig. 4

Authentication and key establishment process

3.3 Authentication and key establishment phase

When a client with identity ID wants to access the server to get some kind of services, the client first randomly chooses a session key $k\in \{0,1\}^{\ell _1}$ and $x\in {\mathbb{Z}}_p^*$. Then the client computes $r=g^x$, $c=(k||TS||ID||ED)\oplus H_2(r)$, $h=H_3(k||TS||ID||ED||r)$, $S=(x+h)S_{ID}$ and $T=xPK$. Here TS is a timestamp to resist the replay attack. Note that we encrypt the client’s identity to achieve the anonymity. The client sends (c, S, T) to the server. After receiving the (c, S, T), the server first computes $r={\hat{e}}(T,SK)$ and $k||TS||ID||ED=c\oplus H_2(r)$. Then the server computes $h=H_3(k||TS||ID||ED||r)$ and checks if the

$$\begin{aligned} r={\hat{e}}(S,H_1(ID||ED)P+P_{pub})g^{-h} \end{aligned}$$

holds. If the above equation holds, the server accepts the client’s access request. A session key k has been established between the client and the server. The k is only known by them, which guarantees the confidentiality for future communication. Otherwise, the server rejects the client’s access request. If we hope to achieve the key confirmation property, the server computes $tag=MAC_k(TS)$ and sends to the client. When receiving the tag, the client computes $tag'=MAC_k(TS)$ and checks if $tag'=tag$. If yes, the client believes that the server has known the session key k. We summarize the above process in Fig. 4.

Fig. 5

Modified authentication and key establishment process

We have two methods to establish a session key: key exchange and key transport. The key exchange protocol allows the both parties to jointly decide the session key. The key transport protocol allows one party to decide the session key and to transfer to the other party. Obviously, our protocol is a key transport protocol. However, our protocol can be easily modified into a key exchange type. The server needs to choose a random $k^*$ from $\{0,1\}^{\ell _1}$, computes $tag=MAC_{k\oplus k^*}(TS)$ and sends $(tag,k^*)$ to the client. The client computes $tag'=MAC_{k\oplus k^*}(TS)$ and checks if $tag'=tag$. In this case, the session key is $k\oplus k^*$. We summarize the modified process in the Fig. 5.

3.4 Revocation phase

We can automatically revoke the registration right by attaching an expiration date ED. For instance, if we set the ED as “2018-12-31”, the client only can access the server before December 31, 2018. If we must revoke the privilege before this date due to some irresistible reasons, the RC can send the identity of this client to the server. The server stores a list of revoked identities so that it can check if the privilege has expired.

4 Analysis of the protocol

In this section, we analyze the correctness, security and performance of the designed protocol.

4.1 Correctness

We show the correctness of our protocol. That is, if the server receives the message (c, S, T), it can authenticate the client correctly and establish the session key.

Since $T=xPK$, $PK=wP$ and $SK=\frac{1}{w}P$, we have

$$\begin{aligned} {\hat{e}}(T,SK)&= {} {\hat{e}}\left( xPK,\frac{1}{w}P\right) ={\hat{e}} \left( xwP,\frac{1}{w}P\right) ={\hat{e}}(P,P)^x \\&= {} g^x=r \end{aligned}$$

In addition, because $S=(x+h)S_{ID}$ and $S_{ID}=\frac{1}{H_1(ID||ED)+s}P$, we have

$$\begin{aligned}&{\hat{e}}\left( S,H_1(ID||ED)P+P_{pub}\right) g^{-h} \\&\quad ={\hat{e}}\left( \frac{x+h}{H_1(ID||ED)+s}P,(H_1(ID||ED)+s)P\right) g^{-h} \\&\quad =g^{x+h}g^{-h}\\&\quad =g^x\\&\quad =r \end{aligned}$$

4.2 Security

Our protocol is based on LZT signcryption that satisfies confidentiality under the bilinear Diffie–Hellman inversion problem and unforgeability under the q-strong Diffie–Hellman problem [25]. Now we prove our protocol in the authenticated key agreement model [27,28,29,30].

The model has a set of participants that are modeled by some oracles. We use the notation $\prod _{i,j}^\tau$ to denote that a participant i believes that it is carrying out the $\tau$-th run of the protocol with a participant j. The model also contains an adversary ${\mathcal{A}}$ that can access all message flows in this system. ${\mathcal{A}}$ even can relay, modify and delete messages. All the oracles can communicate with each other by ${\mathcal{A}}$. In order to answer ${\mathcal{A}}$’s queries, oracles keep transcripts that record all messages they have sent or received. Note that ${\mathcal{A}}$ is neither a participant nor the PKG (CA). If ${\mathcal{A}}$ does not modify the messages and just transfer the messages, we call the adversary passive. At any time, the adversary is permitted to ask the following queries.

Create${\mathcal{A}}$ chooses an identity ID and sets up a new participant (oracle). The participant’s public key is the identity and the corresponding private key is gained from the PKG.

Send${\mathcal{A}}$ sends a chosen message to an oracle i, $\prod _{i,j}^\tau$, in which case the participant i assumes that the message cames from the participant j. In addition, ${\mathcal{A}}$ can instruct the oracle j to start a new run of this protocol with i by sending an empty message $\lambda$. If the first message that an oracle receives is an empty message $\lambda$, the oracle is called an initiator oracle. Otherwise, the oracle is called a responder oracle.

Reveal${\mathcal{A}}$ is permitted to ask an oracle to obtain the session key (if any) it currently holds.

Corrupt${\mathcal{A}}$ is permitted to ask an oracle to gain its long term private key.

An oracle has one of the following several states:

Accepted After receiving the properly messages, the oracle makes up its mind to accept a session key.

Rejected If an oracle has not set up a session key, it decides to reject and to abort this run of the protocol.

* If an oracle has not made up its mind whether to accept or reject, the state of this oracle is *.

Opened If an oracle has replied a reveal query, the state is opened.

Corrupted If an oracle has replied a corrupt query, the state is corrupted.

At some point, ${\mathcal{A}}$ can choose one of these oracles, such as $\prod _{i,j}^\tau$, to ask a Test query. The chosen oracle must be accepted, be unopened and neither i nor j has been corrupted. In addition, there must be no opened oracle $\prod _{j,i}^\tau$ with which it has had a matching conversation. To reply this query, the oracle flips a fair coin $\beta \in \{0,1\}$. If $\beta =0$, then the oracle replies the held session key. Otherwise, the oracle replies a random key from the given key space.

To attack a protocol, ${\mathcal{A}}$ runs an experiment with the set of oracles generated by a challenger ${\mathcal{C}}$. In this experiment, ${\mathcal{A}}$ can make a polynomially bounded number of Create, Send, Reveal, Corrupt queries and one Test query. In the end, ${\mathcal{A}}$ gives a bit $\beta '$ as its guess for $\beta$.

We use Adv$({\mathcal{A}})=|\mathrm{Pr}[\beta '=\beta ]-1/2|$ to denote ${\mathcal{A}}$’s advantage, where $\mathrm{Pr}[\beta '=\beta ]$ is the probability that $\beta '=\beta$.

Definition 1

If an authenticated key agreement protocol fulfils the following three terms, we say that this protocol is secure [28].

• 1. In the presence of a passive attacker on $\prod _{i,j}^\tau$ and $\prod _{j,i}^\upsilon$, both oracles always accept possessing the same session key. In addition, this key is uniformly distributed in the given key space.

• 2. For each adversary, if uncorrupted oracles $\prod _{i,j}^\tau$ and $\prod _{j,i}^\upsilon$ have matching conversations, both oracles accept and possess the same session key.

• 3. For each adversary, Adv$({\mathcal{A}})$ is negligible.

Now we give the security result of our protocol by the following Theorem 1.

Theorem 1

Our protocol is a secure key establishment protocol.

Proof

In this proof, we show that our protocol satisfies the three terms in Definition 1.

First, our protocol uses LZT signcryption to transfer a session key. Because LZT satisfies the consistency, the server must obtain the same session key as the client. In addition, the session key is randomly selected from the key space $\{0,1\}^{\ell _1}$. Therefore, the first condition holds.

Second, because the consistency constraint of LZT, uncorrupted oracles $\prod _{i,j}^\tau$ and $\prod _{j,i}^\upsilon$ that have matching conversations must accept and possess the same session key. Therefore, the second condition holds.

Third, we show the third condition holds by contradiction. If there exists an attacker ${\mathcal{A}}$ that has a non-negligible advantage $\epsilon$ against the security of Definition 1 in our protocol, then we can either construct an algorithm ${\mathcal{C}}_1$ to break the unforgeability of LZT with a non-negligible advantage $\epsilon _1'\ge (\epsilon -\epsilon _2'mn\phi )/mn$ or construct an algorithm ${\mathcal{C}}_2$ to break the confidentiality of LZT with a non-negligible advantage $\epsilon _2'\ge (\epsilon -\epsilon _1'mn)/mn\phi$. Our proof method comes from [31].

We finish this proof by two parts. In the first part, if an event E (explained later) occurs, ${\mathcal{C}}_1$ is constructed. In the second part, if the event E does not occur, ${\mathcal{C}}_2$ is constructed. Let $\{ID_1,ID_2,\ldots ,ID_m\}$ be set of m clients and $\{S_1,S_2,\ldots ,S_n\}$ be set of n servers. We assume that each client is activated at most $\phi$ times and each server is activated at most $\mu$ times by ${\mathcal{A}}$.

In the first part, if there exists an attacker ${\mathcal{A}}$ that can distinguish a random value from a session key in a time $t_1$, we can construct an algorithm ${\mathcal{C}}_1$ that can break the confidentiality of LZT in a time

$$\begin{aligned} t_1'\le t_1+n\mu t_s+m\phi t_u \end{aligned}$$

where $t_s$ and $t_u$ are the response times for the signcryption and unsigncryption queries, respectively. ${\mathcal{C}}_1$ acts as ${\mathcal{A}}$’s challenger and runs ${\mathcal{A}}$ as a subroutine. The goal of ${\mathcal{C}}_1$ is to output a valid signcryption ciphertext $(c^*,S^*,T^*)$ between a client $ID_A$ and a server $S_B$. The input of ${\mathcal{C}}_1$ includes system parameters and key pairs of n servers in this protocol except the $S_B$’s private key. ${\mathcal{C}}_1$ wins its game only if the target session selected by ${\mathcal{A}}$ is a session between $ID_A$ and $S_B$. ${\mathcal{A}}$ can ask the following queries and ${\mathcal{C}}_1$ keeps a state list $L_s$ that records internal state information.

Create${\mathcal{A}}$ chooses an identity $ID_i$ and asks a Create query. In this case, ${\mathcal{C}}_1$ asks its key extraction oracle with an input $ID_i$ and obtains the corresponding private key $S_{ID_i}$. Note that if $ID_i=ID_A$, ${\mathcal{C}}_1$ will fail since its key extraction oracle can not output a correct private key.

Corrupt${\mathcal{A}}$ asks a Corrupt query on $ID_i$ or $S_j$. If $ID_i\ne ID_A$, ${\mathcal{C}}_1$ can answer it because ${\mathcal{C}}_1$ knows the private key $S_{ID_i}$. If $S_j\ne S_B$, ${\mathcal{C}}_1$ also can answer it because ${\mathcal{C}}_1$ knows the private key $SK_j$. Otherwise, ${\mathcal{C}}_1$ fails and stops. ${\mathcal{C}}_1$ should set the states of corrupted oracles Corrupted.

Send From Create and Corrupt, we learn that ${\mathcal{C}}_1$ knows private keys of all parties except $ID_A$ and $S_B$. Therefore, if ${\mathcal{A}}$ asks a Send query that does not relate to $ID_A$ and $S_B$, ${\mathcal{C}}_1$ answers it in the straightforward way since ${\mathcal{C}}_1$ knows their private keys. For a Send query that needs the private keys of $ID_A$ and $S_B$, ${\mathcal{C}}_1$ answers it using its own oracles. We explain the method below. When ${\mathcal{A}}$ asks a Send ($\prod _{A,j}^\tau$) query with input an empty message $\lambda$, ${\mathcal{C}}_1$ randomly chooses a session key k and asks its signcryption oracle with input a message $k||TS||ID_A||ED$ and a public key $PK_j$ to obtain a ciphertext $\sigma =(c,S,T)$. ${\mathcal{C}}_1$ returns $\sigma$ to ${\mathcal{A}}$ and inserts $(\tau ,A,j,k||TS||ID_A||ED,\sigma ,*)$ into the state list $L_s$. When ${\mathcal{A}}$ asks a Send ($\prod _{B,i}^\tau$) query with input a ciphertext $\sigma$, ${\mathcal{C}}_1$ asks its unsigncryption oracle with input the ciphertext $\sigma$ and identity $ID_i$. If it obtains a k||TS||ID||ED from its unsigncryption oracle, ${\mathcal{C}}_1$ marks the oracle $\prod _{B,i}^\tau$ as accepted, inserts

$$\begin{aligned} (\tau ,B,i,k||TS||ID||ED,\sigma ,Accepted) \end{aligned}$$

in the list $L_s$ and returns $tag=MAC_k(TS)$ to ${\mathcal{A}}$. If the unsigncryption oracle outputs a failure symbol $\bot$, this session is not accepted. ${\mathcal{C}}_1$ returns Rejected to ${\mathcal{A}}$ and inserts $(\tau ,B,i,\bot ,\sigma ,Rejected)$ into the list $L_s$. When ${\mathcal{A}}$ asks a Send ($\prod _{A,j}^\tau$) query with input an message tag, ${\mathcal{C}}_1$ checks if there exists an entry

$$\begin{aligned} (\tau ,A,j,k||TS||ID_A||ED,\sigma ,*) \end{aligned}$$

in the list $L_s$. If none is found, ${\mathcal{C}}_1$ marks the oracle $\prod _{A,j}^\tau$ as rejected and inserts $(\tau ,A,j,\bot ,\bot ,Rejected)$ in the $L_s$. Otherwise, ${\mathcal{C}}_1$ further computes $tag'=MAC_k(TS)$ and checks if $tag'=tag$. If no, ${\mathcal{C}}_1$ marks the oracle $\prod _{A,j}^\tau$ as rejected and updates $(\tau ,A,j,k||TS||ID_A||ED,\sigma ,*)$ into

$$\begin{aligned} (\tau ,A,j,k||TS||ID_A||ED,\sigma ,Rejected). \end{aligned}$$

If yes, ${\mathcal{C}}_1$ marks the oracle $\prod _{A,j}^\tau$ as accepted and updates

$$\begin{aligned} (\tau ,A,j,k||TS||ID_A||ED,\sigma ,*) \end{aligned}$$

into $(\tau ,A,j,k||TS||ID_A||ED,\sigma ,Accepted)$.

Reveal When ${\mathcal{A}}$ asks a Reveal query on the oracle $\prod _{i,j}^\tau$, ${\mathcal{C}}_1$ checks if there exists an entry for $(\tau ,i,j)$ in the list $L_s$. Because a Reveal query can be asked only if a session has been accepted, the list $L_s$ must contain an entry for $(\tau ,i,j)$. Otherwise, this query is not valid. When ${\mathcal{C}}_1$ finds this entry, ${\mathcal{C}}_1$ returns the corresponding session key k and updates

$$\begin{aligned} (\tau ,i,j,k||TS||ID_i||ED,\sigma ,Accepted) \end{aligned}$$

into $(\tau ,i,j,k||TS||ID_i||ED,\sigma ,Opened)$.

In the end of this simulation, ${\mathcal{C}}_1$ checks if there is an entry $(\tau ,B,A,k||TS||ID_A||ED,\sigma ,Accepted)$ such that no entry contains $(\tau ,A,B)$. If yes, ${\mathcal{C}}_1$ outputs its forgery $\sigma ^*=\sigma$. Let E be the event that ${\mathcal{A}}$ asked a Send ($\prod _{B,A}^\tau$) query with input an ciphertext $\sigma ^*$ such that $\sigma ^*$ is a valid ciphertext under $ID_A$ and $PK_B$ and $\sigma ^*$ is not a response of Send ($\prod _{A,B}^\tau$) query with input an empty message $\lambda$. If the event E occurs, ${\mathcal{C}}_1$ must find a wanted entry in the list $L_s$ and successfully output a forgery.

If ${\mathcal{A}}$ stops its run without selecting a test session between $ID_A$ and $S_B$ or the event E does not occurs, ${\mathcal{C}}_1$ will fail. The probability that ${\mathcal{A}}$ selects a test session with $ID_A$ as initiator and $S_B$ as responder is 1 / mn. Therefore, the advantage of ${\mathcal{C}}_1$ is

$$\begin{aligned} \epsilon _1'\ge \frac{\mathrm{Pr}[E]}{mn} \end{aligned}$$

To answer the Send ($\prod _{A,j}^\tau$) queries, ${\mathcal{C}}_1$ needs to ask its signcryption oracle. The maximum number of such queries is $n\mu$. In addition, To answer the Send ($\prod _{B,i}^\tau$) queries, ${\mathcal{C}}_1$ needs to ask its unsigncryption oracle. The maximum number of such queries is $m\phi$. Therefore, ${\mathcal{C}}_1$ can forge a ciphertext in a time

$$\begin{aligned} t_1'\le t_1+n\mu t_s+m\phi t_u \end{aligned}$$

In the second part, we assume that there exists an attacker ${\mathcal{A}}$ that can distinguish a random value from a session key in a time $t_2$ when the event E does not occur. By using ${\mathcal{A}}$ as a subroutine, we can construct an algorithm ${\mathcal{C}}_2$ in a time

$$\begin{aligned} t_2'\le t_2+n\mu t_s+m\phi t_u \end{aligned}$$

The input of ${\mathcal{C}}_2$ includes system parameters, master secret key s, and key pairs of n servers in this protocol except the private key of $S_B$. The goal of ${\mathcal{C}}_2$ is to break the confidentiality of LZT created for $S_B$ by any user in $\{ID_1,ID_2,\ldots ,ID_m\}$ using ${\mathcal{A}}$ as a subroutine.

${\mathcal{C}}_2$ returns a sender’s identity $ID_A$ and a random message $k||TS||ID_A||ED$ to its challenger. The challenger gives ${\mathcal{C}}_2$ a ciphertext $\sigma ^*$ (computed by LZT) as the challenge. ${\mathcal{C}}_2$ randomly selects $\rho \in \{1,2,\ldots ,\mu \}$. With this selection, ${\mathcal{C}}_2$ tries to guess ${\mathcal{A}}$’s selection of the target session. ${\mathcal{C}}_1$ keeps a state list $L_s$ that records internal state information. Now we show that how ${\mathcal{C}}_2$ answers ${\mathcal{A}}$’s queries.

Since ${\mathcal{C}}_2$ knows all private keys except $S_B$, ${\mathcal{C}}_2$ can answer all queries except for the oracle $S_B$. For the queries that needs the private key of $S_B$, ${\mathcal{C}}_2$ uses its oracles. We explain these below.

Create${\mathcal{A}}$ chooses an identity $ID_i$ and asks a Create query. In this case, ${\mathcal{C}}_2$ can use the master secret key s to compute private key $S_{ID_i}$.

Corrupt${\mathcal{A}}$ asks a Corrupt query on $ID_i$ or $S_j$. ${\mathcal{C}}_2$ can answer the query for $ID_i$ because ${\mathcal{C}}_2$ know the private key $S_{ID_i}$. If $S_j\ne S_B$, ${\mathcal{C}}_1$ also can answer it because ${\mathcal{C}}_2$ knows the private key $SK_j$. Otherwise, ${\mathcal{C}}_2$ fails and stops. ${\mathcal{C}}_2$ should set the states of corrupted oracles Corrupted.

Send From Create and Corrupt, we know that ${\mathcal{C}}_2$ knows private keys of all parties except $S_B$. Therefore, if ${\mathcal{A}}$ makes a Send query that does not involves $S_B$, ${\mathcal{C}}_2$ can answer it in the straightforward way because ${\mathcal{C}}_2$ knows their private keys. For a Send query that needs the private key of $S_B$, ${\mathcal{C}}_2$ answers it using its own oracles. When ${\mathcal{A}}$ asks a Send ($\prod _{B,i}^\tau$) query with input an ciphertext $\sigma$, ${\mathcal{C}}_2$ asks its unsigncryption oracle with input the ciphertext $\sigma$ and identity $ID_i$. If it obtains a $k||TS||ID_i||ED$ from its unsigncryption oracle, ${\mathcal{C}}_2$ marks the oracle $\prod _{B,i}^\tau$ as accepted, inserts $(\tau ,B,i,k||TS||ID_i||ED,\sigma ,Accepted)$ in the list $L_s$ and returns $tag=MAC_k(TS)$ to ${\mathcal{A}}$. If the unsigncryption oracle outputs a failure symbol $\bot$, this session is not accepted. ${\mathcal{C}}_2$ returns Rejected to ${\mathcal{A}}$ and inserts $(\tau ,B,i,\bot ,\sigma ,Rejected)$ into the list $L_s$.

Reveal When ${\mathcal{A}}$ asks a Reveal query on the oracle $\prod _{i,j}^\tau$, ${\mathcal{C}}_2$ checks if there is an entry for $(\tau ,i,j)$ in the list $L_s$. If yes, ${\mathcal{C}}_2$ returns the corresponding session key k and updates $(\tau ,i,j,k||TS||ID_i||ED,\sigma ,Accepted)$ into $(\tau ,i,j,k||TS||ID_i||ED,\sigma ,Opened)$. Otherwise, the query is considered invalid.

If ${\mathcal{A}}$ asks a Send ($\prod _{A,B}^\rho$) query with an empty message $\lambda$, ${\mathcal{C}}_2$ chooses two equal length messages $k_0$ and $k_1$ and submits $(k_0||TS||ID_A||ED,k_1||TS||ID_A||ED,ID_A)$ to its challenge oracle to get a challenge ciphertext $\sigma ^*$. ${\mathcal{C}}_2$ returns $\sigma ^*$ to ${\mathcal{A}}$. Now, ${\mathcal{A}}$ can choose the $\prod _{A,B}^\rho$ session or a matching session established by Send ($\prod _{B,A}^\rho$) query with input an ciphertext $\sigma ^*$ as its target session.

If ${\mathcal{A}}$ chooses the above two session as the test session as expected by ${\mathcal{C}}_2$, ${\mathcal{C}}_2$ returns $k_\beta$ to ${\mathcal{A}}$. In the end of this game, ${\mathcal{A}}$ outputs its guess $\xi$. If $\xi =0$, ${\mathcal{C}}_2$ outputs $\beta =0$ that implies $k_\beta$ is a real session key and $\sigma ^*$ is a ciphertext of $k_\beta ||TS||ID_A||ED$. Otherwise $\beta =1$ is returned.

If the event E occurs, ${\mathcal{A}}$ may win this game without selecting the session in which the challenge ciphertext $\sigma ^*$ is injected, as the test session. In the case, ${\mathcal{A}}$ has no advantage. Further, when the event E occurs or ${\mathcal{A}}$ selects a different session other than the one wanted by ${\mathcal{C}}_2$ as the test session, ${\mathcal{C}}_2$ outputs a random bit $\beta$ with a probability 1 / 2.

The probability that ${\mathcal{A}}$ selects a test session $\rho$ with $ID_A$ as initiator and $S_B$ as responder is $1/mn\phi$. Therefore, the advantage of ${\mathcal{C}}_2$ is

$$\begin{aligned} \epsilon _2'\ge \frac{\mathrm{Pr}[{\mathcal{A}}\,\text{wins the game}|\bar{E}]}{mn\phi } \end{aligned}$$

To answer the Send ($\prod _{B,i}^\tau$) queries, ${\mathcal{C}}_2$ needs to ask its unsigncryption oracle. The maximum number of such queries is $m\phi -1$. Therefore, the running time of ${\mathcal{C}}_2$ is

$$\begin{aligned} t_2'\le t_2+(m\phi -1) t_u \end{aligned}$$

According to the theorem of total probability, ${\mathcal{A}}$’s advantage is

$$\begin{aligned} \mathrm{Pr}[{\mathcal{A}}\,\mathrm{wins}]&= {} \mathrm{Pr} [{\mathcal{A}}\,\mathrm{wins}|E]\mathrm{Pr}[E]+\mathrm{Pr}[{\mathcal{A}} \,\mathrm{wins}|\bar{E}]\mathrm{Pr}[\bar{E}] \\&\le {} \mathrm{Pr}[E]+\mathrm{Pr}[{\mathcal{A}}\,\mathrm{wins}|\bar{E}]\\&\le {} \epsilon _1'mn+\epsilon _2'mn\phi \end{aligned}$$

Therefore, we have $\epsilon _1'\ge (\epsilon -\epsilon _2'mn\phi )/mn$ and $\epsilon _2'\ge (\epsilon -\epsilon _1'mn)/mn\phi$. Since LZT satisfies the confidentiality and unforgeability, $\epsilon _1'$ and $\epsilon _2'$ are negligible. Therefore, the advantage of ${\mathcal{A}}$ is also negligible. □

Table 2 Performance comparison

We summarize the security properties of our protocol as follows.

• User authentication Since the client signcrypts the message k||TS||ID||ED, the server can explicitly authenticate the client. Without a valid private key $S_{ID}$, anyone can not generate a (c, S, T) that makes the server to accept it. In addition, the server authenticates itself to the client by using tag.

• Key authentication Since the client signcrypts the message k||TS||ID||ED, the server can believe that k is computed by the client. So our protocol supplies explicit key authentication of the client to the server. In addition, only the server can unsigncrypt the ciphertext (c, S, T) to obtain the session key k and send the $tag=MAC_k(TS)$. Our protocol also supplies explicit key authentication of the server to the client.

• Key establishment A client and the server share a session key k or $k\oplus k^*$. Without the server’s private key SK, anyone can not derive the r to get session key k or $k\oplus k^*$.

• Key confirmation Since the client signcrypts the message k||TS||ID||ED, the server can conceive that the client has possessed the session key k. Our protocol provides the key confirmation of the client to the server. In addition, the client checks if $tag'\buildrel ?\over =tag$. If the client accepts this session, the client can believe that the server has possessed the session key k. So our protocol provides the key confirmation of the server to the client.

• Anonymity Since the client’s identity information is encrypted using $H_2(r)$, the anonymity of the client is obtained.

4.3 Performance

We compare the major computational cost and communication overhead of our protocol with those of existing seven authentication and key establishment protocols for MCS environment in Table 2 (Here we only consider the authentication and key establishment phase and ignore the other phases). We represent Pairing Computation by PC, Point Multiplication in $G_1$ by PM and Exponentiation Computation in $G_2$ by EC. We ignore the other operations in this comparison since the above three operations consume the most running time of the whole algorithm. We denote the number of bits of x by |x|. In FA, WT, He, HCH, LH and HL, the expiration date ED is not considered. For the fair comparison, we add the ED in the communication overhead column for the six protocols. From Table 2, we find that our protocol has the lowest cost in computation and communication.

In order to more clearly demonstrate our protocol, we give a quantitative comparison for FA, WT, He, HCH, CT, LH, HL and our protocol. We use JPBC Type A pairing [32] in our analysis. The Type A pairing is constructed on the elliptic curve

$$\begin{aligned} y^2\equiv (x^3+x) \bmod q \end{aligned}$$

with some prime numbers $q\equiv 3 \bmod 4$, where the embedding degree is two and the order of $G_1$ is p. Here we use three types of parameters which represents the 80-bit, 112-bit and 128-bit key size security levels, respectively. Table 3 describes the size of q and p for the three security levels.

Table 3 The size of q and p for the three security levels (bits)

Figures 6 and 7 respectively give the computational time of the client and the server for the eight protocols at the three security levels. The client part is implemented on MEIZU M2 mobile phone that is equipped with a MediaTek MT 6735 1.3 GHz machine with 2G RAM. The server part is implemented on ThinkCentre E73 computer that is equipped with an Intel Core i7 4770S 3.1 GHz machine with 4G RAM. From Figs. 6 and 7, we find that our protocol is the most efficient.

Fig. 6

The computational time of client part

Fig. 7

The computational time of server part

Table 4 Advantage of our protocol over existing seven protocols

Now we consider the communication overhead. We assume that $|ID|=160$, $|TS|=32$ and $|ED|=112$. Note that for the 80-bit, 112-bit and 128-bit security levels, the corresponding sizes of hash value are 160 bits, 224 bits and 256 bits, respectively. When we accept the 80-bit security level, the size of p, q, $G_1$ and $G_2$ is 160, 512, 1024 and 1024 bits, respectively. Using the compression method in [33], we can reduce the size of an element in $G_1$ to 65 bytes. Therefore, the communication overheads of FA, WT, He, HCH, CT, LH, HL and our protocol are $2|G_1|+|ID|+3|h|+2|TS|+|ED| \mathrm{\,bits}=2\times 65+20+3\times 20+2\times 4+14=232\mathrm{\,bytes}$, $2|G_1|+|{\mathbb{Z}}_p^*|+|ID|+|h|+|ED| \mathrm{\,bits}=2\times 65+20+20+20+14=204 \mathrm{\,bytes}$, $3|G_1|+|{\mathbb{Z}}_p^*|+|ID|+|h|+|ED| \mathrm{\,bits}=3\times 65+20+20+20+14=269\mathrm{\,bytes}$, $2|G_1|+2|ID|+2|h|+2|TS|+|ED| \mathrm{\,bits}=2\times 65+2\times 20+2\times 20+2\times 4+14=232 \mathrm{\,bytes}$, $3|G_1|+|ID|+2|h|+|ED| \mathrm{\,bits}=3\times 65+20+2\times 20+14=269\mathrm{\,bytes}$, $5|G_1|+|ID|+2|h|+|ED| \mathrm{\,bits}=5\times 65+20+2\times 20+14=399\mathrm{\,bytes}$, $7|G_1|+2|h|+|ED| \mathrm{\,bits}=7\times 65+2\times 20+14=509\mathrm{\,bytes}$, $2|G_1|+|ID|+|h|+|TS|+|ED|+|k|\mathrm{\,bits}=2\times 65+20+20+4+14+10=198\mathrm{\,bytes}$, respectively. Similarly, we can obtain the communication overheads at the 112-bit and 128-bit security levels. We summarize the communication overheads of the eight protocols at the 80-bit, 112-bit and 128-bit security levels in Fig. 8. From Fig. 8, we find that the communication cost of our protocol is the lowest.

Fig. 8

The communication overhead

The Table 4 summarizes the advantage of our protocol over existing seven protocols. The advantage includes the computational efficiency (both client part and server part) and communication overhead. For the typical 80-bit security level, our protocol is $22.25\%$, $41.69\%$, $22.25\%$, $22.25\%$, $46.16\%$, $66.68\%$ and $66.68\%$ faster than FA, WT, He, HCH, CT, LH and HL, respectively, in the client part and is $21.44\%$, $28.29\%$, $35.31\%$, $21.44\%$, $45.91\%$, $62.51\%$ and $62.51\%$ faster than FA, WT, He, HCH, CT, LH and HL, respectively in the server part. For the same 80-bit security level, compared with FA, WT, He, HCH, CT, LH and HL, the communication overhead of our protocol is respectively reduced by $14.66\%$, $2.94\%$, $26.39\%$, $14.66\%$, $26.39\%$, $50.38\%$ and $61.1\%$.

5 Conclusion

This paper proposed a heterogeneous user authentication and key establishment protocol using the LZT signcryption. In our protocol, the client belongs to the IBC and the server belongs to the PKI. As compared with previous works, our protocol has the lowest cost in computation and communication. Although this paper focuses on the single server environment, our protocol is also suitable for the multi-server environment. The heterogeneous user authentication and key establishment is very suitable for solving the security problems of heterogeneous networks. A key problem in designing such protocols is how to ensure the key consistency between the client and the server since they use different public key authentication method. A possible future work would be to design user authentication and key establishment protocols between PKI and SCC.