Efficient and Secure Keys Management for Wireless ... - CiteSeerX

Efficient and Secure Keys Management for ∗ Wireless Mobile Communications Roberto Di Pietro

Luigi V. Mancini

Sushil Jajodia

Università "La Sapienza" Dipartimento di Informatica Via Salaria, 113 00198 Roma, Italy

Università "La Sapienza" Dipartimento di Informatica Via Salaria, 113 00198 Roma, Italy

George Mason University CSIS 4400 University Drive Fairfax, 22030 VA, USA

[email protected]

[email protected]

[email protected]

ABSTRACT

Categories and Subject Descriptors

This paper presents an efficient algorithm for the secure group key management of mobile users. The most promising protocols to deal with group key management are those based on logical key hierarchy (LKH). The LKH model reduces to logarithmic size the resources needed: computation time, message exchanged, and memory space. In the framework of the LKH model, we present a new protocol LKH++ that outperforms the other proposed solutions in the literature. Such performance improvements are obtained exploiting both the properties of one-way hash functions and the information that the users already share in the LKH model. In particular, when a user eviction occurs in LKH++, each remaining user autonomously constructs a new key along the path from the evicted user to the root as a function of a specific logical child key. Therefore, the center can carry on the re-keying phase by distributing only a subset of the new keys and by reducing the number of communications to the users. When a join occurs, a minimal information is broadcast, while most of the communications are unicast toward just the joining user. The proposed LKH++ protocol establishes a group communication of n users requiring to unicast ((n − 1) log n)/2 keys, while standard algorithms require to deliver n log n keys. Such a solution allows the users to form promptly a new group if the wireless ad hoc network should be reconfigured. Moreover, the proposed extension to deal with mass leave and mass join allows a considerable savings in the messages sent by the center, as well as in the computations required by both the center and the users. Finally, the LKH++ protocol enhances the reliability of the key management due to the reduced number of communications needed in the re-keying phase.

C.2.4 [Computer Systems Organization]: computer communication networks—Distributed Systems; H.4.3 [Information Systems]: information system applications—communication applications; E.1 [Data]: data structures—graphs and networks

∗This work was partially supported by the EU under the IST-2001-34734 EYES project and by the Italian MIUR. During this work, the first author was visiting the CSIS at George Mason University.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. POMC’02, October 30-31, 2002, Toulouse, France. Copyright 2002 ACM 1-58113-511-4/02/0010 ...$5.00.

General Terms Algorithms, Performance, Security

Keywords secure multicast, wireless communications, distributed algorithms, key generation, key distribution, key management protocol, network dynamics management, forward secrecy, collusion, cryptography, backward secrecy.

1. INTRODUCTION 1.1 The scenario Many emerging applications, such as pay per view TV, and stock option bid, are based upon a group communication model. In particular, they require the messages delivery from one or more authorized senders to a large number of authorized receivers. As highlighted in [9, 23], a similar model can be applied in the mobile environment. Thus, security is becoming an important concern to enable the adoption and diffusion of the multicast paradigm. Cryptographic techniques should prevent other users, other than the one authorized, from accessing the content of the delivered messages. As a result, the security of group communications is a critical issue, that is providing confidentiality, authenticity, and integrity of messages delivered between group members. While securing unicast communications for client-server computing is fairly well understood, the technical issues of securing group communications are not. In this paper, the message confidentiality is assured by using simple and efficient symmetric key techniques for group data encryption. Note that, although group communications that use sophisticated cryptographic techniques are proposed in the literature, our choice is motivated by the fact that using asymmetric cryptography would have required much more resources to decrypt messages [17], while wireless mobile devices are usually severely constrained in their resources such as battery power, memory space, and computational power.

This paper focuses on the design of key distribution schemes for secure group communications among mobile users, that is, on the issues of sending private keys to all the mobile users of a group in a secure, efficient and scalable fashion. In particular, we propose a protocol that seems suitable for wireless mobile communications since: (1) each user device stores a number of keys that is logarithmic in the number of devices; (2) the protocol employs symmetric cryptography, thus reducing: (a) the length of the encryption key; (b) the computational efforts required by the user devices to encrypt/decrypt messages and thus saving battery power; (3) the number of multicast messages received from the center is reduced, thus saving the battery power and increasing the communications reliability. Since every point-to-multipoint communication can be represented as a set of point-to-point communications, the current technology for securing unicast communications may seem fairly extensible to secure group communications [10]. However, such an approach does not scale to large groups. Indeed, the secure distribution of the group key to a group of n users requires the encryption of each message with the individual key of each user, that is a communication cost proportional to group size. Alternatively, the set of messages required for the group key distribution might be combined in a single longer message and sent to all group users via a single multicast communication. Either way, there is a communication cost proportional to group size, measured in terms of the number of messages or the size of the combined message. Recent proposals [21, 8, 20] introduce a Key Graph scheme for scalable key distribution that takes Θ(log n) messages to add or to evict a user from a group of n users.

