A Survey of Key Management for Secure Group Communication

A Survey of Key Management for Secure Group Communication

SANDRO RAFAELI AND DAVID HUTCHISON

Computing Department, Lancaster University

Group 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 Protection

General Terms: Design, Management, Security

Additional Key Words and Phrases: Multicast Security, Group Key Distribution

1. INTRODUCTION

Group 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 access

The 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.00

to 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 and

ACM Computing Surveys, Vol. 35, No. 3, September 2003, pp. 309–329.

310 S. Rafaeli and D. Hutchison

selective 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 sim-ple scheme in large groups is very high.

The literature presents us with severaldifferent approaches to group key man-agement. We can divide them into threemain classes:

—Centralized group key management pro-tocols. A single entity is employed forcontrolling the whole group, hence agroup key management protocol seeksto minimize storage requirements, com-putational power on both client andserver sides, and bandwidth utilization;

—Decentralized architectures. The man-agement of a large group is dividedamong subgroup managers, trying tominimize the problem of concentratingthe work in a single place;

—Distributed key management protocols.There is no explicit KDC, and the mem-bers themselves do the key generation.All members can perform access con-trol and the generation of the key canbe either contributory, meaning that allmembers contribute some informationto generate the group key, or done byone of the members.

This survey will unfold as follows: InSection 2, we give an overview of the com-mon goals of those classes cited above.The main contribution of this paper isdescribed in Section 3. In Section 4, we

ACM Computing Surveys, Vol. 35, No. 3, September 2003.

Survey of Key Management for Secure Group Communication 311

present and analyse the group key man-agement protocols. The decentralised ar-chitectures are described in Section 5. Fi-nally, the distributed key managementschemes are analysed in Section 6.

2. KEY MANAGEMENT ROLE

Key management plays an important roleenforcing access control on the group key(and consequently on the group communi-cation). It supports the establishment andmaintenance of key relationships betweenvalid parties according to a security pol-icy being enforced on the group [McDanielet al. 1999]. It encompasses techniquesand procedures that can carry out:

—Providing member identification andauthentication. Authentication is im-portant in order to prevent an intruderfrom impersonating a legitimate groupmember. In addition, it is importantto prevent attackers from impersonat-ing key managers. Thus, authenticationmechanisms must be used to allow anentity to verify whether another entityis really what it claims to be.

—Access control. After a party has beenidentified, its join operation should bevalidated. Access control is performedin order to validate group membersbefore giving them access to groupcommunication1 (the group key, in par-ticular).

—Generation, distribution and installa-tion of key material. It is necessary tochange the key at regular intervals tosafeguard its secrecy [Schneier 1996].Additional care must be taken whenchoosing a new key to guarantee keyindependence. Each key must be com-pletely independent from any previousused and future keys, otherwise compro-mised keys may reveal other keys.

The key secrecy can be extended tomembership changes. When a group re-quires backward and forward secrecy [Kimet al. 2000], the key must be changed for

1This is because hiding information is not the onlymatter. If anyone can obtain the key, it does not makesense to encrypt the content at all.

every membership change. Backward se-crecy is used to prevent a new memberfrom decoding messages exchanged beforeit joined the group. If a new key is dis-tributed for the group when a new mem-ber joins, it is not able to decipher previousmessages even if it has recorded earliermessages encrypted with the old key. For-ward secrecy is used to prevent a leavingor expelled group member to continue ac-cessing the group’s communication (if itkeeps receiving the messages). If the key ischanged as soon as a member leaves, thatmember will not be able to decipher groupmessages encrypted with the new key.

As multicast is being used for grouptransmission, it is generally assumed thatmulticast should also be used to rekeythe group.2 It is not reasonable to con-sider transmitting data using a scalablemulticast communication and rekeyingthe members under a non-scalable peer-to-peer communication. If the group hasthousands of members, sending them anew key one by one would not be effi-cient. Although rekeying a group beforethe join of a new member is trivial,3 rekey-ing the group after a member leaves it isfar more complicated. The old key cannotbe used to distribute a new one, becausethe leaving member knows the old key. Agroup key distributor must therefore pro-vide other mechanisms to rekey the groupusing multicast messages while maintain-ing the highest level of security possible.

3. CONTRIBUTION OF THIS ARTICLE

This article presents a survey of group keymanagement. We present the group keymanagement solutions proposed so far inthe literature, distributing them into theclasses previously introduced in Section 1.We analyze them comparatively withintheir respective class. This survey effec-tively extends and updates Moyer’s survey[Moyer et al. 1999].

2The term rekey determines the action of distributinga new key in order to replace a previous one.3Send the new key to the group encrypted with theold one.



4. CENTRALIZED GROUP KEYMANAGEMENT PROTOCOLS

In a centralized system, there is only oneentity controlling the whole group. Thecentral controller does not have to relyon any auxiliary entity to perform ac-cess control and key distribution. How-ever, with only one managing entity, thecentral server is a single point of fail-ure. The entire group will be affected ifthere is a problem with the controller. Thegroup privacy is dependent on the success-ful functioning of the single group con-troller; when the controller is not working,the group becomes vulnerable because thekeys, which are the base for the group pri-vacy, are not being generated/regeneratedand distributed. Furthermore, the groupmay become too large to be managed bya single party, thus raising the issue ofscalability.

The group key management protocolused in a centralized system seeks tominimise the requirements of both groupmembers and KDC in order to augmentthe scalability of the group management.The efficiency of the protocol can be mea-sured by:

—Storage requirements. The number ofkey encryption keys (KEKs) that groupmembers and the KDC need to keep;

—Size of messages. Characterized by thenumber of bytes is a rekey messagefor adding and removing members. Theprotocol can combine unicast and mul-ticast messages to achieve the best re-sults. Note that the usage of unicastchannels implies establishing a securechannel, hence increasing the final costof the protocol;

—Backwards and forward secrecy. As de-scribed in Section 2, the capability ofa protocol to provide secrecy despitechanges to the group membership;

—Collusion. Evicted members must not beable to work together and share theirindividual piece of information to regainaccess to the group key.

Throughout this Section, ki representsa shared key. Encryption and decryption

of x with key k are respectively {x}k and{x}−1

k . Additionally, {x}ki ,k j means that xwas encrypted with both ki and k j . Finally,n is the number of members.

4.1. Group Key Management Protocol

The Group Key Management Protocol(GKMP) [Harney and Muckenhirn 1997a,1997b] enables the creation and mainte-nance of a group key. In this approach, theKDC helped by the first member to join thegroup creates a Group Key Packet (GKP)that contains a group traffic encryptionkey (GTEK) and a group key encryptionkey (GKEK). When a new member wantsto join the group, the KDC sends it a copyof the GKP. When a rekey is needed, theGC generates a new GKP and encrypts itwith the current GKEK ({GTEK}GKEK). Asall members know the GKEK, there is nosolution for keeping the forward secrecywhen a member leaves the group exceptto recreate an entirely new group withoutthat member.

4.2. Logical Key Hierarchy

Other contributions (Wong et al. [2000]and Wallner et al. [1999]) propose the useof a Logical Key Hierarchy (LKH). In thisapproach, a KDC maintains a tree of keys.The nodes of the tree hold key encryptionkeys. The leaves of the tree correspondto group members and each leaf holds aKEK associated with that one member.Each member receives and maintains acopy of the KEK associated with its leafand the KEKs corresponding to each nodein the path from its parent leaf to the root.The key held by the root of the tree is thegroup key. For a balanced tree, each mem-ber stores at most (log2 n)+1 keys, where(log2 n) is the height of the tree. For ex-ample, see Figure 1, member u1 knows k1,k12, k14 and k.

