A Survey of Key Management for Secure Group CommunicationSANDRO RAFAELI AND DAVID HUTCHISONComputing Department, Lancaster UniversityGroup communication can benefit from IP multicast to achieve scalable exchange ofmessages. However, there is a challenge of effectively controlling access to thetransmitted data. IP multicast by itself does not provide any mechanisms for preventingnongroup members to have access to the group communication. Although encryptioncan be used to protect messages exchanged among group members, distributing thecryptographic keys becomes an issue. Researchers have proposed several differentapproaches to group key management. These approaches can be divided into three mainclasses: centralized group key management protocols, decentralized architectures anddistributed key management protocols. The three classes are described here and aninsight given to their features and goals. The area of group key management is thensurveyed and proposed solutions are classified according to those characteristics.Categories and Subject Descriptors: C.2.2 [Computer Systems Organization]:Network Protocols; K.6.5 [Computing Milieux]: Security and ProtectionGeneral Terms: Design, Management, SecurityAdditional Key Words and Phrases: Multicast Security, Group Key Distribution1. INTRODUCTIONGroup communication applications canuse IP multicast [Deering 1989] to trans-mit data to all n group members usingminimum resources. Efficiency is achievedbecause data packets need to be transmit-ted once and they traverse any link be-tween two nodes only once, hence savingbandwidth. This contrasts with unicast-based group communication where thesender has to transmit n copies of the samepacket.However scalable, IP multicast does notprovide mechanisms to limit the accessThe work presented here was done within the context of ShopAware—a research project funded by theEuropean Union in the Framework V IST Programme.Authors’ address: D. Hutchison, Computing Department, Faculty of Applied Sciences, Engineering Building,Lancaster University, Lancaster LA1 4YR, United Kingdom; S. Rafaeli, Rua Atanasio Belmonte, 175/828,Porto Alegre, Brazil, CEP 90520-550; email: [email protected] to make digital or hard copies of part or all of this work for personal or classroom use is grantedwithout fee provided that copies are not made or distributed for profit or direct commercial advantage andthat copies show this notice on the first page or initial screen of a display along with the full citation.Copyrights for components of this work owned by others than ACM must be honored. Abstracting withcredit is permitted. To copy otherwise, to republish, to post on servers, to redistribute to lists, or to use anycomponent of this work in other works requires prior specific permission and/or a fee. Permissions may berequested from Publications Dept., ACM, Inc., 1515 Broadway, New York, NY 10036 USA, fax: +1 (212)869-0481, or [email protected]°2003 ACM 0360-0300/03/0900-0309 $5.00to the data being transmitted to autho-rised group members only [Ballardie andCrowcroft 1995]. Any multicast-enabledhost can send IGMP [Fenner 1997] mes-sages to its neighbour router and requestto join a multicast group. There is noauthentication or access control enforcedin this operation [Hardjono and Tsudik2000]. The security challenge for multicastis in providing an effective method for con-trolling access to the group and its infor-mation that is as efficient as the underly-ing multicast.A primary method of limiting accessto information is through encryption andACM Computing Surveys, Vol. 35, No. 3, September 2003, pp. 309–329.310 S. Rafaeli and D. Hutchisonselective distribution of the keys used toencrypt group information. An encryptionalgorithm takes input data (e.g., a groupmessage) and performs some transforma-tions on it using a cryptographic key. Thisprocess generates a ciphered text. Thereis no easy way to recover the original mes-sage from the ciphered text other thanby knowing the right key [Schneier 1996].Applying such a technique, one can run se-cure multicast sessions. The messages areprotected by encryption using the chosenkey, which in the context of group commu-nication is called the group key. Only thosewho know the group key are able to recoverthe original message.Furthermore, the group may requirethat membership changes cause the groupkey to be refreshed. Changing the groupkey prevents a new member from decod-ing messages exchanged before it joinedthe group. If a new key is distributed to thegroup when a new member joins, the newmember cannot decipher previous mes-sages even if it has recorded earlier mes-sages encrypted with the old key. Addi-tionally, changing the group key preventsa leaving or expelled group member fromaccessing the group communication (if itkeeps receiving the messages). If the keyis changed as soon as a member leaves,that member will not be able to deciphergroup messages encrypted with the newkey.However, distributing the group key tovalid members is a complex problem. Al-though rekeying a group before the joinof a new member is trivial (send the newgroup key to the old group members en-crypted with the old group key), rekey-ing the group after a member leaves is farmore complicated. The old key cannot beused to distribute a new one, because theleaving member knows the old key. There-fore, a group key distributor must provideanother scalable mechanism to rekey thegroup.A simple scheme for rekeying a groupwith n members has the key distributioncentre (KDC) assigning a secret key toeach member of the group. In order to dis-tribute the group key, the KDC encrypts itwith each member’s secret key. This opera-tion generates a message O(n) long whichis then transmitted to the whole groupvia multicast. On receiving the message,a member can recover the group key fromthe appropriate segment of the messageusing its own secret key.In fact, this is not so simple or scalable.Generating one copy of the group key foreach member means that the KDC has toencrypt the group key n times. The size ofthe broadcast message has to be consid-ered as well. For example, a message in-cluding all n copies of the encrypted groupkey, assuming n equal to one million andusing a cryptographic algorithm with akey 56 bits long, the message would havesize 10253 KB. A session where the mem-bership changes very frequently becomesdifficult to administrate. Even though theprocess is simple, the cost of using the
View Full Document