1.2 Security Goals Confidentiality is among the main requirements we consider: only authorized users should decrypt a multicast message, even if this message is broadcasted over a geographical region. The confidentiality requirement can be translated in the context of secure multicast into the following four requirements on key distribution: (1) Non-group Confidentiality: users that were never part of the group should not access any key that can decrypt any multicast data sent to the group; (2) Forward Confidentiality: users deleted from the group at some time t do not have access to any key used to encrypt multicast data after t, unless they are authorized to join again the group; (3) Collusion Freedom: no subset of deleted users should be able to decrypt future group communication, even by sharing the keys they had before their deletion; (4) Backward Confidentiality: a user added at time t should not have access to any key used to encrypt multicast data before t while the user was not part of the group. Note that in accordance with the related literature, such as [11, 20, 21, 12, 4, 13, 14], we assume that legitimate users do not leak their keys to unauthorized users on purpose.

1.3 Parameters of Interest The resources available to the user and to the center are often limited [2, 7]. As proposed in [16], the efficiency of a multicast re-keying scheme can be measured in terms of: (1) communications cost, both unicast and broadcast; (2) computation cost sustained both by the users and by the center. Since communication and computation costs are two con-

flicting constraints of a re-keying scheme, that is, decreasing one implies augmenting the other, this paper strives to find a good trade-off among these two constraints giving priority to minimizing the communication bandwidth required by the center.

1.4 Motivations, Contributions, and Roadmap In this paper, we address the efficiency of the multicast operations which are relevant to the mobile computing paradigm. In particular, in this paper the focus is posed on the efficiency of the group set-up. Indeed, the users subscribing a service want to access that service as soon as possible. As a positive side effect, the increased efficiency in the group setup generates improved efficiency on both eviction and join operations when they involve a large number of users joining or leaving the network. For example, consider a large set of users which is in the coverage area of a base radio station (BRS) and that wants to join the group already managed by the BRS. To achieve our goals, we introduce a new way to exploit the features of the LKH model. In particular, (1) the set of information the users share in the LKH model are used to generate locally the new keys without the need of communication among the center and the generating users; (2) the keys that a user logically shares from a certain point upward along the path to the root of the LKH tree are computed autonomously by applying a one-way hash functions. The paper is organized as follows. Section 2 describes the recent solutions proposed in the literature for secure group communications. Section 3 illustrates how our LKH++ protocol deals with the group operations (join and leave), and discusses the security and reliability properties of the LKH++ protocol. In section 4, we compare the performance of LKH++ protocol with the performance of the other protocols presented in Section 2. Finally, we expose our concluding remarks.

1.5 Notation, and System Assumptions In this paper, n is the group size, K is the size of a key in bits, d is the ariety of the tree and h = log d n is the height of the key tree; unless otherwise specified, we will assume d = 2. Moreover, without loss of generality, we assume a balanced key tree [21]. In the LKH++ protocol, the center maintains a tree of keys. The internal nodes of the tree correspond to auxiliary keys and the leaves correspond to the group members (users). Each user stores all the auxiliary keys along its path to the root. We refer to an auxiliary key at level l kept by user uj to Klj . Moreover, each user uj holds a secret key that is known only by uj and the center. We refer to such a key as private key Pj . We assume that the private key of a user has been established between the center and the user via some private secure channel. The root of the tree is shared by all the users and its associated key is the key used to encrypt the payload traffic. The ancestor set of a node in the key tree is given by all the nodes along the path from its parent node to the root. Each user: (1) knows its private key and the auxiliary keys associated with each node in its ancestor set; (2) has the capability to compute a one-way hash function H as [1, 15]; (3) has the capability to generate locally a pseudo random number (PRN) invoking the function G(). The function G() can be implemented by applying the hash function H to

Table 1: Summary of the notation employed. n number of users in the group height of the LKH tree (if balanced h = log n) h size of a key in bit K Kij is the key at level i on the path uj -root Kj is the key associated to the intermediate node j G key generation Decryption D E Encryption user ID (takes log n bit) I H hash function X,⊕ xor operation

1

some state variables local to the user, as in [3]. The center can compute the same PRN without any communications, since the center is aware of the state of each user. Table 1 summarizes the notation employed in the rest of the paper.

2.

RELATED WORKS