A joining member is associated with aleaf and the leaf is included in the tree.All KEKs in the nodes from the new leaf ’sparent in the path to the root are com-promised and should be changed (back-ward secrecy). A rekey message is gen-erated containing each of the new KEKs



Fig. 1 . KEKs affected when a member joinsthe tree.

Fig. 2 . Necessary encryptions whena member joins the tree in the basicLKH.

encrypted with its respective node’s chil-dren KEK. The size of the message pro-duced will be at most 2 · (log2 n) keys long.Figure 1 shows an example of the KEKsbeing affected. The new member u3 re-ceives a secret key k3 and its leaf is at-tached to the node k34. The KEKs held bynodes k34, k14 and k, which are the nodesin the path from k3 to k, are compromised.New KEKs (k′34, k′14 and k′) are generatedas shown in Figure 2. Finally, the KEKsare encrypted with each of its respectivenode’s children KEK ({k′34}k3,k4 ; {k′14}k12,k′34

;and {k}k′14,k58 (see Figure 2). The size of arekeying message for a balanced tree hasat most 2 · (log2 n) keys.

Removing a member follows a similarprocess. When a member leaves (or isevicted from) the group, its parent node’sKEK and all KEKs held by nodes in thepath to the root are compromised andshould be updated (forward secrecy). A

Fig. 3 . Necessary encryptions whena member is removed from the basicLKH.

rekey message is generated containingeach of the new KEKs encrypted with itsrespective node’s children KEK. The ex-ception is the parent node of the leavingmember’s leaf. The KEK held by this nodeis encrypted only with the KEK held bythe remaining member’s leaf. As the keyheld by the leaving member was not usedto encrypt any new KEK, and all its knownKEKs were changed, it is no longer able toaccess the group messages.

Figure 3 presents what happens whena member leaves. Member u4 is leavingthe group and it knows KEKs k34, k14 andk. KEKs k′34, k′14 and k′ are updated andencrypted with each of its respective chil-dren’s KEKs. An exception is made for thek′34. This KEK is encrypted only with k3,which is the key of the remaining memberof n34.

The algorithm proposed by Waldvogelet al. [1999] is different for joining oper-ations. Instead of generating fresh keysand sending them to members already inthe group, all keys affected by the mem-bership change are passed through a one-way function.4 Every member that alreadyknew the old key can calculate the newone. Hence, the new keys do not need tobe sent and every member can calculatethem locally. This algorithm is known asLKH+.

4This scheme has been first proposed by Radia Perl-man during an IETF meeting.



Fig. 4 . Ancestor and sibling sets of memberu4.

4.3. One-way Function Tree

An improvement in the hierarchical bi-nary tree approach is a one-way functiontree (OFT) and was proposed by McGrewand Sherman [1998]. Their scheme re-duces the size of the rekeying messagefrom 2 · (log2 n) to only (log2 n). Here anode’s KEK is generated rather than justattributed. The KEKs held by a node’s chil-dren are blinded using a one-way functionand then mixed together using a mixingfunction. The result of this mixing func-tion is the KEK held by the node. This isrepresented by the following formula:

ki = f (g (kleft(i)), g (kright(i))) (1)

Where left(i) and right(i) denote respec-tively the left and right children of nodei. The function g is one-way, and f is amixing function:

Ancestors of a node are those nodes inthe path from its parent node to the root.In this article, the set of ancestor of a nodeis called ancestor set and the set of siblingsof the nodes in ancestor set are called sib-ling set (see Figure 4). Each member re-ceives the key (associated to its leaf node),its sibling’s blinded key and the blindedkeys corresponding to each node in its sib-ling set.

For a balanced tree, each member storeslog2n+ 1 keys. For example, in Figure 4,member u4 knows key k4 and blinded keyskB

3 (its sibling’s blinded key) and kB12 and

kB58 (blinded keys in u4’s sibling set). Ap-

Fig. 5 . Necessary encryptions when u3joins the tree in the improved LKH.

plying this information to the formula 1,member u4 is able to generate all keys inits ancestor set (k34, k14 and k).

The message size reduction is achievedbecause in the standard scheme, whena node’s key changes, the new key mustbe encrypted with its two children’s keys,and in the OFT scheme, the blinded keychanged in a node has to be encrypted onlywith the key of its sibling node. Figure 5shows an example of this scheme. Mem-ber u3 joins the group at node n34. It re-quires keys k34, k14 and k to be changed.The only values that must be transmit-ted are the blinded KEKs kB

3 , k′B34 and k′B14.Each is respectively encrypted with k4, k12and k58. The new KEKs can be calculatedby every group member: k′34= f (g (k3),g (k4)), k′14= f (g (k12), g (k′34)) and k′ =f (g (k′14), g (k58)).

4.4. One-way Function Chain Tree

Canetti et al. [1999a] proposed a slightlydifferent approach that achieves thesame communication overhead. Theirscheme uses a pseudo-random-generator[Goldreich et al. 1986] to generate the newKEKs rather than a one-way function andit is applied only on users removal. Thisscheme is known as the one-way functionchain tree. The pseudo-random-generator,G(x), doubles the size of its input (x), andthere are two functions, L(x) and R(x),that represent the left and right halves ofthe output of G(x) (i.e., G(x) = L(x)R(x),



Fig. 6 . New key r is attributed to leaf K2.

where |L(x)| = |R(x)| = |x|). When a useru leaves the group, the algorithm to rekeythe tree goes as follows:

(1) a new value rv is associated to everynode v from u to the root of the treeusing rp(u) = r for the first node andrp(v) = R(rv) for all other v (where p(v)denotes the parent of v).

(2) the new keys are generated as k′v =L(rv).

(3) each rp(v) is encrypted with key ks(v)(where s(v) denotes the sibling of v) andsent off.

From rv, one can compute all keys k′v,k′p(v), k′p(p(v)) up to the root node key.

Taking into account the example ofFigure 1, if u1 leaves the group (Figure 6),nodes n12, n14 and n0 will be associate re-spectively with r, R(r) and R(R(r)) andthese values will be encrypted for n2, n34and n58, with their respective KEKs (k2,k34 and k58). Finally, the new KEKs k12, k14and k will be L(r), L(R(r)) and L(R(R(r))).

Rafaeli et al. [2001] presented a varia-tion of this scheme called the efficient hi-erarchical binary tree (EHBT) protocol.

4.5. Hierarchical a-ary Tree with Clustering

Canetti et al. [1999b] proposed the clus-tering of members around single leaves ofa a-ary tree (Li et al. [2001] showed howto compute the cluster size for Canetti’smodel). Dividing the group with n mem-ber into clusters of size m and assigning acluster to a unique leaf node, then we have

n/m clusters. Thus, the depth of the treeis (loga (n/m)) (see Figure 7).

All members in a cluster share the samecluster KEK. Every member of the clusteris also assigned a unique key ki, which isshared only with the KDC. The KDC usesa random seed r as an index for a pseudo-random function fr to generate the key kifor member i (ki = fr (i)). Hence, for eachcluster, only the seed and the cluster KEKare stored. Members of the same clusteralso share the set of keys in the path fromthe leaf node to the root, which meansthat every member in a cluster holds also(loga (n/m))+ 1 KEKs.

When a member leaves, the cluster hold-ing it receives a new cluster KEK. Thenew KEK is encrypted with the individualKEKs of all remaining members. Hence,when a member is removed from a clus-ter, the KDC performs m − 1 encryptionsto update the common cluster KEK to allremaining m−1 members. In addition, theKDC updates all keys in the path from thecluster leaf to the root, and every new KEKis encrypted with its respective node’s chil-dren KEK. That is, when a single mem-ber is deleted, the update message hasm− 1+ a(loga (n/m)) keys.

4.6. Centralized Flat Table

Waldvogel et al. [1999] extended their ownsolution proposing to change the hierar-chical tree for a flat table (FT) with theeffect of decreasing the number of keysheld by the KDC. The table has one entryfor the Traffic Encryption Key (TEK) and2w more entries for KEKs, where w is thenumber of bits in the member id. There aretwo keys available for each bit in the mem-ber id, one associated with each possiblevalue of the bit (Table I shows an exam-ple with w= 4). A member knows only thekey associated with the state of its bit. Intotal, each member holds w + 1 keys. Forexample, a member with id 0101 knowsKEK0.0, KEK1.1, KEK2.0 and KEK3.0 (seeTable I).

When a member leaves the group, allkeys known by it are changed and the KDCsends out a rekey message containing



Fig. 7 . Example of tree with degree 2 and cluster 4.

Table I. Flat ID AssignmentTEK

ID Bit #0 KEK 0.0 KEK 0.1




Bit 0 Bit 1

two parts. The first part has the newTEK encrypted with each unchanged KEK(any member with an id with at leastone single bit of difference from the leav-ing member’s id can recover the TEK). Inthe second part, each of the new KEKsis encrypted with its old KEK and withthe new TEK (see Table II). This way,every remaining member can update itsold KEKs without gaining further knowl-edge about the KEKs other membershad.

A group from IBM proposed a similarscheme [Chang et al. 1999] to the onefrom the ETH group. Although the IBMproposal has the same properties as theflat table, they presented an optimisa-tion for the number of messages neededfor rekeying the group based on Booleanfunction minimisation techniques (BFM)[Wegener 1987]. In this case, rather thanalways sending a message containing thenew TEK encrypted by each unchangedKEK, they apply the techniques and findthe smallest set of KEKs needed to rekeyall remaining members.

This scheme is susceptible to collu-sion attacks. A set of evicted members,which have IDs with complementary bits,may combine their sets of keys to re-cover a valid set of keys, hence are able

to have unauthorised access to groupcommunication.

4.7. Efficient Large-Group Key

Perrig et al. [2001] proposed the EfficientLarge-group Key (ELK) protocol. The ELKprotocol uses a hierarchical tree and isvery similar to the OFT in the sense that aparent node key is generated from its chil-dren keys. ELK uses pseudo-random func-tions (PRFs) to build and manipulate thekeys in the hierarchical tree. A PRF usesa key K on input M of length m to gener-ate output of length n represented by thefollowing notation: PRF m→n

k (M).Using the PRF on a key, it is possible

to derive four different keys to be usedin different contexts: kαi =PRF n→n

ki(1), used

to generate values n1 and n2 (see below),kβi =PRF n→n

ki(2), used to encrypt key update

messages, kγi =PRF n→nki

(3), used to gener-ate hints, and kδi =PRF n→n

ki(4), used to up-

date key nodes.ELK employs a timely rekey, which

means that the key tree is completely up-dated in each time interval. The groupkey is updated using the derivationk′G =PRF n→n

kγG(0) (group key) and all other

k′i are derived by k′i =PRF n→nkγi

(kG). By de-riving all keys, ELK does not require anymulticast messages during a join opera-tion (apart from unicast messages thatare needed when members move aroundthe tree due to insertion of new membernodes).

When members are deleted, new keyshave to be generated for those nodes inthe path from the removed node to the



Table II. Message to Exclude Member 0101TEK

(KEK 0.0new) TEKnew (TEKnew) KEK 0.1 ID Bit #0

(TEKnew) KEK 1.0 (KEK 1.1new) TEKnew ID Bit #1

(KEK 2.0new) TEKnew (TEKnew) KEK 2.1 ID Bit #2

(TEKnew) KEK 3.0 (KEK 3.1new) TEKnew ID Bit #3

Bit 0 Bit 1

Table III. Comparison Table of Group Key Management ProtocolsSecrecy

SecureMessage Storage

Scheme/ Against join

Feature back fore Coll. multicast unicast leave KDC member

Simple Y Y Y nK K nK nK K

GKMP Y N Y 2K 2K — 2K 2K

LKH Y Y Y (2d − 1)K (d + 1)K I + 2d K (2n− 1)K (d + 1)K

OFT Y Y Y (d + 1)K (d + 1)K I + (d + 1)K (2n− 1)K (d + 1)K

OFCT Y Y Y d I (d + 1)K I + (d + 1)K (2n− 1)K (d + 1)K

m− 1+ loga( nm ) m− 1 n

ma

a−1+ loga( nm )+

Clusters Y Y Y a loga( nm ) 2 a loga( n

m ) nm 2

FT Y Y N 2I K (I + 1)K 2I K (2I + 1)K (I + 1)K

ELK Y Y Y 0 (d + 1)K I + d (n1 + n2) (2n− 1)K (d + 1)K

root. This is accomplished by deriving thenew key k′i as k′i = PRF n→n

CLR(ki), with CLR =

PRF n→n1kαil

(ki) | PRF n→n2kαir

(ki), where kil andkir are respectively left and right childkey of node i. The server then multicasts{PRF n→n1

kαil(ki)}kβir and {PRF n→n2

kαir(ki)}kβil .

ELK also introduces the idea of hints. Ahint is a small piece of information, whichis smaller than a key update message, thatcan be used to recover possible lost rekeymessage updates. It is provided to improvethe reliability of the rekey operation andit is conveyed in data messages. Every keyki is generated from n1 bits from the leftside child and n2 bits from the right-sidechild. Moreover, using a key verificationvalue, which is derived from the new keyVK ′ =PRFK ′ (0), the right child can brute-force the left child’s n1 bits (trying all com-binations) and recover K ′i . The right childcan do the same with the right child’s n2bits. Normally, n1<n2; therefore, the rightchild would need more computations torecover the right n2 bits; hence, it alsoneeds the n2−n1 least significant bits of

the right child contribution. In conclusion,a hint conveys the key verification value(VK ′ ) and the n2−n1 least significant bitsof the right child contribution.

4.8. Summary

In this section, we summarize and com-pare the properties of those protocols pre-sented in Section 4 in a quantitative way.We focus our criteria on those charac-teristics presented at the beginning ofSection 4. We have divided the compar-ison into two tables. Table III identifiesthose protocols that provide backward andforward secrecy; also, we show the sizeof messages for join and leave operationsand storage requirements from both KDCand members. Table IV identifies compu-tations required from KDC and membersduring join and leave operations.5

The notation used in Tables III and IVis described in Table III:

5Values written in bold are the best values for a cer-tain column.



Table IV. Comparison Table of Group Key Management Protocols

Scheme/ Join processing Leave processing

Feature KDC member KDC member

Simple nE D nE D

GKMP 2E 2D — —

LKH dH+ 3dE (d + 1)D 2dE dD

OFT (d + 1)H + dX+ 3dE (d + 1)D + d (H + X ) d (H + X + E) D + d (H + X )

OFCT dH+ (d + 1)E (d + 1)D d (PRG+ E) D + dPRG

(m− 1)PRG+Cluster mPRG+ (m+ a loga( n

m ))E (loga( nm )+ 2)D (m+ a loga( n

m )− 1)E (loga( nm )+ 2)D

FT 2IE ID (2I + 1)E (I + 1)D

ELK 2(2n− 1)E + 2E + (d + 1)E (d + 1)D 8dE dD+ 5dE

Notation for Tables III and IV.

n number of member in the groupI number of bits in member ida degree of the treed height of the tree (for a balanced

tree d = loga n)m cluster sizeH hash functionX xor operationE encryption operationD decryption operationK size of a key in bits

PuK size of a public keyPrK size of a private key

Note that for a join operation, n in-cludes the joining members, and for aleaving operation, n excludes the leavingmember.

Tables III and IV show that every proto-col achieves different results when apply-ing different techniques. Some protocolsachieve exceptionally better results thanothers do. However, in order to reach thoseperformances, they demand some strongrequirements and may create unbearablerisks for the group security.

The protocol GKMP achieves excep-tional results for storage, communicationand processing on both KDC and mem-bers. However, those results are achievedby providing no method for rekeying thegroup after a member has left, hence seri-ously compromising the forward secrecy.

ELK needs no multicast message forjoin operations, because it employs a timedrekey, which means that the tree is com-

pletely refreshed at intervals, in spiteof any membership changes. Due to therefreshing time intervals, ELK imposessome delay on the joining member beforeit receives the group key.

ELK has a slightly smaller multicastmessage for leave operations than theother protocols, because it enables the keylength to match the security requirementsof the group.

So far, the best solutions for a group keymanagement protocol appear to be thoseusing a hierarchical tree of KEKs. Theyachieve good overall results without com-promising any aspects of security.

5. DECENTRALIZED ARCHITECTURES

In the decentralized subgroup approach,the large group is split into small sub-groups. Different controllers are used tomanage each subgroup, minimizing theproblem of concentrating the work on asingle place. In this approach, more enti-ties are allowed to fail before the wholegroup is affected.

We use the following attributes toevaluate the efficiency of decentralizedframeworks:

—Key independence. As described in Sec-tion 2, disclosure of a key must not com-promise past keys;

—Decentralized controller. A centralizingmanager should not manage the sub-group managers. The central managerraises the same issues as the central-ized systems seen in Section 4, namely



if the centralizing manager is unavail-able, the whole group is compromised;

—Local rekey. Membership changes ina subgroup should be treated locally,which means that rekey of a subgroupshould not affect the whole group. Thisis also known as the 1-affects-n problem[Mittra 1997];

—Keys vs. data. The data path shouldbe independent of the key manage-ment path, which means that rekey-ing the subgroup should not imposeany interference or delays to the datacommunication;

—Rekey per membership. Related to back-ward and forward secrecy;

—Type of communication. Groups with asingle data source are said to use 1-to-ncommunication, and groups with sev-eral or all members being able to trans-mit are characterized by using n-to-ncommunication.

5.1. Scalable Multicast Key Distribution

RFC1949 [Ballardie 1996] proposes ascheme to use the trees built by the CoreBased Tree (CBT) multicast routing pro-tocol to deliver keys to a multicast group.Any router in the path of a joining mem-ber from its location to the primary corecan authenticate the member since therouter is authenticated with the primarycore. This scheme requires some modifi-cations to the IGMP6 [Fenner 1997] andassumes that CBT is deployed. Further-more, there is no solution for forward se-crecy other than to recreate an entirelynew group without the leaving members.

5.2. Iolus

Mittra proposes Iolus [Mittra 1997], aframework with a hierarchy of agentsthat splits the large group into small sub-groups. A Group Security Agent (GSA)manages each subgroup. The GSAs arealso grouped in a top-level group that ismanaged by a Group Security Controller(see Figure 8).

6The description of the modifications required can befound in the Appendix B of RFC1449.

Fig. 8 . Iolus hierarchy.

Iolus uses independent keys for eachsubgroup and the absence of a generalgroup key means membership changes ina subgroup are treated locally. It meansthat changes that affect a subgroup arenot reflected in other subgroups. In addi-tion, the absence of a central controllercontributes to the fault-tolerance of thesystem. If a subgroup controller (namelyGSA) fails, only its subgroup is affected.

Although Iolus is scalable, it has thedrawback of affecting the data path. Thisoccurs in the sense that there is a needfor translating the data that goes fromone subgroup, and thereby one key, to an-other. This becomes even more problem-atic when it is taken into account that theGSA has to manage the subgroup and per-form the translations needed. The GSAmay thus become a bottleneck.

5.3. Dual-Encryption Protocol

In order to solve the problem of trustingthird parties, Dondeti et al. [1999b] pro-posed a dual-encryption protocol (DEP).In their work, they suggest a hierarchicalsubgrouping of the members where a sub-group manager (SGM) controls each sub-group. There are three kinds of KEKs andone Data Encryption Key (DEK). KEKi1 isshared between a SGMi and its subgroupmembers. KEKi2 is shared between theGroup Controller (GC) and the membersof subgroup i, excluding SGMi. Finally, GCshares KEKi3 with SGMi. In order to dis-tribute the DEK to the members, the GCgenerates and transmits a package con-taining the DEK encrypted with KEKi2and encrypted again with KEKi3 (SGMs’KEK). On receiving the package, SGMi



decrypts its part of the message usingKEKi3 and recovers the DEK encryptedwith its subgroup KEK (KEKi2), which isnot known by the SGMi. SGMi encryptsthis encrypted DEK using KEKi1 sharedwith its subgroup members and sends itout to subgroup i. Each member of sub-group i decrypts the message using KEKi1and then, decrypting the message usingKEKi2 (shared with GC), recovers DEK.The DEK cannot be recovered for any en-tity that does not know both keys. Hence,although there are third parties involvedin the management (SGMs), they do nothave access to the group key (DEK). Whenthe subgroup i’s membership changes, theSGMi changes KEKi1 and sends it to itsmembers. Future DEK changes cannot beaccessed for members of subgroup i thatdid not received the new KEKi1. How-ever, evicted members that did not re-ceive KEKi1 can still access the groupcommunication until the DEK is changed(note that it has not been changed withKEKi1), and this compromises forwardsecrecy.

Weiler [2001] proposed SEMSOMM, asystem with similar properties to thoseof DEP, namely the dual-encryptiontechnique. However, SEMSOMM usesthe dual-encryption technique to encryptthe group communication rather than thegroup key. This achieves forward secrecyfrom the moment that a subgroup keyis changed (KEKi1 from DEP). However,because the intermediate nodes have totranslate messages sent by the sender,SEMSOMM presents the same limitationof Iolus affecting the data path.

5.4. MARKS

In MARKS, Briscoe [1999] suggests slic-ing the time-length to be protected (suchas the transmission time of a TV program)into small portions of time and using a dif-ferent key for encrypting each slice. Theencryption keys are leaves in a binaryhash tree that is generated from a singleseed. The internal nodes of the tree arealso called seeds. A blinding function, suchas MD5 [Rivest 1992], is used on the seed

Fig. 9 . Binary hash tree.

to create the tree in the following way:

(1) first, the depth D of the tree is chosen.The depth, D, defines the total number(N) of keys (N = 2D).

(2) then, the root seed, S0,0, is randomlychosen. In Si, j , i represents the depthof the seed in the tree, and j is thenumber of that key in level i.

(3) after that, two intermediate seeds (leftand right) are generated. The left nodeis generated by shifting S0,0 one bit tothe left and applying the blinding func-tion on it (S1, 0 = b(ls(S0,0))). The rightnode is generated by shifting S0,0 onebit to the right and applying the blind-ing function on it (S1, 1 = b(rs(S0,0))).

(4) the same algorithm is applied to thefollowing levels until the expecteddepth is reached.

Users willing to access the group com-munication receive the seeds need to gen-erate the keys required. For example,Figure 9 shows a binary hash tree ofdepth 3. if a user wants to participate inthe group from time 3 to 7, it would be nec-essary to have only two seeds: S3,3, as K3,and S1,1, to generate K4 till K7.

This system cannot be used in situa-tions when a membership change requireschange of the group key, since the keys arechanged as a function of the time.

5.5. Cipher Sequences

Molva presented a framework for multi-cast security [Molva and Pannetrat 1999]



Fig. 10 . An RPS tree.

that is based on Cipher Sequences (CS).A function f (S, a) is called Cipher Group(CG) if it has the following characteris-tics: there is a sequence of n elements,such as a1≤i≤n; and there is a sequenceof n + 1 elements, such as S0≤i≤n, whereSi = f (Si−1, ai), for i > 0 and S0 is the ini-tial value; and for every couple (i, j ), wherei < j , there exists a function hi, j such asSi = hi, j ( j ). The multicast group is placedin a tree, where the root of the tree is themulticast source, the leaves of the tree aregroup members and the internal nodes ofthe tree are intermediate elements in themulticast communication.

Now let S0 be the information to bemulticast and let every node Ni be as-signed a value ai > 1. Every node Ni canperform function f , so that when Nireceives a value Sj from its parent N j , itcomputes Si = f (Sj , ai) and sends Si to itschildren in the tree (note that the childrencan be other nodes or leaves). The leaveswere assigned the function h0,n, which en-ables them to compute S0 from Sn, sinceS0=h0,n(Sn), and therefore recovers theoriginal data.

Figure 10 shows an example of Molva’sscheme that may be described as:

—the root calculates S1= f (S0, a1) andsends S1 to N1;

—node N1 calculates S2= f (S1, a6) andsends S2 to N2;

—node N2 calculates S3= f (S2, a7) andsends S3 to leaf L3;

—leaf L3 calculates S0=h0,3(S3) and re-covers the original data (S0).

A leaf may be composed of several groupmembers and all members in the sameleaf share the same function h0,n. When

a membership change occurs in a leaf, thenode Nn receives a new value a′n and allmembers in the leaf receive a new functionh′0,n. Naturally, if the membership changeoccurred because of member removal, theremoved member will not receive the newh′0,n, thus will not be able to recover S0.

5.6. Kronos

Setia et al. [2000] proposed Kronos. It is anapproach driven by periodic rekeys ratherthan membership changes, which means anew group key is generated after a certainperiod of time, disregarding whether anymember has joined, left or been ejectedfrom the group. Although Kronos can beused within a distributed framework suchas IGKMP, it works differently becausethe DKD does not directly generate thegroup key. Instead, each AKD indepen-dently generates the same group key andtransmits it to its members at the end ofthe predetermined period.

For this scheme to work, the AKDs firsthave to have their clocks synchronized andthey have to agree on a rekey period. Theauthors suggest using the Network TimeProtocol (NTP) [Mills 1992] for clock syn-chronization. Second, the AKDs also haveto agree on two secret factors, namely Kand R0, where R0 is an initial value andK is a master key. The AKDs can receivethe secret factors from DKD via a securechannel. To generate the group key, withname R1, the AKDs apply an encryptionalgorithm, E, to R0 using K as the se-cret key (R1= EK (R0)). The same algo-rithm applies for the next key generations:Ri+1= EK (Ri), i>= 0. Although Kronosdoes not use a central controller andthe subgroup controllers can generate thenew keys independently, which makes thesystem fault-tolerant, it compromisesthe group security because it generatesthe new key based on the previous one. Ifone key is disclosed, then it compromisesall following keys.

5.7. Intra-Domain Group Key Management

DeCleene et al. [2001] present an intra-region group key management protocol



Fig. 11 . Intra-Domain Group Key ManagementElements.

(IGKMP). IGKMP is divided in admin-istratively scoped areas [Meyer 1998].There is a Domain Key Distributor (DKD)and many Area Key Distributors (AKD).Each AKD is responsible for one area. Thegroup key is generated by the DKD andis propagated to the members through theAKDs. The key managers (DKD and AKD)are placed in a multicast group, namedAll-KD-group (see Figure 11). The All-KD-group is used by the DKD to trans-mit the rekey messages to the AKDs. Allareas in the domain use the same groupkey. Therefore, data packets do not need tobe translated when passing from one areato another. In addition, the DKD does notneed to keep track of all group members,it only has to keep track of the AKDs. Nev-ertheless, since Intra-domain protocol em-ploys a central controller (namely, DKD)for controlling the subgroup controllers(namely, AKDs), it presents the undesir-able feature of allowing the whole group tobe disrupted if the DKD is compromised.Moreover, if an AKD is unavailable nomembers in that area are able to access thegroup communication, since they will notbe able to access AKDs from other areas.

5.8. Hydra

Rafaeli and Hutchison [2002] proposedHydra. In Hydra, the large group is di-vided into smaller subgroups, and a servercalled the Hydra Server (HS) controls eachsubgroup. Hydra is a decentralized groupkey management scheme without a cen-tral subgroup controller. If a membershipchange takes place at HSi, and a newkey must be generated, it can generatethe new group key and send this key

to the other HS j involved in that session.The case when one or more HSs becomeunavailable will not cause a problem forthe remaining HSs. In order to have thegroup key distributed to all HSs a syn-chronized group key distribution protocol(SGKDP) is employed. The SGKDP pro-tocol ensures that only a single valid HSis generating the new group key at everygiven time.

5.9. Summary

In this section, we summarize and com-pare the properties of those architecturespresented at the beginning of Section 5.We focus our criteria on those charac-teriztics presented in Section 5. Table Vshows a summary of the properties thatshould be provided by an architecture forgroup key management. A value writtenin bold is the best value for a certaincolumn.

Kronos does not provide key indepen-dence because it generates new keys basedon old ones, and if any past key is compro-mised, all future keys are disclosed. Thesame happens with MARKS if a seed iscompromised.

Although DEP provides key indepen-dence, it uses a timed rekey, which causesdelays to change the group key after amember has left, thus that member canstill access the group communication dur-ing that period of time. The same occurswith Kronos. In SMKD, the lack of rekeyafter a membership change is even moreserious. SMKD uses the same techniqueas the GKMP (seen in Section 4), namelyusing a unique KEK to encrypt the nextgroup key, which has the undesirable ef-fect of not allowing removal of members.

Limiting the rekey operation to the sub-group where the membership change hasoccurred avoids the need for making allmembers change to a new key. It min-imizes the number of control messages.However, the only solutions proposed sofar employ the use of different keys persubgroup. This solution requires direct in-terference with the data path by meansof translating messages transiting from asubgroup to another due to the different



Table V. Comparison Table of Decentralized Frameworks

Scheme/ key Decent. Local Keys vs. Fault Comm.Feature indep. Mngmt KDC rekey data Rekey tolerant Type

SMKD Y Y Y N Y N N Both

Iolus Y Y Y Y N Y Y 1-to-n

DEP Y N Y N Y N N Both

CS Y N N N Y Y N 1-to-n

MARKS N Y — N Y N Y Both

Kronos N Y Y N Y N Y Both

IGKMP Y Y N N Y Y N Both

Hydra Y Y Y N Y Y Y Both

keys being employed by those subgroups.Both Iolus and SEMSOMM solve the one-affects-all problem, but require the data tobe translated.

Finally, we look at the decentralizedcontroller feature. There are architecturesthat, athough using subgroup controllers,rely on a central subgroup controller toeither control access to the group or gen-erate the group key. The former situationclearly spoils the scalability of the system,because the central controller has to becontacted to verify the membership valid-ity of every member in the group. The lat-ter situation may create a hazard for thegroup security if the central controller isincapable of generating the required keys.

In both CS and DEP architectures, thecentral controller has to be contacted dur-ing join operations in order to authorise it.However, in the DEP case, the subgroupcontrollers do not have to be contactedagain when members leave. Moreover, inCS, DEP, SEMSOMM, SMKD and IGKMPframeworks, if the central controller is un-available the whole group is affected.

6. DISTRIBUTED KEY MANAGEMENT

The distributed key management ap-proach is characterized by having no groupcontroller. The group key can be eithergenerated in a contributory fashion, whereall members contribute their own shareto computation of the group key, or gen-erated by one member. In the latter case,although it is fault-tolerant, it may notbe safe to leave any member to generatenew keys since key generation requires se-

cure mechanisms, such as random numbergenerators, that may not be available toall members. Moreover, in most contribu-tory protocols (apart from tree-based ap-proaches), processing time and communi-cation requirements increase linearly interm of the number of members. Addition-ally, contributory protocols require eachuser to be aware of the group member-ship list to make sure that the protocolsare robust.

We use the following attributes to eval-uate the efficiency of distributed key man-agement protocols:

—Number of rounds. The protocolshould try to minimize the numberof iterations among the members toreduce processing and communicationrequirements;

—Number of messages. The overhead in-troduced by every message exchangedbetween members produces unbearabledelays as the group grows. Therefore,the protocol should require a minimumnumber of messages;

—Processing during setup. Computa-tions needed during setup time. Settingup the group requires most of the com-putation involved in maintaining thegroup, because all members need to becontacted;

—DH key. Identify whether the proto-col uses Diffie–Hellman (DH) [Diffie andHellman 1976] to generate the keys. Theuse of DH to generate the group key im-plies that the group key is generated ina contributory fashion.



6.1. Burmester and Desmedt Protocol

Burmester and Desmedt [1994] proposeda very efficient protocol that executes inonly three rounds:

(1) member mi generates its random ex-ponent ri and broadcasts Zi = αri ;

(2) member mi computes and broadcastsX i = (Zi+1/Zi−1)ri ;

(3) member mi can now compute key k =Z nri

i−1 · X n−ii · X n−2

i+1 · · · X i−2mod p.

The BD protocol requires n + 1 expo-nentiations per member and in all but onethe exponent is at most n − 1. The draw-back is the requirement of 2n broadcastmessages.

6.2. Group Diffie–Hellman Key Exchange

Group Diffie–Hellman key exchange[Steiner et al. 1996] is an extension forthe DH key agreement protocol thatsupports group operations. The DH pro-tocol is used for two parties to agree ona common key. In this protocol, insteadof two entities, the group may have nmembers. The group agrees on a pair ofprimes (q and α) and starts calculatingin a distributive fashion the intermediatevalues. The first member calculates thefirst value (αx1 ) and passes it to the nextmember. Each subsequent member re-ceives the set of intermediary values andraises them using its own secret numbergenerating a new set. A set generated bythe ith member will have i intermediatevalues with i−1 exponents and a cardinalvalue containing all exponents.

For example, the fourth member re-ceives the set:

{αx2x3 , αx1x3 , αx1x2 , αx1x2x3}

and generates the set

{αx2x3x4 , αx1x3x4 , αx1x2x4 , αx1x2x3 , αx1x2x3x4}.

The cardinal value in this example isαx1x2x3x4 . The last member (n) can eas-ily calculate k from the cardinal value(k = αx1···xn mod q). Member n raises

all intermediate values to its secret valueand multicasts the whole set. Each groupmember extracts its respective intermedi-ate value and calculates k. The setup timeis linear (in terms of n) since all mem-bers must contribute to generating thegroup key. Therefore, the size of the mes-sage increases as the sequence is reach-ing the last members and more inter-mediate values are necessary. With that,the number of exponential operations alsoincreases.

6.3. Octopus Protocol

Becker and Wille [1998] proposed the oc-topus protocol. This protocol is also basedon DH key exchange protocol. In Octopus,the large group (composed by n members)is split into four subgroups (n/4 memberseach). Each subgroup agrees internallyon an intermediary DH value (Isubgroup =αu1···un/4 , where ui is the contribution fromuser i) and then the subgroups exchangetheir intermediary values. All group mem-bers can then calculate the group key. Theleader member in each subgroup is re-sponsible for collecting contributions fromall its subgroup members and calculat-ing the intermediary DH value (Isubgroup).Let us call the subgroup leaders A, B,C and D. First, A and B, using DH, ex-change their intermediary values (Ia andIb) creating α Ia .Ib. Also, C and D do thesame and create α Ic .Id . Then, A and C ex-change α Ia .Ib and α Ic .Id . Leaders B and Ddo the same. Now, all of them can calculateα Ia .Ib.Ic .Id . After that, A, B, C and D send totheir respective subgroups α

Ia .Ib.Ic .Idui , where

i = 1 · · · (n− 4)/4, and all members of thegroup are capable of calculating the groupkey.

6.4. Conference Key Agreement

Boyd [1997] proposed yet another proto-col for conference key agreement (CKA)where all group members contribute togenerating the group key. The group keyis generated with a combining function:K = f (N1, h(N2), . . . , h(Nn)), where f isthe combining function (a MAC [Schneier1996]), h is a one-way function, n is the



group size and Ni is the contributionfrom group member i. The protocol spec-ifies that n − 1 members broadcast theircontributions (Ni) in the clear. The groupleader, for example U1, encrypts its con-tribution (N1) with the public key of eachn−1 group member and broadcasts it. Allgroup members who had their public keyused to encrypt N1 can decrypt it and gen-erate the group key.

6.5. Distributed Logical Key Hierarchy

A distributed approach based on the log-ical key hierarchy is suggested by Rodehet al. [2000]. In this approach, the GC iscompletely abolished and the logical keyhierarchy is generated among the mem-bers, therefore there is no entity thatknows all the keys at the same time. Thisprotocol uses the notion of subtrees agree-ing on a mutual key. This means that twogroups of members, namely subtree L andsubtree R, agree on a mutual encryptionkey. Member ml is assumed to be L’s leaderand member mr is R’s leader. Subtree Lhas subtree key kL and subtree R has sub-tree key kR . The protocol used to agree ona mutual key goes as follows:

(1) Member ml chooses a new key kLR , andsends it to member mr using a securechannel.

(2) Member ml encrypts key kLR with keykL and multicasts it to members of sub-tree L; member mr encrypts key kL Rwith key kR and multicasts it to mem-bers of subtree R.

(3) All members (L∪R) receive the newkey.

Figure 12 shows an example of the dis-tributed LKH tree:

(1) Members 1 and 2 agree on subtree keyk12Members 3 and 4 agree on subtree keyk34Members 5 and 6 agree on subtree keyk56Members 7 and 8 agree on subtree keyk78

(2) Members 1, 2 and 3, 4 agree on subtreekey k14

Fig. 12 . LKH tree.

Members 5, 6 and 7, 8 agree on mutualkey k58

(3) Members 1, 2, 3, 4 and 5, 6, 7, 8 agreeon mutual key k18

In this case, the algorithm takes threerounds and each member stores threekeys. This algorithm takes log2 n rounds tocomplete, with each member storing log2 nkeys.

6.6. Distributed One-way Function Tree

Another approach using logical key hierar-chy in a distributed fashion was proposedby Dondeti et al. [1999a]. This protocoluses the one-way function tree proposedby McGrew and Sherman. The differenceis that there is no centralized controllingentity. Moreover, every group member istrusted with access control and key gener-ation. A member is responsible for gener-ating its own key and sending the blindedversion of this key to its sibling. As in thecentralized one-way function tree, everymember knows all keys in the path fromits node to the root node and all blindedkeys from the sibling node to the nodes inthe path to the root.

6.7. Diffie–Hellman Logical Key Hierarchy

Perrig [1999] and Kim et al. [2000] alsoused a logical key hierarchy to minimisethe number of key held by group mem-bers. The difference here is that groupmembers generate the keys in the upperlevels using the Diffie–Hellman algorithmrather than using a one-way function.The key of each node is generated fromits two children (k=αkl kr mod p). Using



Table VI. Comparison Table of Distributed Key Management Protocols

Scheme/ No. messages Setup

Feature Nro. rounds Multicast Unicast DH key Leader Others

BD 3 2n 0 N — (n+ 1)Ex

G-DH n n n− 1 Y — (i + 1)Ex

Octopus 2(n− 4)/4+ 2 0 3n− 4 Y (2(n− 4)/4+ 2)Ex 4Ex

CKA 3 n n− 1 N H + (n− 1)(E + H)+ M D + nH + M

D LKH 3 1 n N log2 nEx log2 nD

D OFT log2 n 0 2 log2 n N — log2 n(H + X )

DH-LKH log2 n log2 n 0 Y — (log2 n+ 1)Ex

DFT n 0 2n− 1 N (i-1)E iD

Figure 12 as an example, keys k12=αk1k2

mod p, k34=αk3k4mod p, k56 = αk5k6mod pand k78=αk7k8mod p. Following the algo-rithm, keys k14 = αk12k34mod p and k58 =αk56k78mod p, and k18 = αk14k58mod p (ork18 = ααα

k1k2 αk3k4 ααk5k6 αk7k8

mod p).

6.8. Distributed Flat Table

Waldvogel et al. [1999] extends furtherits solution, proposing to use the flat ta-ble in a distributed (DFT) fashion with noGroup Controller. In this scheme, no mem-ber knows all the keys at any time. Eachmember knows only the KEKs that it isentitled to. The distributed managementhas an inconvenience, namely that a join-ing member is obliged to contact a group ofmembers to get all the keys needed. Fur-thermore, since many members could bechanging the same key at the same time,there could be serious delays in synchro-nizing the keys.

6.9. Summary

In this section, we summarize and com-pare the properties of those distributedkey management protocols presented inSection 6. We focus our criteria on thosecharacteristics presented at the beginningof Section 6. Table VI shows a summaryof the properties that we analyze on akey management protocol. A Value writ-ten in bold is the best value for a certaincolumn.

The notation used in Table VI is de-scribed in Table VI:

The elements that appear in Table VImean:

Notation for Table VI.n number of members in the groupi index of memberI index sizeH hash function executionX xor operationE encryptionD decryption

Ex exponentiationM MAC

The DH key column has no values inbold, because the use of DH to generatethe group key does not imply any directbenefit. DH key generation is only a tech-nique that can be used for generating thegroup key in a contributory fashion.

Those protocols that do not rely on agroup leader during setup time have anadvantage over those with a group leaderbecause, without a leader, all members aretreated equally and if one or more mem-bers fail to complete the setup, it will notaffect the whole group. In those protocolswith a group leader, a leader failure is fa-tal for creating the group and the opera-tion has to be restarted from scratch.

Both CKA and DH-LKH have a fixednumber of rounds, which means that thenumber of interactions among the mem-bers is independent of the number of mem-bers in the group. The operations in thesetwo protocols can be done in parallel, min-imizing the amount of time needed tocreate the group key. However, they bothrely on a leader to collect contributions



from all other members and then broad-cast them to the others, and as we havediscussed before, if the leader fails, thewhole group is affected and the whole op-eration has to be restarted.

Protocols like D-OFT and DH-LKH donot have a leader during setup timeand all members compute the interme-diary values independently. At the finalround, all members compute the samegroup key. Any member failure can be ig-nored, because it does not block the othermembers.

7. CONCLUSION

In this article, we presented a surveyin the secure group communication area,particularly regarding the secure distri-bution and refreshment of keying ma-terial. We reviewed several proposals,placing them into three main classes:group key management protocols, whichtry to minimise the requirements ofKDC and group members; decentralizedarchitectures, which divide large groupin smaller subgroups in order to makethe management more scalable; and fi-nally, the distributed key managementprotocols, which gives all members thesame responsibilities. Every class has itsparticularities, presenting different fea-tures, requirements and goals.

Our analysis made it clear there is nounique solution that can achieve all re-quirements. While centralized key man-agement schemes are easy to implement,they tend to impose an overhead on a sin-gle entity. Protocols based on hierarchicalsubgrouping are relatively harder to im-plement and raise other issues, such asinterfering with the data path or imposingsecurity hazards on the group. Distributedkey management, by design, is simplynot scalable. Additionally, the best solu-tion for a particular application may notbe best for another, hence it is importantto understand fully the requirements ofthe application before selecting a securitysolution.

A solution for secure group commu-nication should complement a multicastapplication rather than drive its imple-

mentation. Primarily, the usage of secu-rity mechanism for secure group commu-nication should be made transparent tothe user and it should also work well withother protocols.

REFERENCES

BALLARDIE, A. 1996. Scalable Multicast Key Distri-bution. RFC 1949.

BALLARDIE, A. AND CROWCROFT, J. 1995. Multicastspecific security threats and counter-measures.In Proceedings of the Symposium on Networkand Distributed System Security. (San Diego,Calif., Feb.).

BECKER, C. AND WILLE, U. 1998. Communicationcomplexity of group key distribution. In Proceed-ings of the 5th ACM Conference on Computerand Communications Security. (San Francisco,Calif., Nov.). ACM, New York.

BOYD, C. 1997. On key agreement and confer-ence key agreement. In Proceedings of the In-formation Security and Privacy: AustralasianConference. Lecture Notes in Computer Sci-ence, vol. 1270. Springer-Verlag, New York, 294–302.

BRISCOE, B. 1999. MARKS: Multicast key manage-ment using arbitrarily revealed key sequences.In Proceedings of the 1st International Workshopon Networked Group Communication. (Pisa,Italy, Nov.).

BURMESTER, M. AND DESMEDT, Y. 1994. A secure andefficient conference key distribution system (ex-tended abstract). In Advances in Cryptology—EUROCRYPT 94, A. D. Santis, Ed., LectureNotes in Computer Science, vol. 950. Springer-Verlag, New York, pp. 275–286.

CANETTI, R., GARAY, J., ITKIS, G., MICCIANCIO, D., NAOR,M., AND PINKAS, B. 1999a. Multicast Security:A Taxonomy and Some Efficient Constructions.In Proceedings of the IEEE INFOCOM. Vol. 2.(New Yok, N.Y., Mar.). 708–716.

CANETTI, R., MALKIN, T., AND NISSIM, K. 1999b. Effi-cient communication-storage tradeoffs for mul-ticast encryption. In Advances in Cryptology—EUROCRYPT ’99, J. Stem, Ed. Lectures Notesin Computer Science, vol. 1599. Springer-Verlag,New York, pp. 459–474.

CHANG, I., ENGEL, R., KANDLUR, D., PENDARAKIS, D.,AND SAHA, D. 1999. Key management for se-cure internet multicast using boolean functionminimization techniques. In IEEE INFOCOM.Vol. 2. (New York, March 1999), 689–698.

DECLEENE, B., DONDETI, L., GRIFFIN, S., HARDJONO, T.,KIWIOR, D., KUROSE, J., TOWSLEY, D., VASUDEVAN,S., AND ZHANG, C. 2001. Secure group commu-nications for wireless networks. In Proceedingsof the MILCOM. (June).

DEERING, S. 1989. Host Extensions for IP Multicas-ting. RFC 1112.



DIFFIE, W. AND HELLMAN, M. E. 1976. New direc-tions in cryptography. IEEE Trans. Inf. TheoryIT-22, 6 (Nov.), 644–654.

DONDETI, L., MUKHERJEE, S., AND SAMAL, A. 1999a.A distributed group key managementscheme for secure many-to-many commu-nication. Tech. Rep. PINTL-TR-207-99, De-partment of Computer Science, University ofMaryland.

DONDETI, L., MUKHERJEE, S., AND SAMAL, A. 1999b.Scalable secure one-to-many group communi-cation using dual encryption. Comput. Com-mun. 23, 17 (Nov.), 1681–1701.

FENNER, W. 1997. Internet Group ManagementProtocol, Version 2. RFC 2236.

GOLDREICH, O., GOLDWASSER, S., AND MICALI, S. 1986.How to construct random functions. J. ACM 33, 4(Oct.), 792–807.

HARDJONO, T. AND TSUDIK, G. 2000. IP multicast se-curity: Issues and directions. Ann. Telecom. 324–340.

HARNEY, H. AND MUCKENHIRN, C. 1997a. GroupKey Management Protocol (GKMP) Specifica-tion. RFC 2093.

HARNEY, H. AND MUCKENHIRN, C. 1997b. GroupKey Management Protocol (GKMP) Architecture.RFC 2094.

KIM, Y., PERRIG, A., AND TSUDIK, G. 2000. Sim-ple and fault-tolerant key agreement for dy-namic collaborative groups. In Proceedings ofthe 7th ACM Conference in Computer andCommunication Security, (Athens, Greece Nov.).(S. Jajodia and P. Samarati, Eds.), pp. 235–241.

LI, M., POOVENDRAN, R., AND BERENSTEIN, C. 2001.Optimization of key storage for secure. In Pro-ceedings of the 35th Annual Conference on In-formation Sciences and Systems (CISS). (JohnHopkins, Mar.).

MCDANIEL, P., PRAKASH, A., AND HONEYMAN, P. 1999.Antigone: A flexible framework for securegroup communication. In Proceedings of the8th USENIX Security Symposium. (Washington,D.C. Aug.). 99–114.

MCGREW, D. A. AND SHERMAN, A. T. 1998. Key es-tablishment in large dynamic groups using one-way function trees. Tech. Rep. No. 0755 (May),TIS Labs at Network Associates, Inc., Glenwood,Md.

MEYER, D. 1998. Administratively Scoped IPMulticast. RFC 2365.

MILLS, D. L. 1992. Network Time Protocol (Version3) Specification, Implementation and Analysis.RFC 1305.

MITTRA, S. 1997. Iolus: A framework for scalablesecure multicasting. In Proceedings of the ACMSIGCOMM. Vol. 27, 4 (New York, Sept.) ACM,New York, pp. 277–288.

MOLVA, R. AND PANNETRAT, A. 1999. Scalable mul-ticast security in dynamic groups. In Proceed-ings of the 6th ACM Conference on Computer and

Communications Security. (Singapore, Nov.).ACM, New York, 101–112.

MOYER, M. J., RAO, J. R., AND ROHATGI, P. 1999. Asurvey of security issues in multcast communi-cations. IEEE Netw. Mag. 13, 6 (Nov./Dec.), 12–23.

PERRIG, A. 1999. Efficient collaborative key man-agement protocols for secure autonomous groupcommunication. In Proceedings of the Interna-tional Workshop on Cryptographic Techniquesand E-Commerce (CrypTEC’99). (Hong Kong,China, July). M. Blum and C H Lee, Eds. CityUniversity of Hong Kong Press, Hong Kong,China, pp. 192–202.

PERRIG, A., SONG, D., AND TYGAR, J. D. 2001. ELK, Anew protocol for efficient large-group key distri-bution. In Proceedings of the IEEE Symposiumon Security and Privacy. (Oakland, Calif., May).IEEE Computer Society Press, Los Alamitos,Calif.

RAFAELI, S. AND HUTCHISON, D. 2002. Hydra: A de-centralised group key management. In Proceed-ings of the 11th IEEE International WETICE:Enterprise Security Workshop, A. Jacobs, Ed.(Pittsburgh, Pa., June). IEEE Computer SocietyPress, Los Alamitos, Calif.

RAFAELI, S., MATHY, L., AND HUTCHISON, D. 2001.EHBT: An efficient protocol for group key man-agement. In Proceedings of the 3rd Interna-tional Workshop on Networked Group Commu-nications. (London, U.K., Nov.). Lecture Notesin Computer Science, vol. 2233. Springer-Verlag,New York, pp. 159–171. Springer-Verlag.

RIVEST, R. 1992. The MD5 Message-Digest Algorithm.RFC 1321.

RODEH, O., BIRMAN, K., AND DOLEV, D. 2000. Opti-mized group rekey for group communication sys-tems. In Network and Distributed System Secu-rity. (San Diego, Calif., Feb.).

SCHNEIER, B. 1996. Applied Cryptography SecondEdition: protocols, algorithms, and source codein C. Wiley, New York. ISBN 0-471-11709-9.

SETIA, S., KOUSSIH, S., AND JAJODIA, S. 2000. Kronos:A scalable group re-keying approach for se-cure multicast. In Proceedings of the IEEESymposium on Security and Privacy. (OaklandCalif., May). IEEE Computer Society Press, LosAlamitos, Calif.

STEINER, M., TSUDIK, G., AND WAIDNER, M. 1996.Diffie-Hellman key distribution extended togroup communication. In SIGSAC Proceedingsof the 3rd ACM Conference on Computer andCommunications Security. (New Delhi, India,Mar.). ACM, New York, pp. 31–37.

WALDVOGEL, M., CARONNI, G., SUN, D., WEILER, N.,AND PLATTNER, B. 1999. The VersaKey frame-work: Versatile group key management. IEEEJ. Sel. Areas Commun. (Special Issue on Middle-ware) 17, 9 (Aug.), 1614–1631.

WALLNER, D., HARDER, E., AND AGEE, R. 1999. KeyManagement for Multicast: Issues and Architec-tures. RFC 2627.



WEGENER, I. 1987. The Complexity of BooleanFunctions. Wiley, New York. ISBN: 0-471-91555-6.

WEILER, N. 2001. SEMSOMM—A scalable multi-ple encryption scheme for one-to-many multi-cast. In Proceedings of the 10th IEEE Interna-

tional WETICE Enterprises Security Workshop,(Cambridge, Mass., June). IEEE Computer So-ciety Press, Los Alamitos, Calif.

WONG, C. K., GOUDA, M. G., AND LAM, S. S. 2000.Secure group communications using key graphs.IEEE/ACM Trans. Netw. 8, 1 (Feb.), 16–30.

Received July 2001; accepted June 2003


Documents

A Survey of Key Management for Secure Group Communication