Identity-based Password-Authenticated Key Exchange for Client/Server

Model

Xun Yi

, Raylin Tso

and Eiji Okamoto

School of Engineering and Science, Victoria University, Melbourne, Victoria 8001, Australia

Department of Computer Science, National Chengchi University, Taipei 11605, Taiwan

Department of Risk Engineering, University of Tsukuba, Tsukuba, Ibaraki, 305-8573, Japan

Keywords:

PAKE, Client/Server Model, Identity-based Encryption, Decisional Difﬁe-Hellman Problem.

Abstract:

Password-Authenticated Key Exchange for Client/Server model (PAKE-CS) is where a client and a server,

based only on their knowledge of a password, establish a cryptographic key for secure communication. In

this paper, we propose a PAKE-CS protocol on the basis of identity-based encryption, where the client needs

to remember a password only while the server keeps the password in addition to a private key related to his

identity, where the private key is generated by multiple private key generators. Our protocol takes advantage of

the features of client/server model and is more efﬁcient than other PAKE-CS protocols in terms that it achieves

explicit authentication with two-round communications only. In order to analyze the security of our protocol,

we construct an ID-based formal model of security for PAKE-CS by embedding ID-based model into PAKE

model. If the underlying identity-based encryption scheme has provable security without random oracle, we

can provide a rigorous proof of security for our protocol without random oracles.

1 INTRODUCTION

Nowadays, the client/server model has become one of

the core ideas of network computing. The Internet’s

main application protocols, such as HTTP, SMTP,

Telnet, DNS, etc, are all built on the client/server

model. Most business applications use this model as

well.

In the client/server model, a client and a server

communicate to exchange information. It is essential

for the server to identify the client before providing

the client with services, such as access to resources.

In order to authenticate the client, it is common for

the client to choose a password from a known small

space, such as a dictionary of English words, in or-

der to remember it, and shares it with the server in

advance. After that, each time when the client sends

the password to the server, the server can identify the

client. Such a password authentication protocol can

go back to 1981 (Lamport, 1981) and even earlier.

After password authentication, the client and the

server need to exchange information securely. Before

encrypting messages, the client and the server have

to share a cryptographic key. The password, chosen

from a small space, cannot be used as the key for en-

cryption. A solution for this problem is password-

authenticated key exchange for client/server (PAKE-

CS).

PAKE-CS is where a client and a server, based

only on their knowledge of a password, establish a

cryptographic key, such that an attacker who controls

the communication channel but does not possess the

password cannot impersonate the client or the server

in the communication and is constrained as much as

possible from guessing the password. Since the pass-

word is chosen from a small space, PAKE-CS has

to be immune to the dictionary attack, in which an

adversary exhaustively tries all possible passwords

from a dictionary in order to determine the correct

one. Dictionary attacks are either off-line attacks or

online attacks. In an off-line attack, an adversary

eavesdrops messages exchanged between the client

and server, and tries all possible passwords to deter-

mine one matching with these messages. In an online

attack, an adversary impersonates a client or a server

by trying possible passwords one-by-one. Online dic-

tionary attack can be discouraged by restricting the

number of password authentication failures.

Initial solutions for PAKE-CS is built on a “hy-

brid” model in which the client stores the server’s

public key in addition to share a password with the

server. Under this model, Gong, Lomas, Needham,

Yi X., Tso R. and Okamoto E..

Identity-based Password-Authenticated Key Exchange for Client/Server Model.

DOI: 10.5220/0004015900450054

In Proceedings of the International Conference on Security and Cryptography (SECRYPT-2012), pages 45-54

ISBN: 978-989-8565-24-2

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

and Saltzer (Gong et al., 1993) were the ﬁrst to pro-

pose password-based authentication protocols with

heuristic resistance to off-line dictionary attacks, and

Halevi and Krawczyk (Halevi and Krawczyk, 1999)

were the ﬁrst to give formal deﬁnitions and rigorous

proofs of security for them. The “hybrid” model re-

lies on the Public Key Infrastructure (PKI), where the

public key of the server is certiﬁed within a certiﬁ-

cate issued by a trusted third party. Exchanging and

verifying the public key certiﬁcate bring extra com-

putation and communication costs to PAKE-CS.

Bellovin and Merritt (Bellovin and Merritt, 1992)

were the ﬁrst to consider authenticated key exchange

based on password only. They introduced a set of

so-called “encrypted key exchange” (EKE) protocols,

where any two parties, who share a password, ex-

change messages encrypted by the password, and es-

tablish a cryptographic key from them. Although

several of the ﬁrst protocols were ﬂawed, the sur-

vived and enhanced EKE protocols effectively am-

plify a shared password into a shared cryptographic

key. Based on EKE, some further works (Gong et al.,

1993; Huang, 1996; Wu, 1998) have been done.

However, only heuristic and informal security argu-

ments for these protocols were provided. In fact,

attacks against many of these protocols have been

found (MacKenzie et al., 2000; Patel, 1997). This

demonstrates the great importance of rigorous secu-

rity proofs in a formal, well-deﬁned model.

In 2000, formal models of security for PAKE were

ﬁrstly given independently by Bellare, Pointcheval

and Rogaway (Bellare et al., 2000), and Boyko,

MacKenzie, Patel and Swaminathan (Boyko et al.,

2000). In the ideal cipher model, Bellare et al. (Bel-

lare et al., 2000) provided a proof of security for the

two-ﬂow protocol at the core of Bellovin-Merritt EKE

protocol (Bellovin and Merritt, 1992). In the ran-