The Logical Key Hierarchy (LKH) model was introduced in [11, 20, 21] to deal with secure multicast. In particular, this model allows an efficient update of the group key when a user joins or leaves the group. With the LKH, a key distribution center (center in the following) maintains a key tree which will be used for group key update and distribution. Each intermediate node in the tree represents a cryptographic symmetric key. The key distribution center associates each group member (user) with one leaf node of the tree. Each user knows all the key from its leaf node up to the root, the set of such keys is referred to as key path. All users know the key at the root node, and that key is employed to encrypt the payload traffic. In [19] a protocol is proposed called LKH+. The performances achieved by LKH+ are better than those in [21] since instead of encrypting new key values with their respective children’s key, these values are simply hashed. In this way, only the indexes of the refreshed keys need to be multicast. Note that an index size is smaller than the key size. LKH+ is related to the protocol proposed in rfc2627. The OFT protocol [12, 4] requires each re-keying message to carry just log n keys instead of 2 log n as in the basic LKH model. In particular, each intermediate node is associated 0 with two cryptographic keys: a key Kx and a key Kx = H(Kx ), where H is a one-way function. The key Kx0 is blinded in the sense that it is computationally unfeasible, for 0 an adversary, to derive Kx from Kx . Each member knows the unblinded node keys on the path from its node to the root, and the blinded node keys that are siblings to its path to the root, and no other blinded or unblinded keys. When the key of a node changes, its blinded version is encrypted with the key of its sibling node. Thus, the re-keying message carries just log n keys. The ELK protocol [13] focuses on secure multicast for large groups. Such protocol addresses also reliability issues for secure multicast. The ELK protocol is similar to OFT, but ELK employs pseudo random functions to build and manipulate the keys in the tree. ELK is based on periodic re-keying, that is at given time interval the center refreshes User uj holds the key Kij if the intermediate node i is on the path uj -root. Note that in this case Kij = Ki 1

the root key using the pseudo random functions and then uses it to update the whole key tree. One of the main advantages of ELK is that by deriving all keys, the protocol does not require any multicast message during a join operation. Indeed, all members can autonomously refresh their own keys. Deletion, as in OFT, requires that new keys are generated from the children’s keys. In [14], the use of the old keys to create or update the new keys saves the information to be transmitted to the users when a membership change occurs. Two operations are performed on local key by the users: (1) refresh which requires the user to receive an index from the center to generate a new local key; (2) update which requires the user to receive an index from the center to generate either the left or the right child key. Given that the users refresh or update their local key only on the base of the old key, an extra message from the center containing the index is required to enforce backward secrecy.

3. THE LKH++ PROTOCOL Our contribution to improve the LKH model, is based on the following observations: (1) the users share many auxiliary keys. To better explain this consideration, take into account, for a generic user ug its path ug -root. For each of the keys Kjg along the path ug -root, there is a set of users that do not have to access Kjg , and there is another set that has to share key Kjg . In particular, if user ui and user uj share a key, then they must share all the auxiliary keys from that key upward along the path to the root. On the other hand, if the same two users do not share a certain auxiliary key K f , then the two users do not share any other keys from K f down to the leaves; (2) the information shared by the users can be exploited to generate new shared keys without communicating with the center. We will apply such considerations to manage group initialization and group dynamics in an efficient way.

3.1 Improving LKH Initialization Group initialization is the process through which the group establishes an initial group communications key. Assume that the center assigns to each user its private key via some secure channel. The other keys on the logical path ug -root must be either generated locally by a generic user ug , or received from the center. We construct the key tree by allowing the user ug to generate locally some of the auxiliary keys along its path to the root. In particular, user g ug generates key Kjg if and only if Kj−1 is the left children of Kjg , otherwise user ug receives Kjg from the center. If the g user has to generate that key, it simply applies H to Kj−1 . The pseudo code for the distributed algorithm for the generation of the key tree is given in figure 1, where it is assumed a tree of ariety two. An example of a key tree built by the algorithm is shown in figure 3, where the notation K2 = H(H(P1 ))(u3 , u4 ) means that the key associated with the intermediate node 2 is computed applying H(H(P1 )) and that such a value is sent by the center to users u3 and u4 . According to the LKH model, such transmission is encrypted by key K5 . Theorem 1. The number of multicast messages employed by the center to build the key tree is n − 1. Proof. The proof is by induction on the height of the tree. Assume the height is h = 1, as in figure 2.a, then

Veck[0]=Pj ; FOR i=1 TO h BEGIN % the ID of the node determines which keys can be % generated locally, or received by the center IF (ID MOD 2)=1 THEN BEGIN - user uj generates the key -; Veck[i]=H(V eck[i − 1]); ID = dID/2e END ELSE BEGIN - user uj must receive the key -; Receive(Kij ); Veck[i]=Kij ; ID = dID/2e END END. Figure 1: The distributed algorithm run by uj to build its key path to the root. 1 K 1 = H(P 1) u2 2

1

3

h=p

h=p−1 u1

u2

P1

P2 u1

(a)

u2^(p−1)

u2^(p−1)+1

