Bresson-Chevassut-Essiari-Pointcheval의 저전력 모바일 장치를 위한 키 동의 방식의 안전성 분석

Cryptanalysis of Bresson-Chevassut-Essiari-Pointcheval′s Key Agreement Scheme for Low-Power Mobile Devices

Abstract

Bresson 등은 최근에 발표한 논문에서 무선 네트워크 환경에 적합한 그룹 키 동의 방식을 제안하였고 이의 안전성을 증명하였다. 하지만 본 논문에서는 Bresson 등이 제안한 그룹 키 동의 방식이 여려가지 공격에 취약함을 보임으로써 안전성 증명에 오류가 있음을 입증한다.

Bresson et al. have recently proposed an efficient group key agreement scheme well suited for a wireless network environment. Although it is claimed that the proposed scheme is provably secure under certain intractability assumptions, we show in this paper that this claim is unfounded, breaking the allegedly secure scheme in various ways.

Ⅰ.Introduction

In many ways, security risks for mobile computing are similar to those for other computing platforms. There are the usual concerns of protecting privileged information, authenticating users and devices. However, the devices' strict limitations on hardware and software characteristics add to the challenges. Due to serious resource constraints on mobile devices, security solutions targeted for more traditional networks are often not directly applicable to wireless networks. In this sense it has been of particular interest to devise an efficient protocol for secue wireless communications.

Though secure key distribution is of vital concern to anyone interested in communicating securely over a public net- work, the design of key exchange protocols that are secure against an active adversary is not an easy task to do, especially in a multi-party setting: there is a long history of protocols for this domain being proposed and subsequently broken by some active attacks (e.g., [1-2]). Consequently, key exchange protocols must be subjected to the strictest scrutiny possible before they can be deployed into an ad~ versarially controlled network.

The recent work of Bresson et al. proposed a very efficient group key agreement scheme well suited for unbalanced networks consisting of devices with strict power consumption restrictions and wireless gateways with less stringent restrictions. The proposed scheme consists of three protocols: the setup protocol GKE. Setup, the remove protocol GKE.Remove, and the join protocol GKE.Join. The main GKE.Setup protocol allows a set of mobile devices (also called clients) and a wireless gateway (also called server) to agree on a common secret key called a session key. To meet the efficiency needs of clients, the protocol shifts most of computational burden to the gateway and provides mobile devices with the ability to perform public-key cryptographic operations offline. The other protocols of the scheme allow the server to efficiently handle dynamic membership changes of clients in one wireless domain.

In this paper we show that the Bresson et al.'s group key agreement scheme is completely insecure, presenting various attacks against the three protocols of the scheme.

Ⅱ.Review of Bresson et al/s Scheme

Let G be a finite cyclic group of /-bit prime order q, where Z is a security parameter, and let g be an arbitrary generator of G. Both G and g are known to all parties in the network. There are three hash functions H : {0, 1}* —>(0, 1} 1, 从:{0, 1}*t { 0, 1}气 where /0 needs not be equal to I, and 研:{0, 1} ‘ x G ―where I、is the maximal bit-length of a counter c used in the scheme.

2.1 Long-Term Key Generation

We denote by S the server and by C the set of all clients that can participate in the protocols. Before the setup protocol is run for the first time, an initialization phase occurs during which:

1. The server S sets its private/public keys to be (SKs PKs) = (x, y), where and y= gx.

2. Each client UeC generates a pair (SIJ PK) of signing/verifying keys by running the key generation algorithm of a signature scheme.

2.2 The GKE.Setup Protocol

Let GceC be a set of clients who wish to establish a session key with the server S. In the protocol, each client U产 G。 generates an ephemeral Diffie-Hellman pair (%,饥=g吗)，which then leads to a secret value % =产 shared between the client Ui and the server S. Signatures are used for authenticating the clients. Let Ic be the set of indices of the clients in Gc. The actual protocol executes in two rounds as follows：

Round 1. Each client UqGc chooses a random 旳任 易q, and precomputes % = 9農', %=?广 and a signature o; of 无 under the signing key SK、Each client 〔7? then sends (y, -. or) to the server S.

Round 2. For each message 3.W, the server S verifies the signature oz using PKj and if the verification succeeds, computes the value a- = . Then S initializes the counter c to 0, computes the shared secret value

#