dom oracle model, Boyko et al. (Boyko et al., 2000)

proved the security of their new Difﬁe-Hellman-based

PAKE while MacKenzie et al. (MacKenzie et al.,

2000) provided the security proof of their new RSA-

based PAKE. Later, some efﬁcient PAKE protocols

(e.g.,(Abdalla and Pointcheval, 2005; Bresson et al.,

2003)) were constructed. In 2001, Goldreich and

Lindell (Goldreich and Lindell, 2001) introduced an-

other model of security for PAKE and gave the ﬁrst

PAKE protocol which is provably secure under stan-

dard cryptographic assumptions. Their protocol does

not require any additional setup beyond the password

shared by the parties. However, their protocol re-

quires techniques from generic two-party secure com-

putation and concurrent zero-knowledge. This makes

their protocol computationally inefﬁcient. A simple

version of Goldreich-Lindell protocol was given by

Nguyen and Vadhan in (Nguyen and Vadhan, 2004),

but it is still not efﬁcient enough to be used in prac-

tice.

Katz, Ostrovsky, and Yung (Katz et al., 2001)

were the ﬁrst to give a PAKE protocol which is both

practical and provably-secure under standard crypto-

graphic assumption. Katz-Ostrovsky-Yung protocol

(simply called KOY protocol) has been proved to be

secure in the model of Bellare et al. (Bellare et al.,

2000) under the decisional Difﬁe-Hellman assump-

tion. In KOY protocol, the client and the server ex-

change the encryptions of the password (on the ba-

sis of a common public key), from which a common

cryptographic key is agreed and authenticated by one-

time digital signature scheme. KOY protocol assumes

that a set of common parameters (including the com-

mon public key) are available to everyone in the sys-

tem. This is known as the common reference model,

which avoids problems associated with the PKI. This

assumption is signiﬁcantly weaker (in both a theoret-

ical and practical sense) than the “hybrid” model in

which clients are required to authenticate the public

key for each server with whom they wish to commu-

nicate. The public parameters can be “hard-coded”

into the implementation of their protocol. Therefore,

the requirement of public parameters does not repre-

sents a serious barrier to using their protocol in prac-

tice.

Afterward, an efﬁcient protocol for PAKE with

proof of security based on a pseudorandom function

family was given by Jiang and Gong in (Jiang and

Gong, 2004), and a protocol satisfying a strong deﬁ-

nition of security for PAKE built on (Katz et al., 2001;

Gennaro and Lindell, 2003) was proposed in (Canetti

et al., 2005).

Our Contribution. The “hybrid” model for PAKE-

CS can be used efﬁciently to establish a cryptographic

key between the client and the server who share a

password. However, this model needs the PKI and

the client has to authenticate the public key of the

server before the execution of PAKE-CS. The com-

mon reference model for PAKE-CS avoids the PKI,

but protocols built on this model, in particular with

proofs of security under standard cryptographic as-

sumptions, are usually less efﬁcient than those based

on the “hybrid” model.

In the client/server model, the client is usually a

human user who can remember the password from a

small space only. However, the server is a machine

which can keep secret keys from a large space. Based

on this feature, identity-based group and three-party

PAKE protocols, in which a group of clients, each of

them shares his password with an “honest but curi-

ous” server, establish a group key with the help of

SECRYPT2012-InternationalConferenceonSecurityandCryptography

the server, have been proposed in (Yi et al., 2009; Yi

et al., 2011). In that setting, the key established is

known to the clients only and no one else, including

the server.

In this paper, we consider a two-party setting,

where a client and a server, who share a password,

establish a cryptography key on the basis of identity-

based encryption. The essential difference between

this setting and the group or three-party PAKE (Yi

et al., 2009; Yi et al., 2011) is that the established

key in this setting is known to the server. We pro-

pose an identity-based model for this setting, where

the client needs to remember a password only while

the server keeps the password in addition to a private

key related to its identity. This model is constructed

by embedding the model for identity-based encryp-

tion (IBE) (Boneh and Franklin, 2001) into the model

for PAKE (Bellare et al., 2000). In this model, we as-

sume that n private key generators cooperate to gen-

erate public parameters and private keys for servers.

Based on the identity-based model, we construct

an efﬁcient PAKE-CS protocol. Our protocol can be

built on any IBE scheme, such as Waters’s scheme

(Waters, 2005), which allows multiple private key

generators to generate private keys for users.

The basic structure of our protocol is Difﬁe-

Hellman key exchange between the client and the

server. But we use the password to authenticate the

request message from the client and conﬁrm the es-

tablished cryptographic key. In order to deter from

ofﬂine dictionary attack, the client encrypts the pass-

word with an IBE scheme on the basis of the identity

of the server.

Our protocol has an advantage over the KOY pro-

tocol (Katz et al., 2001). The KOY protocol does not

achieve explicit authentication (that is, a party does

not know whether its intended partner has success-

fully computed a matching session key). The ex-

plicit authentication has to be added later on using

standard techniques as described in (Bellare et al.,

2000). Thus, the KOY protocol needs four-round

communications to achieve explicit authentication.

But our protocol uses only two-round communica-

tions to achieve explicit authentication.

In terms of the number of communication rounds,

an identity-based PAKE-CS protocol is more efﬁcient

than other PAKE-CS protocols. Different from a pure

identity-based key agreement protocol, such as RFC

6539 (Cakulev et al., 2012), which requires each party

to have a (random) private key related to his identity,

the client in our protocol needs to remember pass-

words only (no cryptographic key of any kinds), and

the server keeps passwords in addition to a private key

