Towards scalable and reliable group key management

1. INTRODUCTION In secure group communications, members of a group share a symmetric group key. A key server provides access control to the group key as well as reliable rekeying for group members whenever the key changes. Figure 1 shows the functional components of an architecture for group key management. The registration component authenticates users and distributes to each user its individual key, which is shared only between the user and the key server. Authenticated users send their join and leave requests to the rekey encoding component. The encoding component validates the requests by checking whether they are encrypted by individual keys, and generates rekey messages, which are sent to the rekey transport component for delivery. Previous studies, however, have focused mainly on the encoding component, particularly the processing time required by the encoding component in a key server to process each request individually [1, 2]. The performance of batch rekeying and the problem of reliable transport of group rekey messages have not been addressed in the literature. In this paper, we investigate scalability issues of all three components, including a performance analysis of periodic batch rekeying based on the use of key trees [2], the design of a reliable rekey transport protocol, an analysis of server and client bandwidth requirements for the protocol, and an overall performance analysis of our system, called keygem. 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. redistribute to lists, requires prior specific permission and/or a fee. While individual rekeying introduces no extra delay to process user requests, it has two issues. First, it is hard for individual rekeying to control the synchronization between keys and data. Furthermore, the delay needed to reliably multicast a rekey message may he too large to implement individual rekeying. Second, individual rekey-ing can be inefficient. For authentication purpose, each rekey message needs to be digitally signed to prove that it originates from the key server. Furthermore, when a key server rekeys upon each request and when forward access control is required, we show that f2(log N) is a lower bound on the amortized number of encrypted keys. In keygem, we alleviate the synchronization problem and improve rekey …