and sends to each client S the values c and K;=丿邮 4((』%).

Key computation. After recovering the shared secret value K as

#

each client S (and S) computes their session key as:

#

2.3 The GKE.Remove Protocol

Let 7? be a set of clients leaving an existing client group Gc. Then, the GKE.Remove protocol is run to provide the sever S and the remaining clients with a new session key sk. After the client group Gc is updated to be Gc\ R, the protocol proceeds as follows.

Round 1. The server S increases the counter c and computes the common secret value

#

S then sends to each client U冃丄 the values c and 瓦. = K㊉ § (c H %).

Key computation. After receiving the values c and Kit each client UeGC first checks that the new counter is greater than the old one, and simply recovers the common secret value K and the session key sk as follows:

#

2.4 The GKE.Join Protocol

Let 7 be a set of new clients who want to join an existing client group Gc. Then, the client group Gc is updated to be GCU J and the GKE.Join protocol is run to provide S and each client with a new session key sk. The protocol proceeds as follows:

Round 1. Each new client U产J chooses a random %, and precomputes Vj=9!, OLj=yJ and a signature o- of y, under the signing key SKh Each client then sends o;) to the server S.

Round 2. The server S verifies the incoming signatures, and if correct, operates as in the setup protocol, with an increased counter c; it computes the shared secret value

#

and sends to each client UieGc the values c and

Key computation. Each client sGc already holds the value at=y' and the old counter value (set to zero for the new ones). So it first checks that the new counter is greater than the old one, and simply recovers the shared secret value K and the session key sk as follows:

#

Ⅲ. Attacks on the GKE.Setup Protocol

In this section we show that the GKE. Setup protocol does not meet the main security properties; implicit key authentication, forward secrecy, and known key security.

3.1 Implicit Key Authentication

The fundamental security property for a key exchange protocol KEP to achieve is implicit key authentication, which is defined in the following contextC₄₁]. Let s庇 be the session key computed and accepted by Ui as a result of protocol KEP. and let U be the set of the intended participants of KEP. Then we say that KEP provides implicit key authentication if each U is assured that no party UkeU can learn the key 闻 unless helped by a dishonest U产U.

To 아low that the GKE.Setup protocol does not provide implicit key authentication, we consider two runs of the protocol which are executed in an either concurrent or non-concurrent manner. We denote by Gc and G c the sets of clients with respect to the first and second runs, respectively. Assume that the adversary A participates as a client in the first run of the protocol (i.e., A eGc), but is intended to be excluded from the second run (i.e., AeG'cU{S}). Also assume that two client sets Gc and Grc are non-disjoint. The goal of adversary A is to share the same key with the participants of the second run. To do so, the adversary A gathers some information during the first run and uses that information to impersonate some client in the second run. The detailed attack scenario is as follows-

1. In the first run of the protocol, the adversary A computes the shared secret value K participating as a normal client. A then obtains for all ieIc by computing

which can be done without knowing cq. The adversary A records II %) and (饥’)for all i ejc.