related to his identity.

2 MODEL AND DEFINITIONS

A formal model of security for PAKE was given by

Bellare, Pointcheval and Rogaway in (Bellare et al.,

2000), and improved by Katz, Ostrovsky, and Yung in

(Katz et al., 2001). Boneh and Franklin deﬁned cho-

sen ciphertext security for IBE systems under a cho-

sen identity attack in (Boneh and Franklin, 2001). In

this section, we give the ID-based model for PAKE-

CS, a combination of deﬁnitions given in (Bellare

et al., 2000; Katz et al., 2001; Boneh and Franklin,

2001).

Participants, Initialization and Passwords. An

ID-based PAKE-CS protocol involves three kinds of

protocol participants: (1) A set of clients (denoted

as Client), each of which requests services from

servers on the network; (2) A set of servers (de-

noted as Server), each of which provides services

to clients on the network; (3) n private key gen-

erators PKG

,PKG

,··· ,PKG

(denoted as PKG),

which cooperate to generate public parameters and

private keys for servers. Private key generators are

not servers.

We assume that a honest private key generator fol-

lows the exact protocol, but a dishonest private key

generator may perform attacks on the protocol to re-

trieve the cryptographic key established between the

client and the server. In addition, let ClientServerPair

be the set of pairs of the client and the server, who

share a password, and let User = Client

Server. We

assume that Client

Server =

Prior to any execution of the protocol, we assume

that an initialization phase occurs. During initializa-

tion, PKG cooperate to generate public parameters for

the protocol, which are available to all participants,

and private key for each server, which is given to the

appropriate server.

For any pair (C, S) ∈ ClientServerPair, the clientC

and the server S are assumed to share the same pass-

word pw

, which is what C remembers to log into

S. We assume that the client C chooses pw

inde-

pendently and uniformly at random from a “dictio-

nary” D = {pw

,pw

,··· ,pw

} of size N, where N

is a ﬁxed constant which is independent of the secu-

rity parameter. It is then stored at the server S for

authentication.

In this model, not every pair of client and server

share passwords. A client may share different pass-

words with different servers.

Execution of the Protocol. In the real world, a proto-

col determines how users behave in response to input

from their environments. In the formal model, these

inputs are provided by the adversary. Each user is

assumed to be able to execute the protocol multiple

Identity-basedPassword-AuthenticatedKeyExchangeforClient/ServerModel

times (possibly concurrently) with different partners.

This is modeled by allowing each user to have unlim-

ited number of instances with which to execute the

protocol. We denote instance i of user U as U

. A

given instance may be used only once. The adversary

is given oracle access to these different instances. Fur-

thermore, each instance maintains (local) state which

is updated during the course of the experiment. In

particular, each instance U

has associated with it the

following variables, initialized as NULL or FALSE (as

appropriate) during the initialization phase.

• sid

,pid

and sk

(initialized as NULL) are vari-

ables containing the session identity, partner iden-

tity, and session key for an instance U

, respec-

tively. The session identity is simply a way to

keep track of the different executions of a par-

ticular user U. The partner identity denotes the

identity of the user with whom U

believes it is

interacting (including U

itself).

• acc

and term

(initialized as FALSE) are

boolean variables denoting whether a given in-

stance U

has been accepted, terminated, or au-

thenticated, respectively. Termination means that

the given instance has done receiving and sending

messages, acceptance indicates successful termi-

nation. In our case, acceptance means that the in-

stance is sure that it has established a session key

with its intended partner, thus, when an instance

accepts, sid

, pid

and sk

are no longer

NULL.

• state

(initialized as NULL) records any state

necessary for execution of the protocol by U

• used

(initialized as FALSE) is a boolean variable

denoting whether an instance U

has begun exe-

cuting the protocol. This is a formalism which

will ensure each instance is used only once.

The adversary A is assumed to have complete con-

trol over all communications in the network and the

adversary’s interaction with the users (more speciﬁ-

cally, with various instances) or the PKG is modeled

via access to oracles which we describe now. The

state of an instance may be updated during an ora-

cle call, and the oracle’s output may depend upon the

relevant instance. The oracle calls include:

• Send(U

,M) – This sends message M to instance

. Assuming term

= FALSE, this instance

runs according to the protocol speciﬁcation, up-

dating state as appropriate. The output of U

(i.e., the message sent by the instance) is given

to the adversary, who receives the updated values

of sid

,pid

,acc

, and term

. This oracle call

models the active attack to a protocol.

• Execute(C

) – If C

and S

have not yet been

used (where (C, S) ∈ ClientServerPair), this ora-

cle execute the protocol between these instances

and outputs the transcript of this execution. This

oracle call represents passive eavesdropping of a

protocol execution. In addition to the transcript,

the adversary receives the values of sid, pid, acc,

and term for both instances, at each step of proto-

col execution.

• Corrupt(C) – This query allows the adversary to

learn the passwords of the client C, which models

the possibility of subverting a client by, for ex-

ample, witnessing a user type in his password, or

installing a “Trojan horse” on his machine. This

implies that all passwords held by C are disclosed.

• Corrupt(S) – This query allows the adversary to

learn the private key of the server S, which mod-

els the possibility of compromising a server by,

for example, hacking into the server. This implies

that all passwords held by S are disclosed as well.

• KeyGen(PKG

,S) – This sends the identity of the

server S to the PKG

, which generates one compo-

nent of the private key corresponding to the iden-

tity of S and forwards it to the adversary. This

oracle models the possibility of a private key gen-

erator being an adversary.