with P2 , therefore the claim is true, that is the center sent n−1 = 1 unicast message and the size of the message unicast in bit is n(h/2)K = 2/2K = K. Assume that the claim is true for h = 2, . . . , p − 1, we have to prove it holds for h = p. Given h = p we have a situation like the one depicted in figure 2.b. Now, each of the two subtree is a subtree of height h = p − 1, therefore by the inductive hypothesis, each of these subtree requires the center to send 2p /2 − 1 unicast messages, for a total size of transmitted bit equal to ((2p /2)(p − 1)/2)K. Note that the root of the key tree K1 can be computed as H(K2 ), see figure 2.b. Therefore, K1 is known by all the leaves of the left subtree, hence the center does not need to communicate K1 to any of the leaves of the left subtree. On the other hand, K1 must be communicated to all the leaves on the right subtree. This requires sending 2p−1 unicast messages to the leaves of the right subtree. Therefore, the total number of unicast messages sent by the center is (2p /2 − 1) + (2p /2 − 1) + 1 = 2p − 1. The total number of bits sent is given, by inductive hypothesis, by the number of bits required by the left subtree of height p − 1, plus the number of bits required by the right subtree of height p − 1, plus the number of unicast bits required to communicate K1 to the users in the left subtree, that is ((2p /2)(p − 1)/2 + (2p /2)(p − 1)/2 + 2p /2)K = (2p (p − 1)/2 + 2p /2)K = 2p (p/2)K bits. Thus the claim.

3.2 Managing Group Dynamics u2^p

(b)

Figure 2: (a): key assignment for h=1; (b) key assignment for h=p. user u1 autonomously generates its path to the root, while the center has to send to user u2 only the key K1 , encrypted with P2 , therefore the claim is true. Assume that the claim is true for h = 1, . . . , p − 1, we have to prove it holds for h = p. Given h = p we have a situation like the one depicted in figure 2.b. Now, each of the two subtree is a subtree of height h = p−1, therefore by the inductive hypothesis, each of these subtree requires the center to send 2p−1 − 1 messages. Note that the root of the key tree (K1 ) can be seen as the pth value generated by the seed given to user u1 . Moreover, the root K1 is generated by all the leaves of the left subtree, and therefore the center does not need to communicate it to any leaves of the left subtree. On the other hand, the root of the tree of height p needs to be communicated to the leaves of the right subtree. Note that, by induction, K3 is known to all the leaves of the right subtree. Therefore, the center can send key K1 to the leaves of the second subtree, encrypting it with K3 and broadcasting such message. Hence, the total number of messages that the center has to send is equal to 2p−1 − 1 + 2p−1 − 1 + 1 = 2p − 1 = n − 1. Thus the claim. Theorem 2. The number of unicast messages necessary to build the key tree is n − 1, where the total size of the messages unicast is n(h/2)K. Proof. The proof is by induction on the height of the tree. Assume the height is h = 1, as in figure 2.a, then user u1 autonomously generates its path to the root, while the center has to send to user u2 only the key K1 , encrypted

In order to guarantee backward and forward secrecy (see Section 1.2), the auxiliary keys hold by an evicted user should be changed. Each auxiliary key to be changed can be locally generated from its child key which is not on the eviction path. Thus, the new generated keys must be distributed among the remaining authorized users, since each user knows only a subset of the new set of keys. Our approach allows the center to reduce the number of update messages since each user can generate locally a portion of the new key path. The proposed protocol that changes all the keys on the path ue -root is discussed in Section 3.3.1 with the help of an example.

3.3 Eviction 3.3.1 Single Eviction Referring to figure 3, the eviction of user u8 requires that users {u1 . . . u4 } should apply G(K2 ) to generate the new K1 , users {u5 , u6 } should generate the new K3 = G(K6 ), and user u7 should generate the new K7 = G(P7 ). Note that the generation of these new keys can take place in a complete parallel fashion among the devices. In this way, each of the remaining n − 1 legitimate user, knows only one value of the new key path u8 -root. Therefore, the center has to communicate to each user, the missing set of the new keys on the path u8 -root, for example user u7 needs to receive the new keys {K1 , K3 }. The center can compute these new keys applying the function G on its internal representation of the key-tree. Lemma 1. A single eviction from a set of n user requires log n − 1 messages from the center. Proof. User us , the sibling of the evicted node, has to update the longest portion of the key path, let alone the s s key Kh−1 which can be generated locally by us as Kh−1 =

K 1 = H(H(H( P 1)) ) (u5,..,u8)

K 2= H(H( P 1) ) (u3, u4)

1

2

3

K 3 = H(H( P 5) ) (u7, u8)

K 6 = H( P 5) (u6)

K 4 = H( P 1) (u2)

4

5 K 5= H( P 3) (u4)

7 K 7 = H (P 7) (u8)

6

u1

u2

u3

u4

u5

u6

u7

u8

P1

P2

P3

P4

P5

P6

P7

P8

