(e.g., Gentry's scheme), and any identity-based signature (IBS) scheme (e.g., Paterson- ... each user to have a pair of public and private keys for digital signature. ..... did not happen, because the server or PKG adversary has no access to any ...
ID-Based Group Password-Authenticated Key Exchange Xun Yi1 , Raylin Tso2 , and Eiji Okamoto2 1 School
of Engineering and Science Victoria University, Melbourne, Victoria 8001, Australia 2
Department of Risk Engineering University of Tsukuba, Tsukuba, Ibaraki, 305-8573, Japan
Abstract—Password-authenticated key exchange (PAKE) protocols are designed to be secure even when the secret key used for authentication is a human-memorable password. In this paper, we consider PAKE protocols in the group scenario, in which a group of clients, each of them shares a password with an “honest but curious” server, intend to establish a common secret key (i.e., a group key) with the help of the server. In this setting, the key established is known to the clients only and no one else, including the server. Each client needs to remember passwords only while the server keeps passwords in addition to private keys related to his identity. Towards our goal, we present a compiler that transforms any group key exchange (KE) protocol secure against a passive eavesdropping to a group PAKE which is secure against an active adversary who controls all communication in the network. This compiler is built on any group KE protocol (e.g., the Burmester-Desmedt protocol), any identity-based encryption (IBE) scheme (e.g., Gentry’s scheme), and any identity-based signature (IBS) scheme (e.g., Paterson-Schuldt scheme). It adds only two rounds and O(1) communication (per client) to the original group KE protocol. As long as the underlying group KE protocol, IBE scheme and an IBS scheme have provably security without random oracles, a group PAKE constructed by our compiler can be proven to be secure without random oracles. Keywords: Group key agreement, protocol compiler, password-authenticated key exchange, common reference model.
1
Introduction
Popularity of group-oriented applications and protocols is currently on the increase and, as a result, group communication is taking place in many different settings, from network layer multicasting to application layer tele- and video-conferencing. Securing group communication makes demands of protocols for group authenticated key exchange (AKE), which allows a group of users communicating over an insecure public network to establish a common secret key (i.e., a group key) and furthermore to be guaranteed that they are indeed sharing this key with each other. Protocols for 2-party AKE has been extensively investigated in [36, 15, 37, 13, 11, 32, 33, 34]. A number of works have considered extending the 2-party Diffie-Hellman protocol [36] to the multi-party setting [43, 57, 29, 58, 10, 50, 51]. Among them, the works of Ingemarsson et al. [43], Burmester and Desmedt [29], and Steiner et al. [58] may be the most well-known. They are merely key exchange (KE) protocols, intended to be secure against a passive adversary only. 1
However, AKE protocols aim to be secure against more powerful adversaries, who - in addition to eavesdropping - control all communication in the network. A number of initial protocols for group AKE were suggested in [44, 19, 7, 8, 59]. But none of these works have rigorous security proofs in a well-defined model. Bresson et al. [22, 23, 24] were the first to define a formal model of security for group AKE and give the first provably secure protocols for this setting. Their model was built on the earlier work of Bellare and Rogaway in the two-party setting [12, 13, 11] and their protocols were based on the work of Steiner et al. [58], which requires O(n) rounds to establish a key among n users, and therefore not scalable. A constant-round group AKE with a security proof in the random oracle model was given in [20], but it was shown to be insecure in [56]. Katz and Yung [48] were the first to give scalable protocol for group AKE along with a rigorous proof of security in the standard model. They also presented the first efficient compiler that transforms any group KE protocols secure against a passive eavesdropping to authenticated protocols by signing message flows. Their compiler adds only one round to the original protocol. However, this compiler requires each user to have a pair of public and private keys for digital signature. The (high-entropy) private key is not human-memorable and needs additional cryptographic devices to store it. Bellovin and Merritt [14] were the first to consider AKE based on (low-entropy) password only and introduced a series of so-called “encrypted key exchange” (EKE) protocols for two-party AKE. A password-based AKE (i.e., PAKE) 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. Even though these attacks are not very effective in the case of high-entropy keys, they can be very damaging when the secret key is a password since the attacker has a nonnegligible chance of winning. Dictionary attacks are usually divided into two categories: offline and online dictionary attacks. Formal models of security for two-party PAKE were firstly given independently by Bellare, Pointcheval and Rogaway [11], and Boyko, MacKenzie, Patel and Swaminathan [21] in 2000. Since then, protocols for two-party PAKE have been continuously proposed and proven to be secure in either the random oracle model (e.g.,[26, 27, 3, 4, 5]) or the standard model (e.g., [40, 46, 45]). Bresson et al. [25, 28] were the first to adapt a group KE protocol to the password-based scenario. As the original protocol, the first group PAKE protocol was not scalable and practical for large groups. In addition, their security proof required ideal models. Recently, a number of constant-round group PAKE have been proposed in the literature by Abdalla et al. [2, 6], by Bohli et al. [16], and by Kim, Lee and Lee [49]. All of these constructions are built on the Burmester-Desmedt protocol [29, 31] and are rather efficient. Among them, the works of Abdalla et al. [6] and Bohli et al. [16] enjoy security proofs in the standard model. Most of existing group PAKE protocols assume that users of a group share the same password, e.g., [25, 28, 2, 6]. In the scenarios where a user wants to participate in many groups, the number of passwords that he would need to remember would be linear in the number of possible groups. In order to limit the number of passwords that each user has to remember, a couple of group PAKE protocols assume that each user shares a password only with a server, which helps users of a group with establishment of a common secret key (i.e., a group key), e.g., [3, 4, 52]. The server is assumed to behave in an “honest but curious” manner. By the knowledge of passwords, the server may attempt to learn the group key. The setting with different passwords seems to be more practical in the real world than the setting with the same password. More recently, Abdalla et al. [1] presented a protocol compiler that transforms any two-party 2
AKE into a group AKE with two more rounds of communication. Their idea is inspired by the construction of Burmester and Desmedt [29], where the trick of constructing a group key from pairwise agreed keys among users of a group was firstly introduced. In particular, applying this compiler to a two-party PAKE protocol yields a group PAKE protocol. The primary motivation of this compiler was the two-party setting. As implied in [48, 47], a compiler tailored from the group setting scales better than the compiler from two-party setting. This leads a question, is there any protocol compiler that transforms any group KE protocol directly to a group PAKE protocol? Contribution. To the best of our knowledge, there has not yet been any protocol compiler that can transform any group KE protocol directly into a group PAKE protocol at present. In this paper, we present such a compiler on the basis of the “state-of-the-art” identity-based cryptosystem, a public-key cryptosystem in which an arbitrary string (e.g., user identity) can be used as the public key. Our compiler employs any group KE protocol secure against passive eavesdropping, any IBE with chosen-ciphertext security and any IBS with existential unforgeability. We assume that clients of a group, each of them shares a password with an “honest but curious” server, intend to establish a common secret key (i.e., a group key) with the help of the server, where the key established is known to the clients only and no one else, including the server. For more details of the “honest but curious” server, we can refer to the work of Abdalla et al. in [3]. The basic idea of our compiler is that users of a group firstly run the group KE protocol to establish a group key without any help of the server, and then the server helps users of the group with mutual authentication and key confirmation by the shared password (protected with the IBE scheme), and finally each user authenticates the server, along with partnered users and the established key during the group KE, by the IBS scheme. To analyze the security of our compiler, we put forth a formal model of security for ID-based PAKE in the group setting, by embedding Boneh et al.’s ID-based model [17][18] into the group PAKE model given by Bresson et al. in [25, 28] and improved by Abdalla et al. [1]. Our model assumes that all users and servers refer to the common public parameters including the public key of a private key generator (commonly used in ID-based model). Thus, our model is between the Halevi-Krawczyk model [42] (where each user needs to keep the public key of each server or to authenticate it with the public key of a certificate authority) and the Katz-Ostrovsky-Yung model [48] (where all users and servers refer the common public parameters only). Different from the Halevi-Krawczyk model, our model is ID-based, where the public key of a server is its identity (which is meaningful) and public key authentication is unnecessary. Thus, the Public Key Infrastructure (PKI) is not needed in our model. Similar to the Katz-Ostrovsky-Yung model, our model includes the public key of a private key generator in the common public parameters. Although the Katz-Ostrovsky-Yung model assumes that the public parameter generator uses random numbers as the public key of Cramer-Shoup cryptosystem [35], it can, in fact, chooses the private key at first and then computes the public key without being detected. Furthermore, provided with the public key in the common public parameters, if the corresponding private key is compromised, both the Katz-Ostrovsky-Yung protocol and our protocol have to reset. We provide a rigorous proof of security for our compiler. Our compiler does not rely on the random oracle model as long as the underlying primitives themselves do not rely on it. By using Burmester-Desmedt group KE protocol [29], Gentry IBE scheme [39], Paterson-Schuldt IBS scheme [54], our compiler can construct a group PAKE with provably security in the standard 3
model. Organization. In Section 2, we introduce a new model for ID-based group PAKE. In Section 3, we describe the underlying cryptographic primitives to build our group PAKE. Then, in Section 4, we present a new ID-based group PAKE compiler. After that, in Section 5, the brief security proof for our protocol is given. We conclude this paper in Section 6. In addition, the detail security proof is provided in Appendix.
2
Definitions
A formal model of security for group PAKE was firstly given by Bresson et al. in [25, 26] (based on Bellare et al.’s formal model for 2-party PAKE [12]), and improved by Abdalla et al. in [1]. Boneh and Franklin were the first to define chosen ciphertext security for IBE under chosen identity attack [17, 18]. In this section, we put forward a new model of security for ID-based group PAKE, on the basis of definitions given by Bresson et al., Abdalla et al. and Boneh et al. Participants, Initialization and Passwords. An ID-based group PAKE protocol involves three kinds of participants: (1) A set of clients (denoted as Client); (2) A set of servers (denoted as Server), which behave in an honest but curious manner; (3) A Private Key Generator (PKG), which generates public parameters and corresponding private keys for servers, and behaves in an honest but curious manner as well. We assume that ClientServerPair is theSset of pairs of theTclient and the server, who share a password. In addition, User = Client Server and Client Server = ∅. Prior to any execution of the protocol, we assume that an initialization phase occurs. During initialization, PKG generates public parameters for the protocol, which are available to all participants, and issues private keys for each server. For any pair (A, S) ∈ ClientServerPair, the client A and the server S are assumed to share the same password pwSA . We assume that the client A chooses pwSA independently and uniformly at random from a “dictionary” D = {pw1 , pw2 , · · · , pwN } of size N , where N is a fixed constant which is independent of the security parameter. The password pwSA is then stored at the server S for authentication. After initialization, a server can be still added to the system as long as it obtains its private key related to its identity from PKG. A client can join the system once he shares his password with a server. Execution of the Protocol. In the real world, a protocol 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 times (possibly concurrently) with different partners. This is modeled by allowing each user to have unlimited number of instances with which to execute the protocol. We denote instance i of user U as U i . A given instance may be used only once. The adversary is given oracle access to these different instances. Furthermore, each instance maintains (local) state which is updated during the course of the experiment. In particular, each instance U i has associated with it the following variables, initialized as NULL or FALSE (as appropriate) during the initialization phase. • sidiU and pidiU are variables (initialized as NULL) denoting the session identity and partner identity for an instance, respectively. The session identity sidiU is simply a way to keep track of the different executions of a particular user U . The partner identity pidiU is the
4
set of users with whom U i believes it is interacting to establish a session key (including U itself). • acciU and termiU are boolean variables (initialized as FLASE) denoting whether a given instance has been accepted or terminated, respectively. Termination means that the given instance has done receiving and sending messages, acceptance indicates successful termination. In our case, acceptance means that the instance is sure that a group key has been established, thus, when an instance U i accepts, sidiU and pidiU are no longer NULL. • usediU is a boolean variable (initialized as FLASE) denoting whether an instance has begun executing the protocol. This is a formalism which will ensure each instance is used only once. • stateiU (initialized as NULL) records any state necessary for execution of the protocol by a user instance U i . • skiA is a variable (initialized as NULL) denoting the session key for a client instance Ai . Computation of the session key is, of course, the ultimate goal of the protocol. When Ai accepts (i.e., acciA = TRUE), skiA is no longer NULL. The adversary A is assumed to have complete control over all communications in the network and the adversary’s interaction with the users (more specifically, with various instances) or PKG is modeled via access to oracles which we describe now. The state of an instance may be updated during an oracle call, and the oracle’s output may depend upon the relevant instance. The oracle types are as follows: • Execute(Ai11 , Ai22 , · · · , Ainn , S j ) – If Ai`` and S j have not yet been used (where A` ∈ Client, S ∈ Server, (A` , S) ∈ ClientServerPair, ` = 1, 2, · · · , n), this oracle executes the protocol among 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 all instances, at each step of protocol execution. • Send(U i , M ) – This sends message M to instance U i . Assuming termiU = FALSE, this instance runs according to the protocol specification, updating state as appropriate. The output of U i (i.e., the message sent by the instance) is given to the adversary, who receives the updated values of sidiU , pidiU , acciU , and termiU . This oracle call models the active attack to a protocol. • KeyGen(PKG, S) – This sends the identity of the server S to PKG, which generates private keys dS corresponding to S and forwards it to the adversary. This oracle models possible compromising of a server due to, for example, hacking into the server. This implies that all passwords stored in the server are disclosed. • Corrupt(A) – This query allows the adversary to learn the passwords of the client A, which models the possibility of subverting a client by, for example, witnessing a user type in his password, or installing a “Trojan horse” on his machine. This implies that all passwords held by A are disclosed.
5
• Reveal(Ai ) – This outputs the current value of session key skiA for a client instance if acciA = TRUE. This oracle call models possible leakage of session keys due to, for example, improper erasure of session keys after use, or cryptanalysis. • Test(Ai ) – This oracle does not model any real-world capability of the adversary, but is instead used to define security of the session key of client instance Ai . If acciA = TRUE and skiA 6= NULL, a random bit b is generated. If b = 0, the adversary is given skiA , and if b = 1 the adversary is given a random session key. The adversary is allowed a single Test query, at any time during its execution. A passive adversary is given access to the Execute, KeyGen, Reveal, Corrupt, and Test oracles, while an active adversary is additionally given access to the Send oracles. We assume that all servers behave in a honest but curious manner. We can imagine a server as a passive adversary who have already queried a KeyGen oracle to retrieve the server’s private keys and all passwords stored in it. In addition, we assume that all servers have no access to any form of Send oracles. In the definition of Execute and Send oracles, we reasonably require that A1 , A2 , · · · , An share different passwords with the same server S. Partnering. We say that client instances Ai and B j are partnered if there exists a server instance S k associated with Ai and B j such that (1) pidiA = pidjB = pidkS and (2) sidiA = sidjB = sidkS . The notion of partnering will be fundamental in defining both correctness and security. Correctness. To be viable, a key exchange protocol must satisfy the following notion of correctness: if Ai and B j are partnered and acciA = accjB = TRUE, then it must be the case that skiA = skjB 6= NULL (i.e., they conclude with the same session key). Freshness. Informally, the adversary succeeds if it can guess the bit b used by a Test oracle. Before formally defining the adversary’s success, we must first define a notion of freshness. A client instance Ai is fresh unless one of the following is true at the conclusion of the experiment, namely, at some point, • The adversary queried Reveal(Ai ) or Reveal(B j ) with the client instances Ai and B j being partnered. • The adversary queried KeyGen(PKG, S) where the server instance S ∈ pidiA , before a query of the form Send(U ` , M ), where U ∈ pidiA , has taken place, for some message M (or identities). • The adversary queried Corrupt(A) or Corrupt(B) with the client instance Ai and B j being partnered, before a query of the form Send(U ` , M ), where U ∈ pidiA , has taken place, for some message M (or identities). Note that a client instance is fresh to a server or PKG adversary as long as the first event did not happen, because the server or PKG adversary has no access to any Send oracles and the last two events always happen. The adversary is thought to succeed only if its Test query is made to a fresh instance. Note that this is necessary for any reasonable definition of security, otherwise, the adversary could always succeed, e.g., submitting a Test query for an instance for which it had already submitted a Reveal query. In addition, a server instance S j is fresh if any client instance Ai such that (A, S) ∈ ClientServerPair, sidiA = sidjS , and pidiA = pidjS , is fresh. 6
Advantage of the adversary. We say an adversary A succeeds if it makes a single query Test(Ai ) to a fresh client instance Ai , with acciA = TRUE at the time of this query, and outputs a single bit b0 with b0 = 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 a function in the security parameter k, defined as AdvPA (k) = 2 · PrPA [Succ] − 1 where the probability is taken over the random coins used by the adversary and the random coins used during the course of the experiment (including the initialization phase). It remains to define what we mean by a secure protocol. Note that a probabilistic polynomial-time (PPT) adversary can always succeed by trying all passwords one-by-one in an online impersonation attack. This is possible since the size of the password dictionary is constant. Informally, a protocol is secure if this is the best an adversary can do. Formally, an instance U i represents an online attack if both the following are true at the time of the Test query: (1) at some point, the adversary queried Send(U i , ∗), and (2) at some point, the adversary queried Reveal(Aj ) or Test(Aj ), where the client instance Aj ∈ pidiU . In particular, instances with which the adversary interacts via Execute, KeyGen, Reveal and Corrupt queries are not counted as online attacks. The number of online attacks represents a bound on the number of passwords the adversary could have tested in an online fashion. Definition 1. Protocol P is a secure protocol for password-authenticated key exchange if, for all dictionary size N and for all PPT adversaries A making at most Q(k) online attacks, there exists a negligible function ε(·) such that AdvPA (k) ≤ Q(k)/N + ε(k) The above definition ensures that the adversary can (essentially) do no better than guess a single password during each online attack. Calls to the Execute, KeyGen, Reveal and Corrupt oracles, which are not included in Q(k), are of no help to the adversary in breaking the security of the protocol. This means the passive attacks and offline dictionary attacks are of no use. Forward secrecy. We follow the definition of forward secrecy from [47, 1] and consider the weak corrupt model of [12], in which corrupting a client means retrieving his passwords, while asking KeyGen query on a server means retrieving its private keys 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. In addition, we follow the definition of freshness from [1]. The adversary is allowed to ask the Test query on a client instance, where he has known (1) the passwords of the client or any of his partners by Corrupt query; or (2) the private key of the server and all password stored in it by KeyGen query, however, he has not asked any Send query to the instance of the client or any of his partners. In this sense, the above definition of security implies forward secrecy. Key privacy with respect to the server. The notion of key privacy respect to the server was introduced in [3] to capture the idea where the session key shared between two instances should only be known to these two instances and no one else, including the server, who behaves in an honest but curious manner. In our model, the server can be imagined as a passive adversary who has already queried a KeyGen oracle to retrieve the server’s private keys and all passwords stored in it. On the basis of the above definition for forward secrecy, key privacy with respect to the server is implied in forward secrecy. 7
3
Cryptographic Building Blocks
3.1
Group Key Exchange
A group key exchange (KE) protocols allow users of a group communicating over an insecure public network to establish a common secret key (i.e., a group key), where the shared secret key is derived by two or more users as a function of the information contributed by, or associated with, each of these, (ideally) such that no user can predetermine the resulting key. They are intended to be secure against the passive adversary only. A passive adversary is given access to the Execute, Reveal, and Test oracles as defined in Section 2. In the definition of Execute oracle, we reasonably require that different executions yield different group session keys. We say a passive adversary A succeeds if it makes a single query Test(Ai ) to a fresh instance Ai (i.e., no Reveal oracle is queried to Ai and his partnered instances), and outputs a single bit b0 with b0 = b (recall that b is the bit chosen by the Test oracle). We denote this event by Succ. The advantage of a passive adversary A in attacking a group KE protocol P is a function in the security parameter k, defined as AdvPA (k) = 2 · PrPA [Succ] − 1. A group KE protocol P is secure against passive eavesdropping if no polynomial bounded adversary A has a non-negligible advantage in attacking it. The group KE protocols proposed by Ingemarsson et al. [43], Burmester and Desmedt [29], and Steiner et al. [58] may be the most well-known. Among them, Burmester-Desmedt protocol has been shown to be secure against passive eavesdropping in the standard model by Katz and Yung [48].
3.2
Identity-Based Encryption
An identity-based encryption (IBE) scheme is specified by four randomized algorithms: Setup, Extract, Encrypt, Decrypt as follows. • Setup: On input a security parameter k, it returns params (public system parameters) and master-key (known only to the “Private Key Generator”). • Extract: On inputs params, master-key and a public identity ID ∈ {0, 1}∗ , it returns a private key d. • Encrypt: On inputs params, ID, and a message M ∈ M (the plaintext space), it returns a ciphertext C ∈ C (the ciphertext space). • Decryption: On inputs params, C ∈ C, and a private key d, it returns M ∈ M. Chosen ciphertext security is the standard acceptable notion of security for a public key encryption scheme. An IBE scheme is semantically secure against the adaptive chosen ciphertext attack if no polynomial bounded adversary A has a non-negligible advantage against the challenger in the following game: • Initialize: The challenger runs the Setup algorithm, gives params to the adversary, but keeps the master-key to itself. • P hase 1: The adversary adaptively asks a number of different queries q1 , q2 , · · · , qm , where qi is either Extract(IDi ) or Decrypt(IDi , Ci ). 8
• Challenge: Once the adversary decides that Phase 1 is over, it outputs a pair of equal length plaintexts (M0 , M1 ) and an identity ID on which it wishes to be challenged, where ID must not appear in Phase 1. The challenger picks a random bit b ∈ {0, 1} and sends C = Encrypt(ID, Mb ) as the challenge to the adversary. • P hase 2: The adversary issues more queries qm+1 , qm+2 , · · · , qn adaptively as in Phase 1, except that the adversary may not request a private key for ID or the decryption of (ID, C). • Guess: Finally, the adversary outputs a guess b0 ∈ {0, 1} and wins the game if b0 = b. We define the adversary A’s advantage in attacking the IBE scheme as a function of the E 0 security parameter k, AdvE A (k) = |PrA [b = b] − 1/2|, where the probability is over the random bits used by the challenger and the adversary. The most efficient identity-based encryption schemes are currently based on bilinear pairings on elliptic curves, such as the Weil or Tate pairings. Boneh and Franklin [17, 18] were the first to give an IBE scheme from Weil pairing and prove it to be adaptive chosen-ciphertext security in the random oracle model. More recently, several new IBE schemes from pairing (e.g., [60][39]) were proposed and proven to be adaptive chosen-ciphertext security in the standard model. A common feature of the latest IBE schemes is that the plaintext space is a cyclic group of prime order.
3.3
Identity-Based Signature
An identity-based signature (IBS) scheme can be described by four algorithms Setup, Extract, Sign, Verify as follows. • Setup: On input a security parameter k, it returns params (public system parameters) and master-key (known only to the “Private Key Generator”). • Extract: Given params, master-key and a public identity ID ∈ {0, 1}∗ , it returns a private key dID . • Sign: Given a message M , params, ID and a private key dID , it generates a signature σ of the user (with identity ID) on M . • Verify: Given a signature σ, a message M , and params, ID, it outputs accept if σ is a valid signature of the user (with identity ID) on M , and outputs reject otherwise. An IBS scheme is existential unforgeability under the chosen message attack [41] if no polynomial bounded adversary A has a non-negligible advantage against the challenger in the following game: • Initialize: The challenger runs the Setup algorithm, gives params to the adversary, but keeps the master-key to itself. • Queries: The adversary adaptively asks a number of different queries q1 , q2 , · · · , qm , where qi is either Extract(IDi ) or Sign(IDi , M ). • F orgery: Once the adversary decides that queries are over, it outputs a message M 0 , an identity ID0 and a string σ 0 . The adversary succeeds (denoted as Succ) if Verify(ID0 , M 0 , σ 0 ) = 1, where ID0 cannot appear in Extract queries and (ID0 , M 0 ) cannot appear in Sign queries. 9
We define the adversary A’s advantage in attacking the IBS scheme as a function of the security parameter k, AdvSA (k) = PrSA [Succ], where the probability is over the random bits used by the challenger and the adversary. A generic approach to construct IBS schemes is to use an ordinary (i.e., non-identity-based) signature scheme and simply attach a certificate containing the public key of the signer to the signature [38]. An IBS scheme with provable security in the standard model was given by Paterson and Schuldt in [54].
3.4
Decisonal Squaring Diffie-Hellman Problem
The computational squaring Diffie-Hellman (CSDH) problem in a cyclic group G with a prime 2 order q and a generator g is: Given g, g a where a is randomly chosen from Z∗q , determine g a . The problem is as hard as Diffie-Hellman problem [53, 30, 9]. The decisional squaring Diffie-Hellman (DSDH) problem in a cyclic group G with a prime 2 order q and a generator g is to distinguish between two distributions (g, g a , g a ) (dentoed as b = 0) and (g, g a , z) (denoted as b = 1), where a is randomly chosen from Z∗q and z is randomly chosen from G. This problem is not harder than the decisional DH problem, but we believe that this problem can still be hard, that is, we can assume that the advantage of any PPT algorithm A that outputs b ∈ {0, 1} in solving the DSDH problem is negligible, namely, 2
|P r[A(g, g a , g a ) = 0] − P r[A(g, g a , z) = 0]| is negligible, where the probability is over the random choice of a in Z∗q and z in G, and the random bits consumed by A.
4 4.1
An Efficient Compiler for Group PAKE Description of the Compiler
In this section, we present an efficient compiler transforming any group KE protocol P to a group PAKE protocol P 0 . Following the communication model given in [3], we assume that arbitrary point-to-point connections among clients and servers to be available. The network is non-private and fully asynchronous, that is, the adversary may delay, eavesdrop, insert and delete message at will. Given a group KE protocol P , our compiler constructs a group PAKE protocol P 0 as shown in Fig. 1, in which n clients A1 , A2 , · · · , An (in lexicographic order) wish to establish a common authenticated secret key (i.e., a group key) with the help of a server S. A completely formal specification of the group PAKE protocol will appear in Section 5, where we give a brief proof of security for the protocol in the security model described in Section 2. We present the protocol by describing initialization and execution. The cryptographic building blocks of our protocol include a group KE protocol, an IBE scheme and an IBS scheme. We let k be the security parameter given to the setup algorithm. Initialization. Given a security parameter k ∈ Z∗ , the initialization includes: Parameter Generation: On input k, (1) PKG runs SetupP of the group KE protocol P to generate system parameters, denoted as paramsP ; (2) PKG runs SetupE of the IBE scheme to generate public system parameters for the IBE scheme, denoted as paramsE , and the secret master-keyE 10
for itself; (3) PKG runs SetupS of the IBS scheme to generate public system parameters for the IBS scheme, denoted as paramsS , and the secret master-keyS for itself; In addition, PKG chooses a large cyclic group G with a prime order q and a generator g, and a hash function H : {0, 1}∗ → M (where M is the plaintext space of IBE), from a collision-resistant hash The public system S S family. S 0 P E parameters for the protocol P is params = {H, G, q, g} params params paramsS and the E S secret (master-key , master-key ) is known only to PKG. Round 0 (Group Key Exchange (P )) Clients A` , ` = 1, 2, · · · , n pidA` ← (A1 , A2 , · · · , An ) P P P (skP A1 , skA2 , · · · , skAn ) ← Execute (A1 , A2 , · · · , An )
Round 1 (Client Authentication) Client A` , ` ∈ {1, 2, · · · , n}, pidA` ← pidA` ∪ {S}, sidA` ← g Auth` ←
skP A
`
EIDS [H(sidA` |pidA` |pwS A` )]
{S} ← msgA` = A` |sidA` |Auth` Server S, pidS ← (A1 , A2 , · · · , An , S), sidS ← sidA1 If ∃` such that DdS [Auth` ] 6= H(sidS |pidS |pwS A` ), then return ⊥
Round 2 (Server Authentication) Server S AuthS ← Sd0S [pidS |sidS ] {A1 , A2 , · · · , An } ← msgS = S|AuthS Client A` , ` = 1, 2, · · · , n If VIDS [pidA` |sidA` , AuthS ] 6= 1, then return ⊥ 0
Else accept ← TRUE, skP A` ← g
2 (skP A ) `
Fig. 1. ID-based group PAKE protocol P 0
Key Generation: On input the identity IDS of a server S ∈ Server, params, and (master-keyE , master-keyS ), PKE runs ExtractE of the IBE scheme and sets the decryption key of S to be dS , and runs ExtractS of the IBS scheme and sets the signing key of S to be d0S . Password Generation: On input (A, S) ∈ ClientServerPair, a string pwSA , the password, is uniformly drawn by the client A from the dictionary Password = {pw1 , pw2 , · · · , pwN }, and then store it in the server S. Protocol Execution. For a group of clients A1 , A2 , · · · , An (in lexicographic order), where there exists a server S such that (A` , S) ∈ ClientServerPair, when A` (having password pwSA` ) (` = 1, 2, · · · , n) agree to establish a common authenticated secret key (i.e., a group key) via S, they firstly run the group KE protocol P and each client A` computes the initial group key skPA` . Note that the clients may not be authentic and the initial group key derived by different clients in the same session may not be equal. Mutual authentication and key confirmation run as follows. skP Each client A` compute sidA` = g A` and an IBE encryption of H(sidA` |pidA` |pwSA` ) based on the identity IDS of the server, denoted as Auth` . Then msgA` = A` |sidA` |Auth` is submitted to the server S.
11
Upon receiving the messages msgA` (` = 1, 2, · · · , n), the server S lets sidS = sidA1 and decrypts the ciphertexts with its decryption key dS , and verifies whether DdS [Auth` ] = H(sidS |pidS |pwSA` )
(1)
If equation (1) holds for ` = 1, 2, · · · , n, the server S uses its signing key d0S to generate a signature AuthS = Sd0S [pidS |sidS ], and then broadcasts msgS = S|AuthS . Upon receiving msgS , each client A` checks if VIDS [pidA` |sidA` , AuthS ] = 1 If equation (2) holds, A` computes g skA` .
2 (skP A ) `
P0
4.2
(2)
and accepts it as the authenticated group key
Correctness, Explicit Authentication, Trust Model and Efficiency
Correctness. In the case where two clients Ai and Aj are partnered with accAi = accAj = TRUE, the signature of the server on pidAi |sidAi = pidAj |sidAj = pidS |sidS ensures that pidAi = pidAj and sidAi = sidAj . Therefore, g g
2 (skP A ) i
=g
2 (skP A ) j
0
skP A
i
=g
skP A
j
and further skPAi = skPAj (mod q). This means,
0
, that is, skPAi = skPAj . Thus, our protocol meets correctness.
Explicit authentication. By verifying equation (1) which involves the password pwSA` , the partner identity pidS and the initial group key skPA` for ` = 1, 2, · · · , n, the server S can make sure the authenticity of each client A` and the initial group key. By verifying equation (2) which involves the signature of the server, each client A` is convinced of the authenticity of the server S, other partners and the initial group key. If both equations (1) and (2) hold, all clients are (skP )2
legitimate, the initial group key is genuine and thus the final group key g A` is authentic. This shows that the group PAKE protocol P 0 achieves explicit authentication, that is, each client knows that its intended partners have successfully computed a matching session key (i.e, a group key). Trust model. The protocol compiler for group PAKE given by Abdalla et al. [1] is applicable where each user of the group is honest. If two adjacent users are dishonest, they can conspire to include one (or several) impersonating attacker(s) between them, while other users are unaware of this attack. Our compiler assumes that there exist “honest but curious” servers, which are trusted to authenticate users of the group, but may perform passive attacks on the protocol to retrieve the group key. In terms of trust management, we believe that our compiler is more practical than Abdalla et al.’s compiler. Efficiency consideration. The efficiency of our group PAKE protocol depends on performance of the underlying group KE protocol, IBE and IBS schemes. Only two rounds are added to the original group KE protocol P . In these two rounds, each client sends out one message and receives one message only. This compiler adds only O(1) communication (per client) to the original group KE protocol. If our compiler employs Burmester-Desmedt group key exchange protocol, our group PAKE protocol has 4 rounds only. The communication cost of each client is O(2n) bits, where n is the number of clients. If Abdalla et al.’s compiler employs KOY 2-PAKE protocol [46] and constructs the commitment scheme with Cramer-Shoup public key encryption 12
scheme [35], their group PAKE protocol has 5 rounds. The communication cost of each user is O(6n) bits. In this sense, we believe that our compiler is more efficient than Abdalla et al.’s compiler. Note that we take into account cryptographic blocks with provably security in the standard model only.
5
Proof of Security
We follow the methods of the security proofs given in [48, 46] to prove the security of our compiler without random oracles. First of all, we provide a formal specification of the group PAKE protocol by specifying the initialization phase and the oracles to which the adversary has access, as shown in Fig. 2−4. During theS initialization forSsecurity parameter k, algorithm Initialize generates params S phase E P = {G, q, g, H} params params paramsS and the secret (master-keyE , master-keyS ) at first. Furthermore, the sets Client, Server, ClientServerPair are determined. Passwords for clients are chosen at random, and then stored at corresponding servers. Initialize(1k ) R (paramsP,E,S , master-keyE,S ) ← SetupP,E,S (1k ) R R R (Client, Server, ClientServerPair) ← UserGen(1k ), (G, q, g) ← GGen(1k ), H ← CRHF(1k ) For each i ∈ {1, 2, · · ·} and each U ∈ User acciU ← termiU ← usediU ← FALSE, sidiU ← pidiU ← skiU ← NULL For each S ∈ Server, dS , d0S ← ExtractE,S (IDS , paramsE,S , master-keyE,S ) R
For each (A, S) ∈ ClientServerPair, pwS A ← {pw1 , pw2 , · · · , pwN } Return Client, Server, ClientServerPair, G, q, g, H, paramsP,E,S
Fig. 2. Specification of the initialize Execute(Ai11 , · · · , Ainn , S j ), where A` ∈ Client, S ∈ Server i
If (∃` such that (A` , S) 6∈ ClientServerPair ∨ usedA`` ) ∨ usedjS , return ⊥ i i usedA`` ← usedjS ← TRUE, pidA`` ← pidjS ← {A1 , · · · , An , S}, ` = 1, 2, · · · , n i1 i2 P P P in (skP A1 , skA2 , · · · , skAn ) ← Execute (A1 , A2 , · · · , An ) skP i i` i` i sidA` ← g A` , Auth` ← EIDS [H(sidA`` |pidA`` |pwS A` )], msgA` ← A` |sidA` |Auth` , ` sidjS ← sidiA11 , AuthS ← Sd0S [pidjS |sidjS ], msgS ← S|AuthS (skP )2 i i i accA`` ← termA`` ← accjS ← termjS ← TRUE, skA`` ← g A` , ` = 1, 2, · · · , n j i1 in Return statusA1 , · · · , statusAn , statusS
= 1, 2, · · · , n
KeyGen(PKG, S) Return dS , d0S and pwS A for any A Corrupt(A) Return pwS A for any S Reveal(Ai ) Return skiA Test(Ai ) R R b ← {0, 1}, sk0 ← Ω. If b = 1 return sk0 else return skiA
Fig. 3. Specification of the Execute, KeyGen, Corrupt, Reveal, Test oracles
13
i
Send0 (A`` , (Ai11 , · · · , Ainn )) i
If usedA`` , return ⊥ i usedA``
← TRUE
········· i
Send00 (A`` , S j ) i
i
If ¬usedA`` ∨ (A` , S) 6∈ ClientServerPair ∨ termA`` , return ⊥ i pidA``
i ← {A1 , · · · , An , S}, sidA`` ← i i MsgOut ← A` |sidA`` |Auth` , stateA`` i Return statusA`` i` i` 0 j Send1 (S , (A` |sidA` |Auth` )`=1,2,···,n )
g
skP A
`
i
i
, Auth` ← EIDS [H(sidA`` |pidA`` |pwS A` )] i
← (pidA`` , skP A` , MsgOut)
If (∃` such that (A` , S) 6∈ ClientServerPair) ∨ usedjS , return ⊥ usedjS ← TRUE, pidjS ← {A1 , A2 , · · · , An , S}, sidjS ← sidiA11 j If ∃` such that DdS [Auth` ] 6= H(sidjS |pidjS |pwS A` ), reject and return statusS
AuthS ← Sd0S [pidjS |sidjS ], accjS ← termjS ← TRUE, MsgOut ← S|AuthS Return statusjS i
Send02 (A`` , S j |AuthS ) i
i
stateA`` ← (pidA`` , skP A` , FirstMsgOut) i i i If ¬usedA`` ∨ termA`` ∨ (S 6∈ pidA`` ), return i i If VIDS [pidA`` |sidA`` , AuthS ] 6= 1, reject and (skP )2 i i i accA`` ← termA`` ← TRUE, skA`` ← g A` i Return statusA``
⊥ i
return statusA``
Fig. 4. Specification of the Send oracles
The description of the Execute oracle matches the high-level protocol described in Fig. 1, but additional details (for example, the updating of state information) are included. We let statusiU denote the vector of values (sidiU , pidiU , acciU , termiU ) associated with instance U i . Given an adversary A, we imagine a simulator that runs the protocol for A. More preciously, the simulator begins by running algorithm Initialize(1k ) (which includes choosing passwords for clients) and giving the public output of the algorithm to A. When A queries an oracle, the simulator also responds by executing the appropriate algorithm. The simulator also records all state information defined during the course of the experiment. In particular, when the adversary completes its execution and outputs a bit b0 , the simulator can tell whether the adversary succeeds by checking whether (1) a single Test query was made, for some client instance U i ; (2) acciU was true at the time of Test query; (3) instance U i is fresh; and (4) b0 = b. Success of the adversary is denoted by event Succ. For any experiment P 0 we define 0 0 AdvPA (k) = 2 · PrPA [Succ] − 1 Based on the model described in Section 2, we have Theorem 1. Assume that (1) the group KE protocol is secure against passive eavesdropping; (2) the IBE scheme is secure against the chosen-ciphertext attack; (3) the IBS scheme is existential unforgeability under the chosen-message attack; (4) the decisional squaring Diffie-Hellman (DSDH) problem is hard over a cyclic group G with a prime order q and a generator g; (5) CRHF is a collision-resistant hash family; then the protocol P 0 described in Fig. 1 is a secure group PAKE protocol. The detail proof of Theorem 1 is provided in Appendix. 14
6
Conclusion
In this paper, we present an efficient compiler to transform any group KE protocol to a group PAKE protocol from identity-based cryptosystem. In addition, we provide a rigorous proof of security for our compiler. As long as our group PAKE protocol is built on a group KE protocol, and IBE and IBS schemes with provable security without random oracles, it can be proven to be secure without random oracles.
References [1] M. Abdalla, J. M. Bohli, M. I. G. Vasco, R. Steinwandt. (Password) authenticated key establishment: From 2-party to group. In Proc. TCC’07, pages 499-514, 2007. [2] M. Abdalla, E. Bresson, O. Chevassut, and D. Pointcheval. Password-based group key exchange in a constant number of rounds. In Proc. PKC’06, pages 427-442, 2006. [3] M. Abdalla, P. A. Fouque, and D. Pointcheval. Password-based authenticated key exchange in the three-party setting. In Proc. PKC’05, pages 65-84, Jan. 2005. [4] M. Abdalla, P. A. Fouque, and D. Pointcheval. Password-based authenticated key exchange in the three-party setting. IEE Proceedings in Information Security, 153(1): 27-39, Mar. 2006. [5] M. Abdalla and D. Pointcheval. Simple password-based encrypted key exchange protocols. In Proc. CT-RSA 2005, pages 191 - 208, Feb. 2005. [6] M. Abdalla and D. Pointcheval. A scalable password-based group key exchange in the standard model. In Proc. Asiacrypt’06, pages 332-347, 2006. [7] G. Ateniese, M. Steiner, and G. Tsudik. Authenticated group key agreement and friends. In Proc. CCS’98, pages 17-26, 1998. [8] G. Ateniese, M. Steiner, and G. Tsudik. New multi-party authentication services and key agreement protocol. IEEE Journal on Selected Areas in Communications, (18)4: 628-639, 2000. [9] F. Bao, R. H. Deng and H. Zhu. Variations of Diffie-Hellman problem. In Proc. ICICS’03, pages 301-312, 2003. [10] C. Becker and U. Wille. Communication complexity of group key distribution. In Proc. CCS’98, pages 1-6, 1998. [11] M. Bellare, R. Canetti, and H. Krawczyk. A modular approach to the design and analysis of authentication and key exchange protocol. In Proc. 30th Annual ACM Symposium on Theory of Computing, pages 419-428, 1998. [12] M. Bellare, D. Pointcheval, and P. Rogaway. Authenticated key exchange secure against dictionary attacks. In Proc. Eurocrypt’00, pages 139-155, May 2000. [13] M. Bellare and P. Rogaway. Entity authentication and key distribution. In Proc. Crypto’93, pages 232-249, 1993. [14] S. M. Bellovin and M. Merritt. Encrypted key exchange: Password-based protocol secure against dictionary attack. In Proc. 1992 IEEE Symposium on Research in Security and Privacy, pages 72-84, May 1992. [15] R. Bird, I. Gopal, A. Herzberg, P. Janson, S. Kutten, R. Molva, and M. Yung. Systematic design of two-party authentication protocols. IEEE Journal on Selected Areas in Communications, 11(5): 679-693, 1993. [16] J. M. Bohli, M. I. G. Vasco, and R. Steinwandt. Password-authenticated constant-round group key establishment with a common reference string. Cryptology ePrint Archive, Report 2006/214, 2006. http://eprint.iacr.org/. [17] D. Boneh and M. Franklin. Identity based encryption from the Weil pairing. In Proc. Crypto’01, pages 213-229, 2001. [18] D. Boneh and M. Franklin. Identity based encryption from the Weil pairing. SIAM Journal of Computing, 32(3):586-615, 2003. [19] C. Boyd. On key agreement and conference key agreement. In Proc. ACISP’97, pages 294-302, 1997.
15
[20] C. Boyd and J. M. G. Nieto. Round-optimal contributory conference key agreement. In Proc. PKC’03, pages 161-174, 2003. [21] V. Boyko, P. Mackenzie, and S. Patel. Provably secure password-authenticated key exchange using DiffieHellman. In Proc. Eurocrypt’00, pages 156-171, May 2000. [22] E. Bresson, O. Chevassut, and D. Pointcheval. Provably authenticated group Diffie-Hellman key exchange the dynamic case. In Proc. Asiacrypt’01, pages 290-309, 2001. [23] E. Bresson, O. Chevassut, D. Pointcheval, and J. J. Quisquater. Provably authenticated group Diffie-Hellman key exchange. In Proc. CCS’01, pages 255-264, 2001. [24] E. Bresson, O. Chevassut, and D. Pointcheval. Dynamic group Diffie-Hellman key exchange under standard assumptions. In Proc. Eurocrypt’02, pages 321-336, 2002. [25] E. Bresson, O. Chevassut, and D. Pointcheval. Group Diffie-Hellman key exchange secure against dictionary attack. In Proc. Asiacrypt’02, pages 497-514, 2002. [26] E. Bresson, O. Chevassut, and D. Pointcheval. Security proofs for an efficient password-based key exchange. In Proc. CCS’03, pages 241-250, 2003. [27] E. Bresson, O. Chevassut, and D. Pointcheval. New security results on encrypted key exchange. In Proc. PKC’04, pages 145-158, 2004. [28] E. Bresson, O. Chevassut, and D. Pointcheval. A security solution for IEEE 802.11s ad-hoc mode: passwordauthentication and group-Diffie-Hellman key exchange. International Journal of Wireless and Mobile Computing, 2(1): 4-13, 2007. [29] M. Burmester and Y. Desmedt. A secure and efficient conference key distribution system. In Proc. Eurocrypt’94, pages 275-286, 1995. [30] M. Burmester, Y. Desmedt, J. Seberry. Equitable key escrow with limited time span. In Proc. Asiacrypt’98, pages 380-391, 1998. [31] M. Burmester and Y. Desmedt. A secure and scalable group key exchange system. Information Processing Letters, 94(3): 137-143, 2005. [32] R. Canetti and H. Krawczyk. Key-exchange protocols and their use for building secure channels. In Proc. Eurocrypt’01, pages 453-474, 2001. [33] R. Canetti and H. Krawczyk. Universally composable notions of key exchange and secure channels. In Proc. Eurocrypt’02, pages 337-351, 2002. [34] R. Canetti and H. Krawczyk. Security analysis of IKE’s signature-based key-exchange protocol. In Proc. Crypto’02, pages 143-161, 2002. [35] R. Cramer and V. Shoup. A practical public key cryptosystem provably secure against adaptive chosen ciphertext attack. In Proc. Crypto’98, pages 13-25, 1998. [36] W. Diffie and M. Hellman. New directions in cryptography. IEEE Transactions on Information Theory, 32(2): 644-654, 1976. [37] W. Diffie, P. van Oorschot and M. Wiener. Authentication and authenticated key exchange. Designs, Codes, and Cryptography, 2(2): 107-125, 1992. [38] D. Galindo, J. Herranz and E. Kiltz. On the generic construction of identity-based signatures with additional properties. In Proc. Asiacrypt’06, pages 178-193, 2006. [39] C. Gentry. Practical identity-based encryption without random oracle. In Proc. Eurocrypt’06, pages 445-464, 2006. [40] O. Goldreich and Y. Lindell. Session-key generation using human passwords only. In Proc. Crypto’01, pages 408-432, 2001. [41] S. Goldwasser, S. Micali, and R. Rivest. A digital signature scheme secure against adaptive chosen-message attack. SIAM J. Computing, 17(2): 281-308, 1988. [42] S. Halevi and H. Krawczyk. Public-key cryptography and password protocols. ACM Transactions on Information and System Security, 2(3):230–268, 1999. [43] I. Ingemarsson, D. T. Tang, and C. K. Wong. A conference key distribution system. IEEE Transactions on Information Theory, 28(5): 714-720, 1982.
16
[44] M. Just and S. Vaudenay. Authenticated multi-party key agreement. In Proc. Asiacrypt’96, pages 36-49, 1996. [45] S. Jiang and G. Gong. Password based key exchange with mutual authentication. In Proc. Selected Areas in Cryptography’04, pages 267-279, 2004. [46] J. Katz, R. Ostrovsky, and M. Yung. Efficient password-authenticated key exchange using human-memorable passwords. In Proc. Eurocrypt’01, pages 457-494, 2001. [47] J. Katz, R. Ostrovsky, and M. Yung. Forward secrecy in password-only key exchange protocols. In Proc. 3rd International Conference on Security in Communication Networks (SCN’03), pages 29-44, 2003. [48] J. Katz and M. Yung. Scalable protocols for authenticated group key exchange. In Proc. Crypt0’03, pages 110-125, 2003. [49] H. J. Kim, S. M. Lee, and D. H. Lee. Constant-round authenticated group key exchange for dynamic groups. In Proc. Asiacrypt’04, pages 245-259, 2004. [50] Y. Kim, A. Perig, and G. Tsudik. Simper and fault-tolerant key agreement for dynamic collaborative groups. In Proc. CCS’00, pages 235-244, 2000. [51] Y. Kim, A. Perrig, and G. Tsudik. Communication-efficient group key agreement. In Proc. IFIP TC11 16th Annual Working Conference on Information Security (IFIP/SEC), pages 229-244, 2001. [52] J. O. Kown, I. R. Jeong, K. Sakurai and D. H. Lee. Password-authenticated multi-party key exchange with different passwords. Cryptology ePrint Archive, Report 2006/476, http://eprint.iacr.org. [53] U. M. Maurer and S. Wolf, Diffie-Hellman oracles. In Proc. Crypto’96, pages 268-282, 1996. [54] K. G. Paterson and J. C. N. Schuldt. Efficient identity-based signatures secure in the standard model. In Proc. ACISP’06, pages 207-222, 2006. [55] S. Patel. Number-theoretic attack on secure password scheme. In Proc. IEEE Symposium on Research in Security and Privacy, pages 236-247, 1997. [56] K. R. Choo, C. Boyd, and Y. Hitchcock. Errors in computational complexity proofs for protocols. In Proc. Asiacrypt’05, pages 624-643, 2005. [57] D. Steer, L. Strawczynski, W. Diffie and M. Wiener. A secure audio teleconference system. In Proc. Crypto’98, pages 520-528, 1998. [58] M. Steiner, G. Tsudik, and M. Widner. Key agreement in dynamic peer groups. IEEE Transactions on Parallel and Distributed Systems, 11(8): 769-780, 2000. [59] W. G. Tzeng. A practical and secure fault-tolerant conference key agreement protocol. In Proc. PKC’00, pages 1-13, 2000. [60] B. Waters. Efficient identity-based encryption without random oracles. In Proc. Eurocrypt’05, pages 114-127, 2005.
Appendix: Proof of Theorem 1 We begin with some terminology that will be used throughout the proof. A given message is called oracle-generated if it was output by the simulator in response to some oracle query. The message is said to be adversarially-generated otherwise. An adversarially-generated message must not be the same as any oracle-generated message. We refer to the real execution of the experiment, as described above, as P00 . We will introduce a sequence of transformations to the experiment P00 and bound the effect of each transformation on the adversary’s advantage. We then bound the adversary’s advantage in the final experiment. This immediately yields a bound on the adversary’s advantage in the original experiment. Experiment P10 : In this experiment, the simulator interacts with the adversary as before except that the adversary does not succeed, and the experiment is aborted, if any of the following occur:
17
1. At any point during the experiment, an oracle-generated message (e.g., msgA` or msgS ) is repeated. 2. At any point during the experiment, a collision occurs in the hash function H (regardless of whether this is due to a direct action of the adversary, or whether this occurs during the course of the simulator’s response to an oracle query). It is immediate that events 1 occurs with only negligible probability, event 2 occurs with negligible probability assuming CRHF as a collision-resistant hash family. Put everything together, we are able to see that P0
P0
Claim 1. If CRHF is a collision-resistant hash family, |AdvA0 (k) − AdvA1 (k)| is negligible. Experiment P20 : In this experiment, the simulator interacts with the adversary A as in experiment P10 except that the adversary’s queries to Execute oracles are handled differently: for any Execute(Ai11 , · · · , Ainn , S j ) oracle where the adversary has not queried Reveal(Ai`` ) (` = 1, 2, · · · , n) in the end of experiment P10 , the initial group key skPA` (` = 1, 2, · · · , n) established during the group key exchange protocol P are replaced with a random value from an appropriate set. The difference between the current experiment and the previous one is bounded by the probability that an adversary breaks the security of the group key exchange protocol P . More precisely, we have Claim 2. If the group key exchange protocol P is secure against passive eavesdropping, P0 P0 |AdvA1 (k) − AdvA2 (k)| is negligible. Assume that there are m such Execute queries in the end of experiment P10 , the claim is 0(1) 0(m) proved by m sub-experiments P2 , · · · , P2 = P20 , in each of which only one such Execute is 0(0)
handled differently. Let P2 1 ≤ t ≤ m) to be negligible. P
0(t−1)
P
P
0(t−1)
= P10 , we only need to prove |AdvA2
0(t)
P
0(t)
(k) − AdvA2 (k)| (where
0(t)
If |AdvA2 (k) − AdvA2 (k)| is non-negligible, where P2 is for Execute(Ai11 , · · · , Ainn , S j ), we show that the simulator can use A as a subroutine to perform the passive attack to the GKE protocol P as follows. Given the parameters paramsP of a GKE protocol P , the simulator runs the initialization protocol as shown in Fig. 2, expect that paramsP is not generated. To respond to those Execute queries with Reveal asked by the adversary A, the simulator queries ExecuteP and RevealP to the protocol P at first. When A asks Execute(Ai11 , · · · , Ainn , S j ) query, the simulator queries ExecuteP (Ai11 , · · · , Ainn ) and then TestP (Ai11 ) to the protocol P . Suppose that TestP (Ai11 ) = skb where b ∈ {0, 1}, sk0 is the group key while sk1 is a random value from Ω. Let skPA` = skb (` = 1, 2, · · · , n), the simulator constructs Execute(Ai11 , · · · , Ainn , S j ) accordingly (i.e., letting sidiA` ` = g h(skb ) ) and responds to A. 0(t−1)
When b = 0, the distribution of adversary’s view in the current experiment and P2 P
0(t−1)
are identical, and thus the adversary has the same AdvA2 (k). If b = 1, the distribution of 0(t) adversary’s view in the current experiment and P2 are identical, and thus the adversary has P
0(t)
P
0(t−1)
P
0(t)
the same AdvA2 (k). If |AdvA2 (k) − AdvA2 (k)| is non-negligible, the simulator can decide when b = 0 or b = 1 with a non-negligible advantage, and thus win the game against the protocol P.
18
P
0(t−1)
Since the GKE protocol P is assumed to be secure against the passive attack, |AdvA2
(k)−
0(t)
P AdvA2
(k)| must be negligible and Claim 2 is true.
Experiment P30 : In this experiment, the simulator interacts with the adversary A as in experiment P20 except that the adversary’s queries to Execute oracles are handled differently: for any Execute(Ai11 , · · · , Ainn , S j ) oracle where the adversary has not queried Reveal(Ai`` ) (` = 1, 2, · · · , n) in the end of experiment P20 , the final group key skiA` ` (` = 1, 2, · · · , n) are replaced with a random value from G. The difference between the current experiment and the previous one is bounded by the probability to solve the decisional squaring Diffie-Hellman (DSDH) problem over a cyclic group G with a prime order q and a generator g. More precisely, we have Claim 3. If the decisional squaring Diffie-Hellman (DSDH) problem is hard over (G, q, g), P0 P0 |AdvA2 (k) − AdvA3 (k)| is negligible. If the above difference is non-negligible, we show that the simulator can use A as a subroutine to solve the DSDH problem with non-negligible probability as follows. 2 Given a DSDH problem (g, g a , Z), where a is randomly chosen from Z∗q and Z is either g a (denoted as b = 0) or a random element z from G (denoted as b = 1), the simulator (without knowledge of a and b) runs the initialization protocol as shown in Fig. 2, except that (G, q, g) is not generated. To respond to Execute(Ai11 , · · · , Ainn , S j ) query where the adversary A has not queried Reveal(Ai`` ) (` = 1, 2, · · · , n), the simulator chooses a random number r ∈ Z∗q and lets 2 sidiA` ` = (g a )r and skiA` ` = Z r (` = 1, 2, · · · , n). Because all initial group keys have been replaced with random values in experiment P20 , when b = 0, the distribution of adversary’s view in the P0 current experiment and P20 are identical, and thus the adversary has the same AdvA2 (k); when b = 1, the distribution of adversary’s view in the current experiment and P30 are identical, and P0 thus the adversary has the same AdvA3 (k). P0
P0
If |AdvA2 (k) − AdvA3 (k)| is non-negligible, the simulator can decide when b = 0 or b = 1 with a non-negligible advantage, and thus solve the DSDH problem. Therefore, the above difference must be negligible and the claim is true. In experiment P30 , 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 client instance Ai invoked by an Execute oracle, where the freshness only requires that the adversary has not queried Reveal(Ai ) or Reveal(B j ) with the client instances Ai and B j being partnered. This is so because the final group keys for such instances in P30 are chosen at random from G, and hence there is no way to distinguish whether the Test oracle outputs a random group key or the “actual” group key (which is just a random element, anyway). Note that an adversary is allowed to ask the above Test oracle even if he has queried KeyGen or Corrupt oracles, but the probability of correctly guessing the bit b is 1/2, too. Therefore, a server adversary never succeed in the game. The remainder of the proof concentrates on the instances invoked by Send oracles. Experiment P40 : In this experiment, we modify the simulator’s responses to Send01 and Send02 queries. Before describing this change we introduce some terminology. The simulator first runs the protocol initialization as shown in Fig. 2. For a query Send01 (S j , (msgA1 , · · · , msgAn )), where
19
(msgA1 , · · · , msgAn ) is adversarially-generated, if equation (1) holds for ` = 1, 2, · · · , n, then (msgA1 , · · · , msgAn ) is said to be valid. Otherwise, (msgA1 , · · · , msgAn ) is said to be invalid. Similarly, for a query Send02 (Ai`` , msgS ) where msgS is adversarially-generated, if equation (2) holds, then msgS is said to be valid. Otherwise, msgS is said to be invalid. Informally, valid messages use correct passwords or signing keys while invalid messages do not. Given this terminology, we continue with our description of experiment P40 . When the adversary makes oracle queries Send01 (S j , (msgA1 , · · · , msgAn )), the simulator examines (msgA1 , · · · , msgAn ). If it is adversarially-generated and valid, the query is answered as in experiment P40 except that accjS is assigned the special value ∇. In any other case, (i.e., (msgA1 , · · · , msgAn ) is oracle-generated, or adversarially-generated but invalid), the query is answered exactly as in experiment P40 . When the adversary makes oracle queries Send02 (Ai`` , msgS ), the simulator examines msgS . If msgS is adversarially-generated and valid, the query is answered as in experiment P30 except that acciA` ` is assigned the special value ∇. In any other case, (i.e., msgS is oracle-generated, or adversarially-generated but invalid), the query is answered exactly as in experiment P30 . Finally, the definition of the adversary’s success in P40 is changed. If the adversary ever queries Send01 or Send02 with accjS = ∇ or acciA` ` = ∇, the simulator halts and the adversary succeeds. Otherwise the adversary’s success is determined as in experiment P30 . The distribution on the adversary’s view in experiments P30 and P40 are identical up to the point when the adversary queries Send01 or Send02 with accjS = ∇ or acciA` ` = ∇. If such a query is never made, the distributions on the view are identical. Therefore, we have P0
P0
Claim 4. AdvA3 (k) ≤ AdvA4 (k). In experiment P40 , the adversary A succeeds if one of the following occurs: (1) the adversary queries Send01 (S j , (msgA1 , · · · , msgAn )) for adversarially-generated and valid (msgA1 , · · · , msgAn ), that is, accjS = ∇ (let Succ1 denote this event); (2) the adversary queries Send02 (Ai`` , msgS ) for adversarially-generated and valid msgS , that is, acciA` ` = ∇ (let Succ2 denote this event); (3) neither Succ1 nor Succ2 happens, the adversary wins the game by a Test query to a fresh client instance Ai . In the last event, if the fresh client instance Ai is invoked by Send oracles, the messages in these Send oracles have to be oracle-generated. In this case, the group of these Send oracles form an Execute oracle, where the final group key skiA can be replaced by a random value from G on the basis of Claims 1 to 3. P40 To evaluate PrA [Succ2 ], we do the following experiment. Experiment P50 . Given the parameters (paramsS ) of IBS, the simulator responds to all oracle queries as in experiment P40 except that it begins by running a modified initialization as follows. Initialize0 (1k , paramsS )– R
R
R
(paramsP,E , master-keyE ) ← SetupP,E (1k ), (G, q, g) ← GGen(1k ), H ← CRHF(1k ) R
(Client, Server, ClientServerPair) ← UserGen(1k ) For each S ∈ Server, dS ← ExtractE (IDS , paramsE , master-keyE ) R
∗ For each (A, S) ∈ ClientServerPair, pwS A ← {pw1 , pw2 , · · · , pwN } ⊂ Zp
Return Client, Server, ClientServerPair, G, q, g, h, H, paramsP,E,S
The distribution of the adversary’s view on experiments P40 and P50 are identical.
20
P0
Claim 5. If the IBS has existential unforgeability under chosen-message attack, then PrA5 [Succ2 ] is negligible. P0
If PrA5 [Succ2 ] is non-negligible, the simulator can use the adversary A to construct a forger 0 A attacking the IBS scheme as follows. For KeyGen queries asked by the adversary A, the simulator has the adversary A0 to query the challenger of the IBS scheme. Each time the simulator responds to Send01 query asked by A, it checks if the messages are valid or not (note that it knows the decryption key dS and passwords). For oracle-generated Send01 query, the simulator has A0 to query the signing oracle Sd0S of the IBS scheme on the message pidjS |sidjS and returns the signature AuthS . In addition, the simulator responds to all other oracles as in P40 . In case that the adversary A queried Send02 (Ai`` , msgS ) to a fresh client instance Ai`` for adversarially-generated and valid msgS (that is, acciA` ` = ∇), the adversary A0 uses it to forge a signature of the signer S on the message msgS . The freshness of Ai`` ensures that the adversary has not queried KeyGen(PKG, S) before Send02 (Ai`` , msgS ) oracle query. P0
If PrA5 [Succ2 ] is non-negligible, the advantage of the forger A0 attacking the IBS scheme is non-negligible. It is in contradiction with the assumption that the IBS scheme has existential P0 unforgeability. Therefore, PrA5 [Succ2 ] must be negligible and the claim follows. P0
To evaluate PrA5 [Succ1 ], we do the following experiment. Experiment P60 : In this experiment, the simulator interacts with the adversary A as in experiment P50 except that the adversary’s queries to Execute and Send00 oracles are handled differently: for Execute(Ai11 , · · · , Ainn , S j ) and Send00 (Ai`` , S j ) oracles where the adversary has not queried KeyGen(PKG, S), Auth` is computed as EIDS [H(sidiA` ` |pidiA` ` |pw0 )] where pw0 is randomly chosen from Z∗p − Password (i.e., it is not a valid password). The following bounds the effect this transformation can have on the adversary’s advantage. P0
P0
Claim 6. If the IBE scheme is secure against the chosen-ciphertext attack, |AdvA5 (k)−AdvA6 (k)| is negligible. Assume that there are m pairs of client instance Aiλλ and server instance S j in experiment P50 , where (1) sidiAλλ = sidjS and (2) the adversary has not queried KeyGen(PKG, S). The claim 0(1)
0(m)
is proved by m sub-experiments P6 , · · · , P6 = P60 , each of them corresponds to a pair of iλ iλ j j (Aλ , S ). In the sub-experiment for (Aλ , S ), only Execute and Send00 related to Aiλλ and S j are 0(0)
handled differently. Let P6 1 ≤ t ≤ m) to be negligible. P
0(t−1)
P
P
0(t−1)
= P50 , we only need to prove |AdvA6
0(t)
0(t)
P
0(t)
(k) − AdvA6 (k)| (where
If |AdvA6 (k)−AdvA6 (k)| is non-negligible, where P6 is the sub-experiment for (Aiλλ , S j ), we show that the simulator can use A as a subroutine to perform the chosen-ciphertext attack to the IBE as follows. Given public parameters paramsE for an instance of the IBE scheme, the simulator begins by running a modified initialization protocol as follows. Initialize00 (1k , paramsE )– R
R
R
(paramsP,S , master-keyS ) ← SetupP,S (1k ), (G, q, g) ← GGen(1k ), H ← CRHF(1k ) R
(Client, Server, ClientServerPair) ← UserGen(1k ), For each S ∈ Server, d0S ← ExtractS (IDS , paramsS , master-keyS )
21
R
∗ For each (A, S) ∈ ClientServerPair, pwS A ← {pw1 , pw2 , · · · , pwN } ⊂ Zp
Return Client, Server, ClientServerPair, G, q, g, h, H, paramsP,E,S
Let M0 = H(sidiAλλ |pidiAλλ |pwSAλ ) and M1 = H(sidiAλλ |pidiAλλ |pw0 ). Assume that the simulator wishes to challenge the two equal length plaintexts (M0 , M1 ) and the identity IDS . Given the ciphertext C = EIDS (Mb ) where b ∈ {0, 1} is unknown, the simulator responds all of the (t−1) adversary’s queries as in experiment P6 except from Execute and Send00 queries related to iλ Aλ and S j as shown in Fig. 5 and Fig. 6, respectively. Execute(Ai11 , · · · , Ainn , S j ) i
If (∃` such that (A` , S) 6∈ ClientServerPair ∨ usedA`` ) ∨ usedjS , return ⊥ i
i
usedA`` ← usedjS ← TRUE, pidA`` ← pidjS ← {A1 , · · · , An , S}, ` = 1, 2, · · · , n i1 i2 P P P in (skP A1 , skA2 , · · · , skAn ) ← Execute (A1 , A2 , · · · , An ) C (` = λ) R i i sidA`` ← G, Auth` ← msgA` ← A` |sidA`` |Auth` i i EID [H(sidA`` |pidA`` |pwS (` 6= λ) A` )]
sidjS ← sidiA11 , AuthS ← Sd0S [pidjS |sidjS ], msgS ← S|AuthS i
i
i
R
accA`` ← termA`` ← accjS ← termjS ← TRUE, skA`` ← G, ` = 1, 2, · · · , n Return statusiA11 , · · · , statusiAnn , statusjS
Fig. 5. The modified Execute oracle for proof of Claim 6 i Send00 (A`` , S j ) i i i If ¬usedA`` ∨ (A` , S) 6∈ ClientServerPair ∨ termA`` ∨ (S 6∈ pidA`` ), i` pidA` ← {A1 , · · · , An , S} C (` = λ) skP i sidA`` ← g A` , Auth` ← i i EID [H(sidA`` |pidA`` |pwS )] (` 6= λ) A` i` i` i P MsgOut ← A` |sidA` |Auth` , stateA` ← (pidA` , skA` , MsgOut) i Return statusA`` i
return ⊥
i
Send01 (S j , (A`` |sidA`` |Auth` )`=1,2,···,n ) If (∃` such that (A` , S) 6∈ ClientServerPair) ∨ usedjS , return ⊥ usedjS ← TRUE, pidjS ← {A1 , A2 , · · · , An , S}, sidjS ← sidiA11 If MsgIn is adversarially-generated j If ∀`, DdS [Auth` ] = H(sidjS |pidjS |pwS A` ), then accS ← ∇
Else accjS ← termjS ← TRUE, AuthS ← Sd0S [pidjS |sidjS ], MsgOut ← S|AuthS Return statusjS i
Send02 (A`` , S j |AuthS ) i stateA``
i
← (pidA`` , skP A` , FirstMsgOut) i
i
i
If ¬usedA`` ∨ termA`` ∨ (S 6∈ pidA`` ), return ⊥ If MsgIn is adversarially-generated i
i
If VIDS [pidA`` |sidA`` , AuthS ] = 1, then accjS ← ∇ Else
i accA``
Return
i
i
← termA`` ← TRUE, skA`` ← g
2 (skP A ) `
i statusA``
Fig. 6. The modified Send oracles for the proof of Claim 6
Note that an adversarially-generated message which contains A` |sidiA` ` |C in Send01 (S j , ∗)
query, where ` 6= λ or ` = λ but sidiA` ` 6= sidjS , is invalid. The decryption of C is either 22
H(sidiAλλ |pidiAλλ |pwSAλ ) or H(sidiAλλ |pidiAλλ |pw0 ). Because different sessions have different sid, different clients use different passwords, and H is a collision-resistant hash function, we have both H(sidiAλλ |pidiAλλ |pwSAλ ) 6= H(sidiA` ` |pidiA` ` |pwSA` ) and H(sidiAλλ |pidiAλλ |pw0 ) 6= H(sidiA` ` |pidiA` ` |pwSA` ) for the above message, which means equation (1) does not hold for `. Although the simulator cannot query the decryption of C, it can respond to all kinds of Send01 queries involving C properly. 0(t−1) When b = 0, the distribution of adversary’s view in the current experiment and P6 P
0(t−1)
are identical, and thus the adversary has the same AdvA6 (k). If b = 1, the distribution of 0(t) adversary’s view in the current experiment and P6 are identical, and thus the adversary has P
0(t)
P
0(t−1)
P
0(t)
the same AdvA6 (k). If |AdvA6 (k) − AdvA6 (k)| is non-negligible, the simulator can decide when b = 0 or b = 1 with a non-negligible advantage. P
0(t−1)
Since the IBE is assumed to be secure against the chosen-ciphertext attack, |AdvA6
(k) −
0(t)
P AdvA6
(k)| must be negligible and Claim 2 is true.
Now let us consider an adversarially-generated Send01 (S j , (Ai`` |sidiA` ` |Auth` )1,2,···,n ) query to a fresh server instance S j . The freshness of S j implies that the adversary has not queried KeyGen(PKG, S) oracle and any Corrupt(A` ) (` = 1, 2, · · · , n). In experiment P60 , all messages which are dependent of pwSA` (` = 1, 2, · · · , n) have been replaced by those which are independent of these passwords. Therefore, the adversary’s view is independent of the passwords pwSA` (` = 1, 2, · · · , n) chosen by the simulator. In order to win the game, the adversary has to try all passwords one-by-one in an online impersonation attack. The probability that Succ1 occurs is at most Q(k)/N , where Q(k) is the number of online attacks made by the adversary A. In experiment P60 , the adversary succeeds if either Succ1 or Succ2 occurs, or else by guessing the value of b used by the Test oracle. However, if neither Succ1 nor Succ2 occurs and the adversary queries Test(Ai ) where Ai is fresh and acciU = TRUE, then skiA is randomly-distributed in G independent of the adversary’s view. Thus, the adversary’s probability of success when neither Succ1 nor Succ2 occurs is 1/2. The preceding discussion implies that P0
P rA6 [Succ] ≤ Q(k)/N + 1/2 · (1 − Q(k)/N ) and thus the adversary’s advantage in experiment P60 is at most Q(k)/N . The sequence of claims proved above show that P0
P0
AdvA0 [Succ] ≤ AdvA6 (k) + ε(k) for some negligible function ε(·) and therefore the adversary’s advantage in P00 (i.e., the original protocol) is at most Q(k)/N plus some negligible quantity. This complete the proof of the theorem.
23