• Reveal(U

) – This outputs the current value of ses-

sion key sk

if acc

= TRUE. This oracle call

models possible leakage of session keys due to,

for example, improper erasure of session keys af-

ter use, compromise of a host computer, or crypt-

analysis.

• Test(U

) – This oracle does not model any real-

world capability of the adversary, but is instead

used to deﬁne security. If acc

= TRUE, a ran-

dom bit b is generated. If b = 0, the adversary

is given sk

, and if b = 1 the adversary is given

a random session key. The adversary is allowed

only a single Test query, at any time during its

execution.

Partnering. We say that a client instance C

and a

server instance S

are partnered if (1) pid

= pid

NULL; and (2) sid

= sid

6= NULL; and (3) sk

6= NULL; and (4) acc

= acc

= TRUE. The

notion of partnering will be fundamental in deﬁning

both correctness and security.

Correctness. To be viable, an authenticated key ex-

change protocol must satisfy the following notion of

correctness: At the presence of both passive and ac-

tive adversaries, for any pair of client and server in-

stances C

and S

, if sid

= sid

6= NULL and acc

SECRYPT2012-InternationalConferenceonSecurityandCryptography

acc

= TRUE, then it must be the case that sk

6= NULL (i.e., both conclude with the same ses-

sion key) and pid

= pid

6= NULL (i.e., both con-

clude with the same pair). The notion of correctness

has no restriction on the adversary’s oracle accesses.

Advantage of the Adversary. Informally, the adver-

sary succeeds if it can guess the bit b used by the Test

oracle. Before formally deﬁning the adversary’s suc-

cess, we must ﬁrst deﬁne a notion of freshness. A

user instance A

(either a client or a server) is fresh if

none of the following is true at the conclusion of the

experiment, namely, at some point,

• The adversary queried Reveal(A

) or Reveal(B

)

with the instances A

and B

being partnered;

• The adversary queried KeyGen(PKG

,S) (i =

1,2,··· ,n) where there exists a server in-

stance S

∈ pid

, before a query of the form

Send(U

ℓ

,M), where U

ℓ

∈ pid

, has taken place,

for some message M (or identities);

• The adversary queried Corrupt(A) or Corrupt(B)

where there exists a instance B

∈ pid

, before a

query of the form Send(U

ℓ

,M), where U

ℓ

∈ pid

has taken place, for some message M (or identi-

ties).

Note that passive adversaries have no access to

any Send oracles. Therefore, a user instance is fresh

to a passive adversary as long as the ﬁrst event did not

happen.

The adversary is thought to succeed only if its

Test query is made to a fresh instance. We say

an adversary A succeeds if it makes a single query

Test(U

) to a fresh instance U

, with acc

= TRUE

at the time of this query, and outputs a single bit b

′

with b

′

= b (recall that b is the bit chosen by the Test

oracle). We denote this event by Succ. The advantage

of adversary A in attacking protocol P is then given

Adv

(k) = 2· Pr[Succ] − 1

where the probability is taken over the random coins

used by the adversary and the random coins used dur-

ing the course of the experiment (including the initial-

ization phase) and k is a security parameter.

Formally, an instance U

represents an on-line at-

tack if both the following are true at the time of

the Test query: (1) at some point, the adversary

queried Send(U

,∗), and (2) at some point, the ad-

versary queried Reveal(U

) or Test(U

). In particu-

lar, instances with which the adversary interacts via

Execute, KeyGen, Corrupt and Reveal queries are not

counted as on-line attacks. The number of on-line at-

tacks represents a bound on the number of passwords

the adversary could have tested in an on-line fashion.

Deﬁnition 1. Protocol P is a secure protocol for

password-authenticated key exchange if, for all dic-

tionary size N and for all PPT adversaries A making

at most Q(k) on-line attacks, there exists a negligible

function ε(·) such that

Adv

(k) ≤ Q(k)/N + ε(k)

where k is a security parameter.

The above deﬁnition ensures that the adversary

can (essentially) do no better than guess a single pass-

word during each on-line attack. Calls to the Execute,

KeyGen, Corrupt and Reveal oracles, which are not

included in Q(k), are of no help to the adversary in

breaking the security of the protocol.

Forward Secrecy. We follow the deﬁnition of for-

ward secrecy from (Katz et al., 2003) and consider

the weak corrupt model of (Bellare et al., 2000), in

which corrupting a client means retrieving his pass-

words, while corrupting a server means retrieving its

private key and all passwords stored in it. Forward

secrecy is then achieved if such queries do not give

the adversary any information about previous agreed

session keys.

3 IDENTITY-BASED PAKE-CS

PROTOCOL

The high-level depiction of the protocol is illustrated

in Fig. 1, and a more detailed description follows. A

completely formal speciﬁcation of the protocol will

appear in Section 5, where we give a proof of secu-

rity for the protocol in the security model described

in Section 2.

We present the protocol by describing initializa-

tion and execution. We let k be the security parameter

given to the setup algorithm.

Initialization. Given a security parameter k ∈ Z

∗

, the

initialization works as follows:

Parameter Generation:

On input k, (1) PKG coop-

erate to run Setup

of the IBE scheme to gener-

ate public system parameters for the IBE scheme,

denoted as params

, and the secret master-key

{mk

,mk

,··· ,mk

}, where

stands for encryption

and mk

is known only to PKG

; (2) PKG choose a

large Mersenne prime q = 2

− 1, where p is a prime

and construct a ﬁnite ﬁeld F

, where each element α