Figure 3: An example of group initialization with LKH++. G(Ps ). Following a bottom up key distribution protocol, the center takes only log n − 1 messages to communicate to us and the other legitimate users the relevant portion of the new keys on the path ue -root. Lemma 2. A single eviction from a set of n users requires that an authorized user performs at most (log n − 1)(H + X) computations. Proof. The user us that has to update the longest portion of its path is the sibling of the evicted user. It is at level s h and has already autonomously computed key Kh−1 . User us needs to receive the other log n − 1 keys by the center. Since each of this key is encrypted as in Section 4.1.1, it must perform (log n − 1)(H + X) operations to recover the remaining keys.

3.3.2 Multiple Eviction This section addresses the multiple eviction problem assuming that the system is composed of n users, r of which need to be evicted. Below, we discuss the worst case in Theorem 3, and the best case in Lemma 3. As in [18], the worst case occurs when there is a user to be evicted exactly each n/r − 1 authorized users. The best case occurs when all the r users are clustered together. Theorem 3. Evicting r users from the system requires r (log n/r) − 1 messages in the worst case. Proof. The prove is by induction on the number of users evicted. Without loss of generality, we can assume that the number of users to be evicted is a power of two. Let r = 1, then as seen in lemma 1 the eviction of a single user requires log n − 1 messages and the theorem holds. Let us assume that the claim is true for r = 2, . . . , 2j−1 , we have to prove the claim holds for r = 2j . We assume that there is a user to be evicted exactly each n/r leaves. Consider the maximum subtree that has among its leaves one and only one evicting user. Under the hypothesis that the evicting users are uniformly distributed among leaves, we have that each of these maximum subtrees has its root at height log n/r = h − j. For each of these subtrees, by inductive hypothesis (there is only one evicting member among its leaves) the center can perform the eviction by sending log n/r − 1 messages. After the re-keying of each subtree, we have a situation in which all the intermediates nodes from level j + 1 to level 0 still need to be changed. As seen in theorem 1, given m users, we can construct the key tree with m − 1 messages by the center. We apply this theorem considering leaves the r roots of the log n/r subtrees. We can construct the corresponding tree with r − 1 messages. The total number of messages sent is therefore r(log n/r − 1) + r − 1 = r log n/r − 1 and hence the claim.

Lemma 3. Evicting a cluster of r users from the system requires log n/r − 1 messages in the best case. Proof. Assume that the r = 2j users to be evicted are clustered together, such that they can be seen as leaves of a subtree of height j. Let Kje be the root of such a subtree. The keys that need to be changed are those on the path Kje -root which ranges from level j + 1 to level 0. All that must be done is to communicate the appropriate portion of the path to the legitimate users. This can be done with h − (j + 1) messages from the center, where h − (j + 1) = h − j − 1 = log n − log r − 1 = log n/r − 1 .

3.4 Join 3.4.1 Single Join When a single user uj joins the multicast group, to guarantee backward secrecy, all the keys on the path uj -root need to be changed before uj joins the group. The path can be changed more efficiently for a join operation than for an eviction, since all the users currently in the group are legitimate, and the old keys can be used to communicate the new one before uj joins the group. The procedure is the following: first, the center broadcasts that the existing user us will have a new right sibling; then the center broadcasts a random number of length K encrypted by the group key to all the current users. Finally, each user decrypts this random number, and executes an xor between each of its keys and the received random number. In this way, all the keys that will be disclosed to uj are changed, and the backward secrecy is preserved. The user us , sibling of the joining node uj , will generate autonomously the key Khs applying G(Ps ) and hence us does not need any communication from the center. The path uj root will be communicated to uj via a unicast message of size (log n + 1)K bit. Lemma 4. The join of user uj requires uj to compute (log n + 1)(H + X) operations. Proof. The center sends log n + 1 unicast messages of size K, encrypted as explained in Section 4.1.1.

3.4.2 Multiple Join For the execution of a multiple join the number of unicast messages increases linearly with the number of the users to be joined, since each new user needs to receive individually the new key path. However, the center has to send only one multicast message to renew all the key paths of the current users, that is the center pays for a multiple join the same broadcast communication cost paid for a single join. It is worth noting the following particular case. As it has been shown in Section 3.1, it is possible to create a key tree

with n users, requiring only n − 1 broadcast messages from the center. Suppose that the multiple join operation is a mass join, that is the number of joining users is j ≥ n/2. The creation of a separate key tree composed of only these j users requires j − 1 messages. Moreover, all the users of the new tree can generate locally another key, say Kr , from their root key. Then, the merge of the two key trees can be done communicating to the old tree the new key Kr with a single multicast message. The key Kr becomes the new root of the two key trees. All these operations require only j − 1 + 1 = j multicast messages from the center. The procedure of creating a separate key tree for the joining users and then merging such a new tree with the old tree is always possible, but note that the fewer the joining users with respect to the number of the existing user, the more the final tree will be unbalanced.

4.

PERFORMANCE EVALUATION AND COMPARISON

