Balanced Batch LKH: New Proposal, Implementation and Performance Evaluation.

Transcription

1 Balanced Batch LKH: New Proposal, Implementation and Performance Evaluation. Josep Pegueroles, Francisco Rico-Novella Departamento de Ingeniería Telemática. Universitat Politècnica de Catalunya. Jordi Girona 1 y 3. Campus Nord, Mod C3, UPC Barcelona josep.pegueroles@entel.upc.es Abstract Perfect Secrecy can only be achieved in multicast groups by ciphering data sent to the group with a different key every time a member joins or leaves the group. A Key Server must send the new key to all the remaining members so bandwidth efficiency concerns appear. Logical Key Tree algorithms reduce the number of messages to be sent, but in many scenarios, rekeying after each membership change has no sense. Batch rekeying algorithms are proposed as a solution to these problems. However such methods need to maintain the Logical Key Tree balanced all the time in order to achieve maximum bandwidth efficiency. This paper presents a new technique for multicast batch rekeying. This technique reallocates the tree nodes in order to keep the tree balanced all the time. 1. Introduction When adding security features to multicast communications a common secret shared by all the multicast group members is needed. The shared key provides group secrecy and source authentication [1]. This key must be updated every time the membership of the group changes. When it does, Forward and Backward Secrecy (FS and BS) are provided. FS means that the session key gives no meaningful information about future session keys, that is to say no leaving member can obtain information about future group communication. BS means that a session key provides no meaningful information about past session keys and that no joining member can obtain information about past group communication [2]. A centralized trusted entity called Key Server (KS) requires N messages each encrypted with a member private key in order to distribute initial group key to a group of N users. Same number of encrypted messages is needed for trivially distributing new group key when membership changes. Several works address the issues of initially distributing the group key to all users and rekey when group membership changes. Most of the methods trying to reduce the number of required messages for rekeying are based on multilevel logical binary trees of Key Encryption Key (KEK) [3,4,5]. When used over a reliable multicast, this approach results in a quite efficient key update mechanism in which the number of multicast messages needed for updating the Session Key is proportional to the depth of the tree. If KEK tree is balanced, depth of the tree is O(log N), where N is the number of members in the multicast group. However, for large groups, join and leave requests are very frequent and usually bursty in nature. Different scenarios, such as Web-TV, show a high volume of signon/sign-off requests at peak times. In these cases, individual rekeying after each join or leave is relatively inefficient. Batch rekeying techniques have been recently presented as a solution to overcome this problem. In such methods, a departed user will remain in the group longer, and a new user has to wait longer to be accepted. All join and leave requests received within a batch period are processed together at the same time. An example of batch rekeying is presented by Lam-Gouda in [6]. Nevertheless, this method assumes that the KEK tree is kept balanced across multiple batches. However, depending on the actual locations of the request, it is possible that the key tree may grow unbalanced after some number of batches. This work presents a new method for batch rekeying that leads to complete balanced trees. The proposed algorithm preserves the Lam-Gouda algorithm simplicity and improves efficiency since no additional rebalancing algorithm is needed. Furthermore, keeping the tree balanced at any time avoids extra rekeying messages due to tree depth beyond O(log N). The rest of this paper is organized as follows. Section 2 presents Logical Key Hierarchy methods as the most common way to increase bandwidth efficiency in secure multicast rekeying. Section 3 introduces the Batch Rekeying techniques as a method for achieving more bandwidth efficiency. Section 4 details the new Balanced Batch Rekeying algorithm. Finally in section 5, we present performance evaluation of this method and compare it to Lam-Gouda technique. 2. Rekeying in secure multicast The main problem when managing secure multicast groups is to distribute new symmetric session keys to members every time a user joins or leaves the group. The