2. . In the first round of the second run, the adversary A (pretending to be Uj for some UJeGcr\G, c) replaces the message (幻,。')sent by Uj with oy) stored in the previous step of this scenario. Because the server S thinks that is from Uh it will compute the shared secret value K as per protocol specification and will send to client Uj the values c= 0 and

#

with d. computed as

3. In the second round of the second run, the adversary A reads K; which is transmitted through an open channel. Now, from the values K? and 耳(시It》(obtained in the first step of this scenario), the adversary A can recover the shared secret value K as follows-

#

This equation holds, since q; = 여 and thus 4(厂此'丿)=4(引的). Finally, the adversary A can share the same session key sk' = H(Kf II G' c II S) with all the participants of the second run except U、

Consequently, there seems to be little reason to expect that the GKE.Setup protocol provides implicit key authentication, as soon as the adversary participates as a client in a protocol execution and is intended to be excluded from another protocol execution with a non-disjoint set of clients.

3.2 Forward Secrecy

The perfect forward secrecy property says that earlier session keys are protected against loss of some underlying information at the present time. As noted by the authors themselves, the GKE.Setup protocol does not provide perfect forward secrecy: as soon as the long-term private key x of the server is leaked, all the past session keys can be recovered since every q can easily be computed from y, and

However, it is claimed by the authors that the protocol achieves partial forward secrecy: disclosure of the private signing keys of clients does not reveal anything about previous session keys. In support of this claim, they argue that the long-term keys of the clients are used for implicit authentication only, and not for hiding the session key. But, this claim is flawed. The attack Elow shows that if some client's signing key is ever revealed, then any previous session key can be computed by an active adversary. As a simple scenario, we consider two runs of the protocol with the first one being completed before the second one begins. Similarly as before, we denote the client groups with respect to the first and second runs of the protocol by Gc and Gf c respectively. Assume that the adversary A wants to recover the session key established in the first run of the protocol in which she has not participated. The attack is launched as follows:

1. In the first run of the protocol, the adversary A eavesdrops on the session recording the transmitted messages and

#

for some ieIc.

2. Now, the adversary A participates as a client in the second run of the protocol. Because we consider forward secrecy, we will assume that the private signing key SK} of some other client Uj Gf c is exposed to A.

3. In the first round of the second run, the adversary A proceeds much like a normal client by sending the message (yrAi oe) to the server. In the same time period, the adversary A (pretending to be the client U» replaces the message 3'丿 o') sent by Uj with where o, r ■ is the signature of yt- (stored in the first step) under the private key SK, Note that the adversary A can sign any message of its choice on behalf of U>

4. Because the verification of signature 。':will succeed, the server S will compute 屯 as

and the shared secret value K' as per protocol specification. Then S will send to client Uj the values c= 0 and

#

5. Now, in the second round of the second run, the adversary A should be able to compute the shared secret value K since it participates as a group member. From K' and K'> the adversary A can recover 名泠此;)as follows:

#

6. With this information &(시la;), the adversary A can recover the shared secret value K of the first run of the protocol as follows;

#

since a(- =dj and thus 耳(c H %)= II arj). Finally, A can compute

the session key sk — Gc II S) of the first run.

Therefore, once an underlying key is exposed, there is nothing to prevent an adversary with the key from accessing privileged information communicated in earlier sessions.

3.3 Known Key Security

A protocol is said to provide known key security if compromising some session keys does not allow a passive adversary to compromise keys of other sessions, nor an active adversary to impersonate one of the protocol parties. In this subsection. we will extend our security analysis of the protocol by presenting an active known key attack. We will assume two sessions of the protocol with the same participants. Then the following attack is possible:

1. In the first run of the protocol, the adversary A eavesdrops on the session recording the transmitted messages 3, 。)and (c, K) for all ieIc. Since we consider known key attack, we will assume that the session key K of this run is revealed to A.

2. In the first round of the second run, the adversary A replaces the message (V o\) sent by each 1人 with 0, ) obtained in the previous step.

3. Since all the y-s are replayed, the server S will compute the same session key as computed in the first run of the protocol.

Therefore, at the end of this scenario, the server S will share with the adversary A the key that has been shared by all participants of the first session of the protocol.

Ⅳ.Collusion Attack on the GKE.Remove Protocol

Let Ax and A2 denote two colluding adversaries. First, consider two existing sessions of the GKE.Setup protocol with the client groups Gc (AltA2 Gc) and Gc (c), respectively. Now, assume that the adversaries & and A2 move from G'c to Gc, and thus two new sessions of the protocols are opened- in the first session, the GKE.Join protocol is executed with the client group Gc — GCU {&血}; while in the second session, the GKE.Remove protocol is executed with the client group G' c= G\\ {AitA2}. We also assume that G℃G'芦。.Then, the following attack on the second session, where the GKE.Remove protocol is executed, is possible:

1. Before moving from G c to Gc, in the second run of the setup protocol, one of two adversaries, say A2, records the message o\) sent to S by some client UkeGcC\ Grc.

2. Now, after moving from G'c to Gc, the adversaries A】 and A2 participate in the run of the join protocol. In the first round of this run, the adversary sends to S th슨 message (电, c財)exactly following the protocol specification. In the same time period, the adversary A2 generates the signature o of y k (obtained in the previous step of this scenario) under her signing key SK 厶 and sends the message (儿。瓦)to S. In the second round, S operates as specified in the protocol, verifying the received signatures, increasing the counter(', computing aX|, % =1广Z and K, and sending out the keying material to the clients in Gc.