4.1 Performance Evaluation 4.1.1 From Encryption to Hashing In our protocol, the center encrypts the new key to be sent to the legitimate users as follows. Assume that the center wants to encrypt key K 0 with key Kc ; the center computes the hash of key Kc , executes the xor of the key K 0 with such a value, that is K e = H(Kc ) ⊕ K 0 , and then sends K e to the legitimate users. The receiving users ui will recover K 0 via H(Kc ) ⊕ K e . However, note that if two users with two different keys Kc and Kc0 receive the same secret in two individual communications, each user can recover the hashed seed of the other. Indeed, a user um holding Kc0 could recover H(Kc ) as follows: H(Kc ) = (H(Kc ) ⊕ K 0 ) ⊕ K 0 , where K 0 is known by um and H(Kc ) ⊕ K 0 is eavesdropped. So the next message encrypted with key H(Kc ), and directed only to users holding Kc could be possibly decrypted by um . To solve this problem, the center and the receiving users after each application of H(Kc ) increase by one unit Kc , yielding Kc+1 , and employ the key Kc+1 at the next application of function H. The security of this scheme relies on the properties of the one-way hash functions [1, 15]. That is, it is computationally unfeasible for an attacker, during the ith application of this method, to recover Kc+i even given H(Kc+i ), . . . , H(Kc ).

4.1.2 Security Analysis This section comments briefly on the security features of the LKH++ protocol. The security properties of LKH++ stem from the strength of the one-way function used, and from the initial random selection of private keys. Note that even if one-way hash functions are not theoretically secure [6], we can reasonably rely on computational security [1, 15]. The LKH++ protocol provides forward and backward secrecy as well as collusion free, indeed: (1) backward secrecy: the join of new users does not affect this property, since the old keys are scrambled with a random seed generated by the center. Without such a nonce, it is computationally unfeasible for any new user to infer any past key; (2) forward secrecy: the evicted users have no information about the key tree to infer the new keys. Indeed, after a user

is evicted, the keys along the path from the user to the root are changed. This property enforces forward secrecy; (3)collusion free: since the new keys are derived from a set of information that is not available to any coalition of the evicted users, it is computationally unfeasible for the evicted users to recover any of the keys in the LKH tree, thus our LKH++ protocol is collusion free. We assumed in Section 1.2 that legitimate users do not leak their keys to unauthorized users, so the security analysis of this threat is out of the scope of this paper. However, it seems that the LKH model can tolerate also the case in which legitimate users leak their keys. Indeed, if a legitimate user A leaks its keys to a set B of unauthorized users, when user A is evicted from the center, also the unauthorized users in B lose the keys to decrypt the messages. That is, the unauthorized users can decrypt the messages only as long as A can.

4.1.3 Impact on Reliability It has been seen in Section 3.1 that LKH++ reduces the number of messages sent by the center, since users can autonomously compute one new key from the keys they already own. It is out of the scope of this paper to specifically address reliability, but it is worth noting that our LKH++ protocol improves reliability in secure multicast. Indeed, LKH++ reduces the total number of keys that the center has to send, and therefore our protocol reduces the probability that a message is lost or corrupted, and must be re-transmitted because the users have not received it. To appreciate the impact of LKH++ on reliability, consider a single eviction. In the standard LKH model the total number of keys that have to be received by the users are h−1 i i=0 2 (h − i). Our LKH++ protocol requires the users to h−1 i i receive h−1 i=0 2 (h − i − 1) = i=0 2 (h − i) − (n − 1) keys, hence saving n − 1 keys transmissions. Another advantage of LKH++ is that it allows the local generation of critical keys from the communication point of view, that is some keys that should be sent to a large group of users can be generated locally without any communications. For example in the case of single eviction, our protocol allows n/2 users to compute the only key they need (that is the root key) without requiring any communication. To better delve with reliability issue, we refer the reader to [13, 22].

4.2 Comparison In this subsection, we show a comparison of our model with the performance attained by the other related works described in Section 2, that is OFT [12], LKH+ [19], ELK [13] and EHBT [14]. Further details of the evaluation model can be found in [14]. The parameters of interest in assessing protocol performance are the following: (1) computation performed by the users and by the center; (2) size of the messages sent by the center, distinguishing between unicast messages and multicast messages. As for computations, note that in our protocol any encryption/decryption operation reduces to a single computation of a one-way hash function and a simple xor operation, if the technique described in Section 4.1.1 is applied. The application of a one-way hash function requires less computational efforts than the application of an encryption function, like 3-DES. Moreover, note that a xor operation is far less com-

Table 2: Comparison of the cost of single user eviction. Model LKH++ EHBT ELK OFT LKH+

Computation Center Sibling h(2X + 2H) h(H + X + E) 8hE h(H + X + E) 2hE

Multicast Message size

(h − 1)(H + X) h(X + H) hD + 5hE D + h(H + X) hD