2 trivial way of doing it involves encrypting the message containing the new session key as many times as members the multicast group has (N). Once with each secret key shared between a Key Server (KS) and the corresponding member. In many scenarios such as Web-TV or multi-party network games, N may be very large, therefore, multicast key distribution leaks scalability. In the last years, many proposals have been published in order to overcome the scalability problem in Group Key Management [7,8,9]. However, the most promising protocols are those based on logical binary trees of KEKs [3,4]. Next we briefly describe the most significant and successful technique. 2.1 Logical Key Hierarchy: LKH In key tree schemes two types of encryption keys are used: Session Encryption Keys (SEK) and Key Encryption Keys (KEK). SEKs are used to cipher the actual data that multicast groups exchange, for example, video streams in multicast videoconference sessions. KEKs are used to cipher the keying material that members need in order to get the SEK. Normally, KEKs are structured in logical binary trees. The root of the key tree is shared by all users and the leaf nodes are users' individual keys. We will adopt the next criterion as naming convention for the rest of the paper. Tree nodes will be referenced as (level number, position at level), so we will refer to root node as (1,1); sons of root node will be (2,1) and (2,2) and so on. An example of key tree is shown in Fig.1a. Key in node (X,Y) will be noted as K (X,Y). Consider a group of 8 users. See Fig. 1a. The tree has 15 nodes, each node corresponds to a KEK. Group members are located at leaf nodes. Keys in the leaves are only known by single users. K (1,1) is known by all members in the group. The rest of the keys are revealed only to users considered sons of the node. For example, K (3,1) is known only by users in leaves (4,1) and (4,2), and K (2,2) is only revealed to users in nodes (4,5) to (4,8). The LKH key management scheme works as follows. Consider the multicast group in Fig.1b with N=7 members (M1..M7) and a centralized group controller (KS). Each member must store a subset of the controller's keys. These subset of KEKs will allow the member to get the new SEK when it changes. A generic member (Mj) stores the subset of keys in the path from the leaf where he is to the root. In our example, member M1, in node (4,1), will store K (4,1),K (3,1), K (2,1) and K (1,1) Managing joinings When a new member (Suppose M8 in Fig. 1a) joins the group he must contact the KS via a secure unicast channel. Then they negotiate a shared key that they will use in later interactions (K (4,8) ). After that, the controller must update every KEK in the path from the leaf, where new member is located, to the root. See Fig 1a in which new keys are noted with quotes. The KS has to reveal the updated keys to the corresponding users. He uses the existing key hierarchy, along with reliable multicast, to efficiently distribute them as follows. He sends two messages containing the whole set of updated keys, one to each of the members in nodes (4,7) and (4,8), via a unicast channel and using their individual keys. After that, he constructs and sends a multicast message containing K (2,2) and K (1,1) ciphered with K (3,3), so only members in nodes (4,5) and (4,6) can decipher it. Finally, he also constructs and sends a multicast message containing new root key K (1,1) and ciphered with K (2,1), so members in nodes (4,1) to (4,4) can decipher it. At this point, the 8 members in the multicast group know the subset of keys from their leaves to the root. Every member knows the root key, so this is used to cipher a multicast message containing the new session key (SEK ) Managing leavings Now, assume that member M4 leaves the group. All keys along the path from node (4,4) to the root must be changed. K (4,4) is simply deleted. See Fig 1b. The updated KEKs are multicasted to the remaining group members encrypted under keys in sibling nodes of the updated ones. In our example, KS first sends the whole set of updated keys to node (4,3) via a unicast channel, and using the individual key of member M3 to cipher it. After that, constructs and sends a multicast message containing K (2,1) and K (1,1) ciphered with K (3,1), so only M1 and M2 can decipher it. Finally, he sends a multicast message containing K (1,1) ciphered with K (2,2), so members in nodes (4,5) to (4,8) can decipher it. At this point, all keys that M4 knew while he was a member of the group have been updated, so he has been excluded from any future communication. Following the example it is easy to see how the binary tree-based key management scheme can update keys using 0(log2(N)) messages, where N is the number of members in the multicast group. a) Joining b) Leaving Figure 1. LKH example