is corresponding to a binary vector (α

,α

,··· ,α

and F

∗

is a large cyclic multiplicative group (denoted

as G) with a prime order q. Assume g is a generator

of G; (3) PKG select two hash functions h : {0,1}

∗

→

and H : {0, 1}

∗

→ M (where M is the plaintext

space of IBE) from a collision-resistant hash family.

Identity-basedPassword-AuthenticatedKeyExchangeforClient/ServerModel

Public: params

,G,q,g,h : {0,1}

∗

→ Z

,H : {0,1}

∗

→ M

Client (pw

) Server (pw

)

← Z

,pid

← {C

}

Auth

← E

[H(g

|pid

|pw

)] C

|Auth

msg

pid

← {C

}

If D

[Auth

] 6= H(g

|pid

|pw

)], return ⊥

Else β

← Z

← (g

)

Auth

← g

h(g

|pid

|pw

)+k

← g

,sid

← g

|pid

acc

← TRUE



|Auth

msg

← (g

)

If Auth

6= g

h(g

|pid

|pw

)+k

, return ⊥

Else sk

← g

,sid

← g

|pid

acc

← TRUE

Figure 1: ID-based PAKE-CS protocol P.

The public system parameters for the protocol P are

params = params

{h,H, G,q,g} and the secret pa-

rameter is master-key

Key Generation:

On input the identity ID

of a server

S ∈ Server, params, and master-key

, PKE runs

Extract

of the IBE scheme and sets the decryption

key of S to be d

= {d

S,1

S,2

,··· ,d

S,n

} where d

S,i

is generated by PKG

with params and mk

Password Generation:

On input (C, S) ∈

ClientServerPair, a string pw

, the password, is

uniformly drawn by the client C from the dictionary

Password = {pw

,pw

, ··· ,pw

}, and then store it

in the server S.

Protocol Execution. A client and a server, where

(C, S) ∈ ClientServerPair (i.e., they share a password

), execute the protocol as follows. The client

C ﬁrstly randomly chooses α ∈ Z

, and computes

Auth

, which is an encryption of H(g

|pid

|pw

) on

the basis of the identity of the server ID

, denoted

as E

[H(g

|pid

|pw

)], where pid

= {C

} .

Please note that the identity of the server, like an e-

mail address, is meaningful and easy to remember and

keep. Then the client C sends msg

= C

|Auth

the server S as the ﬁrst message of the protocol.

Upon receiving the message msg

, S ﬁrstly de-

crypts the ciphertext with its private key d

and then

veriﬁes the password. The password is correct if

[Auth

] = H(g

|pid

|pw

) (1)

where pid

= {C

If (1) holds, the server S randomly chooses

β ∈ Z

and computes k

= g

αβ

. Let Auth

h(g

|pid

|pw

)+k

, the server S replies to the client

C with msg

= S

|Auth

, and ﬁnally computes the

session key sk

= g

and keeps the session identiﬁer

sid

= g

|pid

Upon receivingmsg

, the clientC ﬁrstly computes

= g

αβ

and then veriﬁes if

Auth

= g

h(g

|pid

|pw

)+k

(2)

If (2) holds, the client C computes the ﬁnal session

key sk

= g

and keeps the session identiﬁer sid

|pid

Remark: Due to the special structure of G, the group

element k

(or k

) is corresponding to a binary vector

,··· ,k

), which is treated as an integer from Z

∗

Correctness. In an execution of the protocol, if

sid

= g

|pid

= sid

= g

|pid

6= NULL,

then α

= α

, β

= β

, and pid

= pid

= {C,S}.

If acc

= acc

= TRUE, then sk

= g

where

= g

, and sk

= g

where k

= g

. If

sid

= sid

6= NULL and acc

= acc

= TRUE, then

= sk

Explicit Authentication. Generally speaking, a key

exchange protocol achieves explicit authentication if

a party knows that its intended partner has success-

fully computed a matching session key. By verify-

ing equation (1), the server knows that g

does come

from the client. Therefore, the server makes sure

that as long as the client receives msg

= S|g

|Auth

he must compute a matching session key sk

= sk

By verifying equation (2), the client is sure that

does come from the server and knows that the

server has successfully computed the matching ses-

sion key sk

= sk

. In the settings where the client

needs to remember passwords only, previous PAKE

protocols achieve implicit authentication only (e.g.,

(Katz et al., 2001)) or explicit authentication with

three-round communications (e.g., (Jiang and Gong,

2004)). Our protocol achieves explicit authentication

with only two-round communications.

Efﬁciency Consideration. The efﬁciency of our pro-

tocol depends on performance of the underlying IBE

SECRYPT2012-InternationalConferenceonSecurityandCryptography

system. If we employ Waters’ IBE scheme (Waters,

2005), where e(g

) are included in the public pa-

rameters, the client needs to compute 7 exponentia-

tions without pairing. In addition, the client needs to

send and receive 6 group elements. In the KOY pro-

tocol, the client needs to compute 15 exponentiations

plus signature generation and exchange 10 group ele-

ments plus a signature and a veriﬁcation key. There-

fore, on the side of the client, our protocol is more

efﬁcient than the KOY protocol.

Example. According to RFC 5091 (Boyen and Mar-

tin, 2007), if a security parameter k is 1024, the ci-

phertext size of the Waters’ IBE scheme is about

1024 + 160 × 2 = 1344 bits. In addition, we use a

large Mersenne prime q = 2

1279

− 1, where 1279 is

a prime as well, to construct the group G. With ref-

erence to Fig. 1 in this setting, the size of the mes-

sage msg

sent to the server from the client is about