3. Now that the two colluding adversaries & and A2 receive from S the messages (g&Q and &呵)respectively, they can easily obtain the value Hx{c II without knowing aAi, The adversaries first compute K as

#

using o4i, and then, from K, recover

4. Now, in the run of the GKE.Remove protocol with the client group G c (UkwG'", the adversaries eavesdrop on the message (d, K'》sent by S to the client Uk. Meanwhile, after receiving the messages from S, the clients in Gr c operates as specified in the protocol, checking that the new counter is greater than the old one, recovering the common secret value K', computing the session key skr as-

#

But, this session key skr can be also obtained by the adversaries. Since c= c and 知=«欢, and thus II a&)=4(c' II afk) t the adversaries can compute K' as

#

using 瓦)obtained in the run of the join protocol, and hence the session key skr.

Consequently, all the users taking part in the remove protocol share a session key with and A2.

Ⅴ.Interleaving Attack on 하le GKE.Join Protocol

We now show that 나re GKE.Join protocol does not satisfy implicit key authentication. Lets assume that a set of new clients, J, wants to join two existing sessions of the GKE.Setup protocol with the client groups Gc (Gc) and Gf c (AwG'c), respectively. Assume further that the clients in J are permitted to join, and thus two concurrent runs of the GKE.Join protocol are opened with the new client groups Gc= GJJJ and G'c=G'cU/ respectively. Then, an interleaving attack can be launched against the clients in JeG1 c. As can be observed in the following attack, increasing the counter (in the second round of the GKE.Join protocol) does not play any role to prevent relaying messages between two sessions from leading to a successful attack.

1. In the first round of the second run, the adversary intercepts all the messages (Vo\) sent to S by the clients in juG'c.

2. In the first round of the first run, the adversary A replaces the message (yjt sent to S by each client Uj in JuG。with obtained in the previous step of this scenario.

3. In the second round of the first run, the server S verifies all the received signatures. All these signature verifications should be passed since they have been honestly generated by the clients themselves. After the verifications are complete, S operates as specified in the protocol, computing % as ol- for each new client Uj in juGc and increasing the counter c. The server S then sends to each client Ui in Gc the values c and

and to the adversary A the values c and Ka=K&HJ、c II aA).

Now, the adversary A records all the messages sent by S to the other clients while recovering the shared secret value K from KA.

4. In the second round of the second run, the adversary A (pretending to be the server S) sends to each client Uj in JuGthe message (c, K> obtained in the second round of the first run. After receiving this message from A, each client in 7cG\ first checks that the newly received counter is greater than the old one: this verification will succeed since the server S increased the counter for the first run of the protocol. Then, each client in JuG、recovers K from Kj and compute the session key as:

#

At the end of this attack, the clients in JuGc believe that they have established a secure session with S sharing a secret key skr, while in fact they have shared it with A.

Ⅵ.Improvement

To frustrate the attacks, we must somehow prevent information obtained in some sessions from being used for a successful attack on any other session. At first glance, it seems like that the weakness of the scheme is solely because the counter c is always initialized to the same value 0 in the setup protocol. However, we note that increasing the counter monotonically with each new session of the protocol is not enough by itself to solve the security problems. Indeed, with this modification alone, the protocol can still be broken by an interleaving attack in a scenario where two sessions of the protocol are executed concurrently: note that the interleaving attack described in the previous section does not require that two counter values used in two concurrent sessions be the same. But fortunately, it turned out that we can easily solve the security problems without compromising the efficiency of the original scheme, by modifying the counter management scheme and the computation of K? to the following:

1. During the initialization phase, the server S and all clients in C initialize their own counter c to 0.

2. The server S increases the counter c monotonically with each new session of the protocols, and computes each Ki as

#

3. Upon receiving the message (cj, ) from the server S, each client UQG(. checks that the newly received counter is greater than the old one, recovers the shared secret value K as

#

and updates its counter to the new value.

Our improved version is as efficient as the original scheme, meeting the efficiency needs of clients; it provides low-power mobile devices with the ability to perform all of the public-key cryptographic operations off-line.

Ⅶ. Conclusion

The recent work of Bresson et al/3j proposed an efficient group key agreement scheme which consists of three protocols, the setup protocol GKE.Setup, the remove protocol GKE.Remove, and the join protocol GKE.Join. But unfortunately, this group key agreement scheme is completely insecure since:

1. The GKE.Setup protocol does not meet the main security properties, namely, implicit key authentication, forward secrecy, and known key security.

2. The GKE.Remove protocol can be broken by a collusion attack in a scenario where it is executed concurrently with the GKE.Join protocol.

3. The GKE.Join protocol is also vulnerable to an interleaving attack.

본 연구는 정보통신부 및 정보통신진흥원의 대학 IT연 구센터 육성•지원사업의 연구결과로 수행되었음