3 3. Batch Rekeying With binary key tree techniques, individual rekeying has reached his lower bound in number of required messages for rekeying (O(logN)) [10]. Recently, some works have proposed batch rekeying to overcome this limit. In batch rekeying algorithms join and leave requests are collected during a time interval and processed in a batch. Since the KS does not rekey immediately, a leaving member will remain in the group till the end of the batch period, and a new member will have to wait the same time to be accepted. However, this batch period can be adapted to dynamics in the multicast group. On the other hand, batch rekeying techniques increase efficiency in number of required messages thus it takes advantage of the possible overlap of new keys for multiple rekey requests, and thus reduces the possibility of generating new keys that will not be used. 3.1 Lam-Gouda batch rekeying In [6] Lam, Gouda et al. presented a very simple marking algorithm that updates the key tree and generates a rekey subtree. Briefly, their system can be summarized as follows. After each rekey interval the KS collects all Join and Leave requests and processes them according to the two possible cases. If the number of leavings is greater or equal than the number of joinings, new members are allocated in the places of the departed members. Empty leaves are marked as null. All node keys in the path from the replaced leaves to the root are updated following the rules in LKH. If the number of joinings is greater than the number of leavings a rekey subtree is constructed with all the remaining new members left after applying the algorithm described above. The rekey subtree is allocated under the departed user node with the smallest height. 4. Balanced Batch Rekeying The algorithm explained in the previous section aims to keep the tree balanced through different batches by allocating the rekey subtree under the shallowest node in each rekeying. However, this rebalancing system is only valid when the number of joinings and leavings are very similar, in any other case a periodic rebalancing algorithm is needed. In Fig 2, it is easy to see how the tree grows unbalanced through different batches. In this example, in the first batch, same number of joinings and leavings is requested, so the tree is kept balanced. In Fig 2b members in nodes (4,4) and (4,8) ask for departing the group, but no joining is requested; so nodes (3,2) and (3,4) become leaf nodes with private keys of remaining members. In the third step, Fig 2c, three joinings and no leavings are asked again, this time, the rekey subtree is allocated under node a) Batch with same number of leavings and joinings c) Batch with 3 requested joinings and no leaving member (3,1), the shallowest one. Finally, in Fig 4d two of the members under node (2,2) want to leave the group. After the 4 batches only 6 members are left and therefore only a 4 degree key tree is needed, instead of that, the KS must keep a tree of degree Proposed algorithm Figure 2 b) Members 4 and 8 leave the group d) 2 leavings under node (1,1) and no joining In order to overcome this inefficiency we propose a new batch rekeying algorithm that keeps the tree balanced for every batch. The algorithm updates not only node keys but also node naming or position, so rekeying nodes can change their original position after each batch following a very simple rule. The KS computered system does not have much more processing load cause he only has to update the position of the nodes using simple rules. Besides that, keeping the tree balanced reduces the total amount of required program memory. In the other side, the new algorithm slightly increases the number of operations to be done by individual members, cause they have to know all the time the position in the tree that they are occupying in order to update it properly. However, this increase is not significant for single multicast members, even if they are devices with low computation capability. Next, we will describe the atomic steps the KS and the individual members must follow to carry out the algorithm Key Server Side There are four main actions that the KS has to do every batch: marking the rekeying nodes, prune the tree, make new rekey tree and construct and send the multicast rekeying messages.