1344 + 1279 = 2623 bits, while the size of the mes-

sage msg

replied to the client from the server is about

1279× 2 = 2558 bits.

4 PROOF OF SECURITY

First of all, we provide a formal speciﬁcation of the

protocol by specifying the initialization phase and the

oracles to which the adversary has access. A for-

mal speciﬁcation of the Initialize, Execute, KeyGen,

Reveal, Test, and Send oracles appears in Fig. 2−4.

The description of the Execute oracle matches the

high-level protocol described in Fig. 1, but additional

details (for example, the updating of state informa-

tion) are included. We let status

denote the vector

of values (sid

,pid

,acc

,term

) associated with in-

stance U

Theorem 1. Assume that (1) the IBE scheme, where

there exist n private key generators and at least one

of them is honest, is secure against the chosen-

ciphertext attack; (2) the decisional Difﬁe-Hellman

(DDH) problem and the squaring decisional Difﬁe-

Hellman (SDDH) problem are hard over a cyclic

group G with a prime order q and a generator g; (3)

CRHF is a collision-resistant hash family; then the

protocol described in Fig. 1 is a secure protocol for

PAKE-CS.

Remark. The SDDH problem here is to distinguish

between two distributions (g,g

) and (g,g

,z),

where a is randomly chosen from Z

∗

and z is ran-

domly chosen from G.

Proof. We follow the methodology of the security

proof given by Katz et al. in (Katz et al., 2001).

Given an adversary A , we imagine a simulator that

Initialize(1

)

(params

,master-key

)

← Setup

)

(Client,Server,ClientServerPair)

← UserGen(1

)

(G,q,g)

← GGen(1

),{h,H}

← CRHF(1

)

For each i ∈ {1,2,· ·· } and each U ∈ User = Client ∪ Server

acc

← term

← used

← FALSE

sid

← pid

← sk

← NULL

For ∀S ∈ Server, d

← Extract

(ID

,params

,master-key

)

For ∀(C, S) ∈ ClientServerPair,pw

← {pw

,pw

,·· · ,pw

}

Return Client,Server,ClientServerPair,h,H,G,q,g,params

Figure 2: Speciﬁcation of the initialize.

Execute(C

)

If (C,S) 6∈ ClientServerPair ∨ used

∨ used

, return ⊥

used

← used

← TRUE, pid

← pid

← {C

}

← Z

,Auth

← IBE

[H(g

|pid

|pw

)]

msg

← C

|Auth

← Z

,K ← g

αβ

,Auth

← g

h(g

|pid

|pw

)+K

msg

← S

|Auth

acc

← term

← acc

← term

← TRUE

sid

← sid

← g

|{C

}

← sk

← g

Return status

,status

KeyGen(PKG

,S)

Return d

S,i

Corrupt(S)

Return d

and pw

for any C

Corrupt(C)

Return pw

for any S

Reveal(U

)

Return sk

Test(U,i)

← {0,1},sk

′

← G; If b = 1 return sk

′

else return sk

Figure 3: Speciﬁcation of Execute, KeyGen, Reveal and

Test.

runs the protocol for A . Preciously, the simulator be-

gins by running algorithm Initialize(1

) as shown in

Fig. 2 and giving the public output of the algorithm to

A . When A queries an oracle, the simulator responds

to A by executing the appropriate algorithm as shown

in Fig. 3−4.

In particular, when the adversary queries the Test

oracle, the simulator chooses (and records) the ran-

dom bit b.

When the adversary completes its execution and

outputs a bit b

′

, the simulator can tell whether the

adversary succeeds by checking whether (1) a single

Test query was made, for some instance U

; (2) acc

was true at the time of Test query; (3) instance U

fresh; and (4) b

′

= b. Success of the adversary is de-

noted by event Succ. For any experiment P, we deﬁne

Adv

(k) = 2Pr

[Succ] − 1, where Pr

[·] denotes the

probability of an event when the simulator interacts

with A in accordance with experiment P.

Identity-basedPassword-AuthenticatedKeyExchangeforClient/ServerModel

Send

)

If (C, S) 6∈ ClientServerPair ∨ used

, return ⊥

used

← TRUE, pid

← {C

}

← Z

,Auth

← IBE

[H(g

|pid

|pw

)]

MsgOut ← C

|Auth

,state

← (α,pid

,MsgOut)

Return MsgOut,status

Send

|Auth

)

If (C, S) 6∈ ClientServerPair ∨ used

, return ⊥

used

← TRUE,pid

← {C

}

If D

[Auth

] 6= H(g

|pid

|pw

), return status

Else β

← Z

,K ← g

αβ

,Auth

← g

h(g

|pid

|pw

)+K

MsgOut ← S

|Auth

acc

← term

← TRUE, sk

← g

,sid

← g

|pid

Return MsgOut,status

Send

|Auth

)

state

← (α,pid

,FirstMsgOut)

If ¬used

∨ term

∨ (S

6∈ pid

), return ⊥

K ← g

αβ

. If Auth

6= g

h(g

|pid

|pw

)+K

, return status

Else acc

← term

← TRUE,sk

← g

,sid

← g

|pid

Return status

Figure 4: Speciﬁcation of the Send oracles.

We refer to the real execution of the experiment,

as described above, as P

. We will introduce a se-

quence of transformations to the original experiment

and bound the effect of each transformation on the

adversary’s advantage.

We begin with some terminology that will be

used throughout the proof. A given msg is called

oracle-generated if it was output by the simulator

in response to some oracle query (whether a Send

or Execute query). The message is said to be

adversarially-generated otherwise. An adversarially-