I + (h − 1)K I + hK I + h(n1 + n2 ) I + (h + 1)K I + 2hK

Table 3: Comparison of the cost of multiple users eviction. Model

Computation

Multicast Message size

Center LKH++ EHBT ELK OFT LKH+

n(X + H) (2n − 1)(H + X) + (n − 1)E (7n − 3)E (2n − 2)H + (n − 1)X + (3n − 2)E (2n − 2)E

putational expensive than the application of a one-way hash function. In the following, we assume that an encryption function E is as expensive as the application of a one-way hash function H. Table 2 considers the case of a single eviction from the multicast group. Note that our protocol requires to multicast at least one message less than the other protocols as can be seen in the last column on the right. This slight saving is due to the fact that each user computes locally a new key of the path ue -root. In table 3 we focus on the worst case analysis, in which exactly half of the the group members leaves the group, and the evicted members are uniformly distributed among the members that stays in the group. Note that in the ELK protocol, if we want to guarantee a level of security which is equal to the one enforced by the others protocol, we have to set n1 + n2 = K bits. Indeed, since ELK employs only n1 + n2 bits to generate the new key, an adversary has to compute 2n1 +n2 new keys before recovering the new one. Moreover, our protocol requires less than 50% of the computations performed by the center with respect to the other solutions in the literature. Indeed, the left column of table 3 shows that our protocol needs only n computations of the hash function, while the others require at least 2n of such computations. This performance is achieved by applying the group initialization mechanism exposed in Section 3.1 to the remaining users, that is to the users that do not have to be evicted. In table 4 we deal with the join of a single user. Note that LKH++ requires the center to multicast only K + I bit (see last column on the right), while EHBT, OFT, and LKH+ require the center to multicast a number of bit which is bounded to the number of users in the multicast group, since h = log n. Even for small values of the group size, e.g. 1024 users, the number of bits multicast by LKH++ is less than those required by the other methods. In particular, EHBT and LKH+ multicast hI bits which for 1024 users is about 100 bits. Indeed, an optimal coding for I requires at least log n = h bits, hence the number of multicast bits is hI ≥ h2 which is larger than K +I for practical values of the key length, and of the size of the multicast group. Moreover, LKH++ performs better as for the number of computations

Sibling + (h−1) (X + H) 2 D + (h + 1)(X + H) hD + 5hE (h + 1)D + h(H + X) hD

(h−1) H 2

nI + (n − 1)K nI + (n − 1)K nI + (n − 1)(n1 + n2 ) nI + (3n − 2)K nI + 2(n − 1)K

required both by the center and by the sibling of the joining user, if compared with the ELK protocol which, however, multicasts 0 bit for the join of a single user. Table 5 reports the performance measures for the case when the number of joining users is equal to the number of existing users, which is recognized as the worst case for joining operations [14]. In the table, n is the original number of users in the group, while h is the new height of the tree after the mass join. As can be seen in the third column from right, LKH++ outperforms all the other protocols, with an average gain of 50% in unicast communications, as shown in theorem 2.

5. CONCLUDING REMARKS This paper has revisited the LKH model, and has introduced a brand new way to exploit the LKH model to take advantage of: (1) the set of information the users share and that can be used to locally generate the new keys; (2) the set of keys that the users logically share from a certain point onward in the LKH, and that allows the users to compute autonomously their path to the root employing a one-way hash functions. In this way, it has been shown how to reduce of the 50% the bandwidth required by the center for unicast communications to perform group set-up, and to deal with mass join. Moreover, our model allows to save more than the 50% of the computations required by the center in mass evictions and requires less computations on the user device than the other solutions. Finally, it has been mentioned how our model improves the overall reliability of re-keying, while preserving a memory occupation that is logarithmic in the size of the users in the multicast group. These results are particular useful in a wireless mobile environment where (1) the battery consumption should be reduced; (2) the devices have a limited amount of available memory; (3) the communications can be error prone.

6. REFERENCES [1] N. F. P. 180-1. Secure hash standard. Draft, NIST, May 1994. [2] M. Abdalla, Y. Shavitt, and A. Wool. Key management for restricted multicast using broadcast

Table 4: Comparison of the cost of a single user joining the multicast group. Model Center LKH++ EHBT ELK OFT LKH+

(h + 1)(2X + H) + H G + (h + 1)(X + H + E) G + (4n − 2)E and (h + 3)E G + (h + 1)H + hX + 3hE 2G + hH + (h + 1)E

Computation Join member (h + 1)(H + X) (h + 1)D (h + 1)D (h + 1)D + h(H + X) (h + 1)D

Sibling

Join unic.

Message size Sibling unic.

Multicast

G + H + X + hX (h + 1)(H + X) 2hE and 2E 2D + h(H + X) D + hH

(h + 1)K (h + 1)K (h + 1)K (h + 1)K (h + 1)K