4 Mark Rekeying Nodes In the first step, nodes that should be removed have to be pointed out. After collecting the leaving requests, all nodes from leaving members leaves to root need to be updated, so they are marked for deletion. Notice that no replacement with joining members is carried out. This is why the important figure in this algorithm is the reusing of subtree nodes, and in Lam-Gouda algorithm replaced nodes and its siblings also have to be updated. Prune Tree The prune action is very simple, it consists in deleting the marked nodes and keep the subtree structures that remain unchanged. After this action, the KS has to manage three types of elements: remaining subtrees (structures with more than one members), joining members and siblings of leaving members. As the tree is a binary tree, siblings of leaving members cannot reuse any KEK but his individual key, so they should be treated the same way as new joining members. Make New Rekey tree Now, the KS has to construct the new rekey tree balanced following the next recursive criterion. Group all trees of depth j in twos. If any element is left, group it with tree of depth j+1 and treat the result as a tree of depth j+2. The criterion must begin with trees of minimum depth, that is to say, single elements, and be repeated until just only one tree is resulted. Construct and Send Rekey Messages Finally, the rekeying messages have to be sent. These messages should include three information fields: destination node, new position of destination node and rekeying material. The destination node is the node to which sons the message is addressed. This field is used by single members to decide whether the rekeying message concerns to them or not. The new position is the renaming field of the message. Using this information, users can rename themselves and their keying material. The rules used for renaming are explained in the next subsection. The Rekeying material field is the actual data of updated keys, calculated, for example, according to LKH Multicast Member Side Basically the multicast member only has to decide if a multicast rekeying message is sent to him, receive it and update his position and keying material. Receive Rekey Message A single member (located in node (m,n) will only listen to a message if the coordinates of the destination node field (say (i,j)) comply with the following conditions. m i (2) m i m i m i ( j 2 ) (2 1) n j 2 (3) Update Position and Keys After deciding if a message concerns him, node (m,n) and keys are renamed using the new position field (p,q) in rekeying message. The renaming follows the next expressions. m = p + ( m i) (4) ( m i) ( m i) n = q 2 ( j 2 n) (5) Re-used keys and new keys are also renamed according to relative position with new node name Further considerations It is important to note that the most important function from all the above described ones is the update of the tree. This function shows the main differences between the proposed balanced batch LKH algorithm and the Lam- Gouda technique. In the update tree step of the algorithm, subtrees that can be reused are treated the way they lead to a minimum number of rekeying messages and balanced new key tree. 5. Performance evaluation There is a long history of network and Internet traffic analysis. The majority of this, however, looks at packet level and network level traces, and does not examine session level user dynamics. We want to study and simulate the behavior of our new algorithm, so we had to consider different models to generate join/leave request patterns. Next we present the different considered scenarios and the used models. 5.1 Benchmark scenarios Two benchmark scenarios are given in [2] as those to consider when studying or simulating multicast systems: single source broadcast and virtual conferences. However, we have included a third one in order to fit more precisely the real multicast world. We have used three simple models to generate user behavior patterns, one for each of the mentioned scenarios. Next we briefly describe how we have considered them.

5 5.1.1 Single source broadcast In this scenario a single source continuously broadcasts data to a large number of recipients. A typical example of this scenario is Pay-TV. The number of recipients can be up to hundreds of thousands and more. The life-time of the group is usually long. Group membership is dynamic: members join and leave at a relatively high rate. At peak times a high volume of sign-on/sign-off requests are expected. Almeroth and Ammar [11] started the study of user behavior for single source multicast sessions many years ago. A simple way of modeling user behavior at session level is by means of exponential distribution interarrival time. We have used two exponential random number generators to simulate request arrivals at KS. One for joinings and another one for leavings. In Fig 3a it is shown a sample pattern of our model for single source broadcast and the histogram for Web-TV interarrival time Virtual conferences Virtual conference scenarios include on-line corporate meetings, interactive lectures... A virtual conference involves several tens to hundreds of peers. Usually most, or all, group members wish to transmit data. The group is often formed per event and is relatively short-lived (say, few minutes or hours). Membership is often static: members join at start-up, and remain signed a) Join/Leave pattern for WebTV b) Join/Leave pattern for virtual conference c). Join/Leave pattern for NetGames on throughout. We have found no studies about user behavior modeling for virtual conferences. However, according to the previously mentioned features, we have developed a very simple model that we have used for virtual conferences. A random number of users stablish a virtual conference. After a random period of time users begin to join/leave the group following an exponential interrequest time statistics. See Fig 3b Multiplayer video games In multiparty networked games the number of players strongly depends on time-of-day and network externality effects. The presence of other users alters other users behaviors. Player interarrival times are highly correlated at short lags which implies that the arrival of some users will lead to others arriving. Moreover, interarrival times and number of players in a session shows an inversely proportional relationship; as the number of players in a session increases, the interarrival time decrease. So number of players is a deteminant in other player s decisions to join a group. In [12] Henderson and Bhatti found that interarrival times for networked games follow a heavy-tailed distribution. We have used this result to generate patterns according to lognormal distribution for joinings and exponential for leavings. See Fig 3c. 5.2 Results Simulations for the comparison of our new algorithm to Lam-Gaouda batch rekeying were done. As expected, in all cases the balanced algorithm showed a better behavior than Lam-Gouda in terms of tree depth. Next, results for the three different benchmark scenarios are considered. Statistically generated join/leave patterns were used. The pattern life for network games was 12 hours considered every second (x axis). Except in case of peak times, only a joining or a leaving can be considered every second. Different batch periods were considered, from 5 minutes to 50 minutes (y axis). In Fig 4a it is plotted the tree depth behavior for the two considered algorithms (z axis). It can be seen how the balanced batch rekeying method leads to less depth for all the cases. Results for virtual conference show similar behavior. It is important to note that joining/leaving traffic pattern was generated to fit a monotonic increase in number of members. For virtual conference, only a life of an hour was considered (x axis). Measures were taken for different batch periods (y axis), and population was dynamic but always between 256 and 512 members. In Fig 4b can be easily seen how the balanced algorithm preserves the same tree depth for every time and batch, while Lam Gouda tree depth increase with time. Figure 3. Benchmark scenarios