generated message must not be the same as any

oracle-generated message.

Experiment P

. In this experiment, the simulator in-

teracts with the adversary as before except that any of

the following never occurs:

1. At any point during the experiment, an oracle-

generated message (e.g., msg

or msg

) is re-

peated.

2. At any point during the experiment, a collision

occurs in the hash functions h,H (regardless of

whether this is due to a direct action of the adver-

sary, or whether this occurs during the course of

the simulator’s response to an oracle query).

It is immediate that events 1 and 2 occur with only

negligible probability assuming the security of CRHF

as a collision-resistant hash family. Therefore,

Claim 1. If CRHF is a collision-resistant hash family,

then |Adv

(k) − Adv

(k)| is negligible.

Experiment P

. In this experiment, the simulator in-

teracts with the adversary A as in experiment P

ex-

cept that the adversary’s queries to Execute oracles

are handled differently: for any Execute(C

) ora-

cle, the value of K is replaced with a random value

from G.

The difference between experiments P

and P

bounded by the probability that an adversary solves

the DDH problem. More precisely, we have

Claim 2. If the DDH problem is hard over (G,q,g),

then |Adv

(k) − Adv

(k)| is negligible.

Experiment P

. In this experiment, the simulator in-

teracts with the adversary A as in experiment P

ex-

cept that the adversary’s queries to Execute oracles

are handled differently: for any Execute(C

) ora-

cle, the session key sk

and sk

are replaced with a

random element from G.

The difference between experiments P

and P

bounded by the probability to solve the SDDH prob-

lem. More precisely, we have

Claim 3. If the SDDH problem is hard over (G, q,g),

then |Adv

(k) − Adv

(k)| is negligible.

In experiment P

, the adversary’s probability of

correctly guessing the bit b used by the Test oracle

is exactly 1/2 if the Test query is made to a fresh in-

stance invoked by an Execute oracle. Therefore, all

passive adversaries (including the PKG) cannot win

the game, even if they can query KeyGen(PKG

,∗)

for i = 1,2,··· ,n and Corrupt oracles. The remain-

der of the proof discusses instances invoked by Send

oracles.

Experiment P

. In this experiment, we modify the

simulator’s responses to Send

and Send

queries.

At ﬁrst, we introduce some terminology. For a

query Send

,msg

) (or Send

,msg

)), where

msg

(or msg

) is adversarially-generated, if equa-

tion (1) (or (2)) holds, then msg

(or msg

) is said

to be valid. Otherwise, msg

(or msg

) is said to be

invalid. Informally, valid messages use correct pass-

words while invalid messages do not.

When the adversary makes an oracle query

Send

,msg

) to a fresh sever instance S

, the sim-

ulator examines msg

. If it is adversarially-generated

and valid, the simulator halts and acc

is assigned

the special value ∇. In any other case, (i.e., msg

is oracle-generated, or adversarially-generated but in-

valid), the query is answered exactly as in experi-

ment P

. When the adversary makes an oracle query

Send

,msg

) to a fresh client instance C

, the

simulator examines msg

. If msg

is adversarially-

generated and valid, the simulator halts and acc

assigned the special value ∇. In any other case, the

SECRYPT2012-InternationalConferenceonSecurityandCryptography

query is answered exactly as in experiment P

. Now,

we change the deﬁnition of the adversary’s success

in P

. If the adversary ever queries Send

,∗) to a

fresh server instance S

with acc

= ∇ or Send

,∗)

to a fresh client instance C

with acc

= ∇, the simu-

lator halts and the adversary succeeds. Otherwise the

adversary’s success is determinedas in experiment P

The distribution on the adversary’s view in exper-

iments P

and P

are identical up to the point when

the adversary queries Send

or Send

to a fresh user

instance with acc

= ∇ or acc

= ∇. If such a query

is never made, the distributions on the view are iden-

tical. Therefore, we have

Claim 4. Adv

(k) ≤ Adv

(k).

In experiment P

, the adversary A succeeds if one

of the following occurs: (1) acc

= ∇ (let Succ

de-

note this event); (2) acc

= ∇ (let Succ

denote this

event); (3) neither Succ

nor Succ

happens, the ad-

versary wins the game by a Test query to a fresh user

instance A

. To evaluate Pr

[Succ

∨ Succ

], we do

the following experiments.

Experiment P

. In this experiment, the simulator in-

teracts with the adversary A as in experiment P

ex-

cept that the adversary’s queries to Execute and Send

oracles are handled differently: for Execute(C

)

(after which there exist any query of the form

Send(U

ℓ

,∗) where U ∈ {C,S}) or Send

)

queries to the fresh instances C

and S

, Auth

computed as E

[H(g

|pid

|pw

′

)] where pw

′

is ran-

domly chosen from D .

Claim 5. If the IBE scheme where there are n pri-

vate key generators and at least one of them is hon-

est is secure against the chosen-ciphertext attack, then

|Adv

(k) − Adv

(k)| is negligible.

Experiment P

. In this experiment, the simulator in-

teracts with A as in experiment P

except that the

adversary’s queries to Send

and Send

oracles are

handled differently: for Send

,∗) or Send

,∗)

queries, Auth

is replaced by a random element from

Claim 6. If the DDH problem is hard over (G, q,g),

then |Adv

(k) − Adv

(k)| is negligible.

For any adversarially-generated Send

,∗) or

Send

,∗) queries to the fresh instances C

and S

in experiment P

, all Execute and Send queries are in-

dependent of the password pw

in the view of the ad-

versary. In order to win the game by Succ