0 I I I + 2K I +K

K+I hI 0 (h + 1)K hI

Table 5: Comparison of the cost of multiple users joining the multicast group. Model Center LKH++ EHBT ELK OFT LKH+

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11] [12]

[13]

Computation Join member

(n + 1)(X + H) nG + (3n − 1)(X + H) + n(h + 1) + E (8n − 2)E and nG + n(h + 3)E nG + (4n − 2)(H + X) + (nh + 5n − 1)E 2nG + (n − 1)H + n(h + 2)E

Sibling

((h + 1)H + h 2 X) (h + 1)D (h + 1)D (h + 1)D + h(H + X) (h + 1)D

encryption. IEEE/ACM Transaction on Networking, 8(4), 2000. Michel Abdalla and Mihir Bellare. Increasing the lifetime of a key: A comparative analysis of the security of re-keying techniques. In ASIACRYPT, pages 546–559, 2000. D. Balenson, D. McGrew, and A. Sherman. Key management for large dynamic groups: One-way function trees and amortized initialization. Internet draft, IETF, June 2002. S. Berkovits. How to broadcast a secret. In Springer-Verlag, editor, Advances in Cryptology, EUROCRYPT 1991, volume 547 of Lecture Notes in Computer Science, 1991. S. Bkhtiari, R. Safavi-Nini, and J. Pieprzyk. Cryptographic hash functions: A suervey. technical report, Unversity of Wallongon, July 1995. R. Canetti, T. Malkin, and K. Nissim. Efficient communication-storage tradeoffs for multicast encryption. In Springer-Verlag, editor, Advances in Cryptology, EUROCRYPT 1999, volume 1592 of Lecture Notes in Computer Science, 1999. G. Caronni, M. Waldvogel, D. Sun, and B. Plattner. Efficient security for large and dynamic multicast groups. In IEEE Computer Society Press, editor, Proc. of the Seventh Workshop on Enabling Technologies, (WETICE ’98), 1998. Li Gong and Nachum Shacham. Multicast security and its extension to a mobile environment. Wireless Networks, 1(3):281–295, 1995. H. Harney and C. Muckenhirn. Group key management protocol (GKMP) architecture. RFC 2094, July 1997. H.Harney and E. Harder. Logical key hierarchy protocol. Internet draft, IETF, April 1999. David A. McGrew and Alan T. Sherman. Key establishment in large dynamic groups using one-way function trees. Technical Report 0755, TIS Labs at Network Associates, Inc., Glenwood, MD, May 1998. Adrian Perrig, D. Song, and D. Tygar. ELK, a new protocol for efficient large-group key distribution. In

[14]

[15] [16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

(H + X) (h + 1)(H + X) 2DE and 2E 2D + h(H + X) D + hH

Message size Join unic. (n :) Sib. unic. (h + 1)/2K (h + 1)K (h + 1)K (h + 1)K (h + 1)K

0 n:I n:I n : I + 2K n:I +K

Multicast 2K (n − 1)I 0 2(n − 1)K (n − 1)I

Proc. of 2001 IEEE Symposium on Security and Privacy, pages 247–262, 2001. Sandro Rafaeli, Laurent Mathy, and David Hutchison. EHBT: an efficient protocol for group key management. Lecture Notes in Computer Science, 2233:159–171, 2001. R. Rivest. The MD5 message-digest algorithm. RFC 1321, April 1992. R. Safaci-Naini and H. Wang. New constructions for multicast re-keying schemes using perfect hash function. In Proc. of the 7th ACM Conference on Computer and Communications Security, 2000. Bruce Schneier. Applied Cryptography: Protocols, Algorithms and Source Code in C. John Wiley & Sons, 1996. J. Snoeyink, S. Suri S, and G. Varghese. A lower bound for multicast key distribution. In Proc. of IEEE INFOCOM 2001: Conference on Computer Communications, 2001. Marcel Waldvogel, Germano Caronni, Dan Sun, Nathalie Weiler, and Bernhard Plattner. The versakey framework: Versatile group key management. IEEE Journal on Selected Areas in Communications, 17(9):1614–1631, September 1999. D. Wallner, E. Harder, and R. Agee. Key management for multicast: Issues and architectures. RFC 2627, June 1999. C. K. Wong, M. Gouda, and S. S. Lam. Secure group communications using key graphs. IEEE/ACM Transaction on Networking, 8(1), 2000. Yang Richard Yang, X. Steve Li, X. Brian Zhang, and Simon S. Lam. Reliable group rekeying: a performance analysis. In Proc. of the 2001 conference on applications, technologies, architectures, and protocols for computer communications, pages 27–38. ACM Press, 2001. Kan Zhang and Tim Kindberg. An authorization infrastructure for nomadic computing. In Seventh ACM Symposium on Access Control Models and Technologies, pages 107–113. ACM Press, 2002.