6 Finally, web-tv environments for a period of monotonic increase of number of members have the same behavior. Fig 4c. Differences in the increase rhythm can be explained according to peak time arrivals. As new members arrive in a batch at peak times, Lam-Gouda algorithm has to construct a very big rekey subtree and allocate it in the old tree, this makes the tree grow quickly. Instead of that, balanced algorithm, reconstruct the whole tree and achieves a slowly growth. 6. Conclusions In this research, we have presented a new rekeying technique for batch joining and leavings. The new method is based on Logical Key Hierarchy protocol but avoids rekeying for every single membership change. Unlike other existing batch rekeying methods, the proposed technique keeps the Key Tree balanced all the time. Balancing the tree reduces the number of encrypted messages to be sent in order to distribute the new session key. Results for performance evaluation have also been presented. Acknowledgments This work is supported by the Spanish research council under project DISQET (CICYT TIC ) and CREDO (CICYT - TIC ) References [1] Wallner, Harder, Agee. Key Management for Multicast: Issues and Architectures. RFC [2] R. Canetti, J. Garay, G. Itkis, D. Micciancio, M. Naor, and B. Pinkas, it Multicast security: A taxonomy and some efficient constructions INFOCOM 99. Eighteenth Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE, vol. 2, pp , [3] Harney, Harder. Logical Key Hierarchy Protocol (LKH). I-D Harney-sparta-lkhp-sec-00. Mar 99. Work in progress. [4] Balenson, McGrew, Sherman. Key Management for large Dynamic Groups: One-Way Function Trees and Amortized Initialization. Aug 2000 I-D irtf-smuggroupkeymgmt-oft-00. Work in progress [5] Canetti, Malkin, Nissim. Efficient Communication Storage Tradeoffs for Multicast Encryption. Eurocrypt99 pp [6] Li, Yang, Gouda, Lam. Batch Rekeying for Secure Group Communications}. ACM SIGCOMM 2001, San Diego, August 2001 [7] H. Harney, A. Colegrove, E. Harder, U. Meth, R. Fleischer, it Group Secure Association Key Management Protocol (GSAKMP), draft-irtf-smug-gsakmp-00.txt, November 2000, Work in Progress. [8] H. Harney, C. Muckenhirn, Group Key Management Protocol (GKMP) Specification, IETF, RFC 2093, July [9] T. Hardjono, B. Cain, Simple Key Management Protocol for PIM}, draft-ietf-pim-simplekmp-01.txt, Feb 2000, Work in Progress. [10] Snoeyink, Suri, Varghese (2001). A Lower Bound for Multicast Key Distribution}. IEEE INFOCOM [11] Almeroth, Ammar, (1997) Multicast Group Behavior in the Internet's Multicast Backbone (MBone), IEEE Communications, June 1997 [12] Henderson, Bhatti (2001). Modelling user behavior in networked games. Proceedings of ACM Multimedia 2001, Ottawa, Canada, pp , October 2001 a) networked games environment. b ) virtual conference environment. c) Web tv environment. Figure 4. Comparison of tree depth evolution for Lam-Gouda and balanced batch rekeying algorithm