or Succ

the adversary has to try all passwords one-by-one in

an online impersonation attack. The probability that

Succ

or Succ

occurs is at most Q(k)/N, where Q(k)

is the number of online attacks made by A .

When neither Succ

nor Succ

occurs, the adver-

sary’s probability of success is 1/2. The preceding

discussion implies that

[Succ] ≤ Q(k)/N + 1/2· (1− Q(k)/N)

and therefore Adv

(k) ≤ Adv

(k) + ε(k) for some

negligible function ε(·). This completes the proof of

the theorem.

5 CONCLUSIONS

In this paper, we have presented an identity-based

PAKE protocol for client/service model. Our protocol

is based on identity-based encryption and needs only

two-round communication between the client and the

server to achieve explicit authentication. Our future

work is to machine-validate our security proofs using

a cryptographic proof-assistant, such as EasyCrypt

(Barthe et al., 2011).

REFERENCES

Abdalla, M. and Pointcheval, D. (2005). Simple password-

based encrypted key exchange protocols. In Proc. CT-

RSA 2005, pages 191–208.

Barthe, G., Grgoire, B., Heraud, S., and Bguelin, S. Z.

(2011). Computer-aided security proofs for the work-

ing cryptographer. In Proc. Crypto'11, pages 71–90.

Bellare, M., Pointcheval, D., and Rogaway, P. (2000). Au-

thenticated key exchange secure against dictionary at-

tacks. In Proc. Eurocrypt'00, pages 139–155.

Bellovin, S. M. and Merritt, M. (1992). Encrypted key ex-

change: Password-based protocol secure against dic-

tionary attack. In Proc. 1992 IEEE Symposium on Re-

search in Security and Privacy, pages 72–84.

Boneh, D. and Franklin, M. (2001). Identity based encryp-

tion from the weil pairing. In Proc. Crypto'01, pages

213–229.

Boyen, X. and Martin, L. (2007). Identity-based cryptog-

raphy standard (ibcs) 1: Supersingular curve imple-

mentations of the bf and bb1 cryptosystems. In RFC

5091.

Boyko, V., Mackenzie, P., and Patel, S. (2000). Prov-

ably secure password-authenticated key exchange us-

ing difﬁe-hellman. In Proc. Eurocrypt'00, pages 156–

171.

Bresson, E., Chevassut, O., and Pointcheval, D. (2003). Se-

curity proofs for an efﬁcient password-based key ex-

change. In Proc. CCS'03.

Cakulev, V., Sundaram, G., and Broustis, I. (2012). Ibake:

Identity-based authenticated key exchange. In RFC

6539.

Canetti, R., Halevi, S., Katz, J., Lindell, Y., and MacKenzie,

P. (2005). Universally composable password-based

key exchange. In Proc. Eurocrypt'05, pages 404–421.

Identity-basedPassword-AuthenticatedKeyExchangeforClient/ServerModel

Gennaro, R. and Lindell, Y. (2003). A framework for

password-based authenticated key exchange. In Proc.

Eurocrypt'03, pages 524 –543.

Goldreich, O. and Lindell, Y. (2001). Session-key genera-

tion using human passwords only. In Proc. Crypto'01,

pages 408–432.

Gong, L., Lomas, T. M. A., Needham, R. M., and Saltzer,

J. H. (1993). Protecting poorly-chosen secret from

guessing attacks. IEEE J. on Selected Areas in Com-

munications, 11(5):648–656.

Halevi, S. and Krawczyk, H. (1999). Public-key cryptog-

raphy and password protocols. ACM Transactions on

Information and System Security, 2(3):230–268.

Huang, H. F. (1996). Strong password-only authenticated

key exchange. ACM Computer Communication Re-

view, 26(5):5–20.

Jiang, S. and Gong, G. (2004). Password based key ex-

change with mutual authentication. In Proc. SAC'04,

pages 267–279.

Katz, J., Ostrovsky, R., and Yung, M. (2001). Efﬁcient

password-authenticated key exchange using human-

memorable passwords. In Proc. Eurocrypt'01, pages

457–494.

Katz, J., Ostrovsky, R., and Yung, M. (2003). Forward se-

crecy in password-only key exchange protocols. In

Proc. SCN'03, pages 29–44.

Lamport, L. (1981). Password authentication with insecure

communication. Comm. of the ACM, 24(11):770–772.

MacKenzie, P., Patel, S., and Swaminathan, R. (2000).

Password-authenticated key exchange based on rsa. In

Proc. Asiacrypt'00, pages 599–613.

Nguyen, M. H. and Vadhan, S. P. (2004). Simpler session-

key generation from short random passwords. In Proc.

Theory of Cryptography'04, pages 428–445.

Patel, S. (1997). Number-theoretic attack on secure pass-

word scheme. In Proc. IEEE Symposium on Research

in Security and Privacy, pages 236–247.

Waters, B. (2005). Efﬁcient identity-based encryption with-

out random oracles. In Proc. Eurocrypt'05, pages

114–127.

Wu, T. (1998). The secure remote password protocol. In

Proc. Internet Society Symp. on Network and Dis-

tributed System Security, pages 97–111.

Yi, X., Tso, R., and Okamoto, E. (2009). Id-based

group password-authenticated key exchange. In Proc.

IWSEC'09, pages 192–211.

Yi, X., Tso, R., and Okamoto, E. (2011). Three-party

password-authenticated key exchange without random

oracles. In Proc. SECRYPT'11, pages 15–24.

SECRYPT2012-InternationalConferenceonSecurityandCryptography