Secure multicast in dynamic environments

Computer Networks 51 (2007) 2805–2817

www.elsevier.com/locate/comnet

Secure multicast in dynamic environments

Chun-Ying Huang *, Yun-Peng Chiu, Kuan-Ta Chen, Chin-Laung Lei

Department of Electrical Engineering, National Taiwan University, Room 604, EE-3 Building, No. 1, Section 4,

Roosevelt Road, Taipei 106, Taiwan, ROC

Received 1 June 2006; received in revised form 29 November 2006; accepted 30 November 2006Available online 19 December 2006

Responsible Editor: P. Dowd

Abstract

A secure multicast framework should only allow authorized members of a group to decrypt received messages; usually,one ‘‘group key’’ is shared by all approved members. However, this raises the problem of ‘‘one affects all’’, whereby theactions of one member affect the whole group. Many researchers have solved the problem by dividing a group into severalsubgroups, but most current solutions require key distribution centers to coordinate secure data communications betweensubgroups. We believe this is a constraint on network scalability. In this paper, we propose a novel framework to solve keymanagement problems in multicast networks. Our contribution is threefold: (1) We exploit the ElGamal cryptosystem andpropose a technique of key composition. (2) Using key composition with proxy cryptography, the key distribution centersused in secure multicast frameworks are eliminated. (3) For key composition, the framework is designed to resist node fail-ures and support topology reconstruction, which makes it suitable for dynamic network environments. Without reducingthe security or performance of proxy cryptography, we successfully eliminate the need for key distribution centers. Ouranalysis shows that the proposed framework is secure, and comparison with other similar frameworks demonstrates thatit is efficient in terms of time and space complexity. In addition, the costs of most protocol operations are bounded byconstants, regardless of a group’s size and the number of branches of transit nodes.� 2006 Elsevier B.V. All rights reserved.

Keywords: ElGamal cryptosystem; Key composition; Key management; Proxy cryptography; Secure multicast

1. Introduction

The original design of multicast [1] did not incor-porate mechanisms that guaranteed the integrityand confidentiality of messages. Since multicast

1389-1286/$ - see front matter � 2006 Elsevier B.V. All rights reserved

doi:10.1016/j.comnet.2006.11.027

* Corresponding author. Tel.: +886 2 33663544.E-mail addresses: [email protected] (C.-Y.

Huang), [email protected] (Y.-P. Chiu), [email protected] (K.-T. Chen), [email protected] (C.-L. Lei).

routers simply deliver messages via a tree-like struc-ture according to group addresses, when an arbi-trary user registers with a multicast group, he canreceive all the messages from the distributor. Thisraises a serious security problem. Therefore, a greatdeal of research has focused on security mechanismsfor multicast and group communications. The goalof these mechanisms is simple: A secure multicast

mechanism should be able to control member access

rights and guarantee the confidentiality of data. Only

.

mailto:[email protected]





2806 C.-Y. Huang et al. / Computer Networks 51 (2007) 2805–2817

authorized members with a proper key should be able

to decrypt ciphertexts received from the group. Thus,the secure multicast problem can be reduced to twoquestions: (1) How can cryptographic keys be gener-ated and distributed? (2) Who should have access tothese cryptographic keys to read confidentialmessages?

In general, secure multicast mechanisms, can beclassified as centralized, decentralized, or distrib-uted mechanisms [2]. Centralized mechanisms, suchas [3,4], employ a single entity to control the wholegroup and seek to minimize storage costs, computa-tional power, and bandwidth requirements. How-ever, since there is only a single entity, thepossibility of a single point of failure increases. Incontrast, methods like [5–8] divide a group intoseveral subgroups; hence, better scalability and reli-ability can be achieved because failures are confinedto subgroups. Even so, these methods still require acentralized controller to coordinate secure datacommunications between different subgroups. Dis-tributed approaches, like [9,10], eliminate central-ized controllers so that all group members cancontribute to the required cryptographic key, or itcan be generated by one member. The result is agroup key shared by all members; therefore, eachuser must be aware of the group membership list.In addition, computation and communicationrequirements may grow linearly as the number ofgroup members increases.

Each approach has benefits and drawbacks.However, to construct a large-scale secure multicastnetwork, especially one that requires the collabora-tion of nodes in different administrative domains,we believe a hybrid framework that uses a decentral-ized model working in a distributed manner is agood design choice.

In this paper, we propose a new secure multicastframework that builds on the advantages of decen-tralized and distributed approaches. The frameworkis constructed in two steps. First, we exploit themathematics used in ElGamal cryptography [11]and proxy cryptography [12,13] and extend the cal-culations to develop a distributed protocol for keycomposition. Then, using the protocol, we eliminatethe key distribution centers used in proxy cryptogra-phy-based secure multicast networks like [7].

The framework adopts a network model similarto those in [7,8], which are source-based multicasttree networks. We use proxy cryptography to deli-ver key encryption keys (KEKs). In proxy cryptog-raphy, given a sender A, receiver B, and proxy P, a

message encrypted by A’s encryption key, kA, andtransformed by P’s encryption key, kP, can bedecrypted by B’s decryption key, kB. Proxy cryptog-

raphy has several benefits, including low key storagerequirements, message invisibility on intermediate

proxies, and low computational complexity regardless

the number of proxy branches. Since a proxy trans-forms an encrypted message without understandingthe original message, it is suitable for large-scalenetworks, especially when most intermediate nodescan not be totally trusted.

The remainder of this paper is organized as fol-lows. In Section 2, we review several related worksthat propose solutions for the secure multicast prob-lem. In Section 3, we introduce the basic compo-nents used in our framework, and then constructthe framework in Section 4. In Section 5, we evalu-ate and discuss the proposed approach, and com-pare its performance with other methods. InSection 6, we present our conclusions.

2. Related works

Several solutions to the problem of secure groupcommunications have been proposed. In centralizedapproaches, such as [3,4], the authors propose a log-ical key hierarchy (LKH), whereby a key distribu-tion center (KDC) maintains a tree of keys.Except for the root node (the KDC) and the leafnodes (the group members), all intermediate nodesare logical nodes. Initially, each node is assigned akey encryption key (KEK). The KDC knows theKEKs of all nodes and a group member knowsthe KEKs of nodes on the path from the KDC toitself. Thus, in a balanced key tree with m members,each member has to keep O(log(m)) keys. When agroup secret key is being delivered to a member,the key is encrypted using the KDC’s KEK and isthen sent to all group members by a multicast. Ifa member joins or leaves a balanced key tree con-taining m members, O(log(m)) keys and O(log(m))encryptions are required to update the correspond-ing KEKs in the key tree. Since there is a centralizedkey distribution center, the single point of failureand scalability problems cannot be avoided.

In distributed approaches, members in one groupcooperate to generate a shared secret key. In groupDiffie–Hellman (GDH) [9], the authors extend theDiffie–Hellman [14] key agreement protocol to n

parties. Given a cyclic group G of order q with agenerator g, each participant i chooses a randomvalue Ni 2 G. The GDH protocol starts with the

C.-Y. Huang et al. / Computer Networks 51 (2007) 2805–2817 2807

first member passing a secret number gN1 to the sec-ond member. On receipt of the set of secret numbersfrom the (j � 1)th member, the jth member increasesthe numbers in the set by adding his secret numbergNj and generates a new set for the next member.After O(n) rounds of computation, the final groupkey k of gN1��Nn can be generated and delivered toall participants. Since members in a distributedsecure group communication environment arerequired to know the group membership list, suchframeworks may be not suitable for large groups.In addition, they suffer from the ‘‘one affects all’’problem.

To overcome the problems encountered in cen-tralized and distributed models, several decentral-ized frameworks for secure multicast have beenproposed. In IOLUS [5], members of a multicastgroup are divided into several subgroups. The con-nectivity between the subgroups is controlled bygroup security agents (GSAs) placed on the linksbetween the subgroups. Each subgroup is relativelyindependent; therefore, membership changes can beconfined to the subgroup in which they occur. Theproblem with IOLUS is that while an encryptedmessage is being transmitted from subgroup A tosubgroup B, the GSA decrypts the message withA’s secret key and then encrypts it with B’s secretkey. Although this achieves the goal of confidential-ity, the GSAs must be totally trusted and well pro-tected to prevent the leakage of confidentialmessage.

To solve the problem of trusting third parties,another framework, the dual-encryption protocol(DEP) [6], has been proposed. In DEP, a multicastgroup is also partitioned into several subgroups,each of which has a corresponding subgroup man-ager (SGM). Confidentiality is guaranteed by a dataencryption key (DEK) maintained by a group con-troller (GC). Three key encryption keys (KEKs)are used to deliver a DEK: KEK1 is shared by theGC and the SGM; KEK2 is shared by the SGMand members of its subgroup; and KEK3 is sharedby the GC and members of a subgroup, except theSGM. Let the encryption and decryption functionswith secret key k be denoted by Enck(Æ) and Deck(Æ),respectively. The GC delivers the DEK to a sub-group’s members via the following steps. First, theGC sends EncKEK1

ðEncKEK3ðDEKÞÞ to the SGM.

The received message is decrypted with KEK1 andre-encrypted with KEK2. The new encrypted keyEncKEK2

ðEncKEK3ðDEKÞÞ is then sent to the sub-

group’s members. Since only those members know

both KEK2 and KEK3, they can obtain the correctDEK. When a member joins or leaves a subgroup,KEK2 is changed by the SGM and sent to all validmembers. The problem with DEP is that the for-ward and backward secrecy depends on how oftenthe DEK is updated. Therefore, if the DEK is chan-ged infrequently, newcomers or ex-members candecrypt past/current messages easily.

Cipher-sequence (CS) [8] is another decentralizedsecure multicast framework that is built over a mul-ticast tree. Every non-leaf node in the tree isassigned a cryptography function. When a messageis sent out from a non-leaf node, it is encrypted bythe assigned cryptographic function of that node.Thus, a message sent from the root of the tree toa member is encrypted by all nodes on the path.The encryptions performed by intermediate nodesform a cipher-sequence. Each leaf node containsmembers of a subgroup, all of whom share the samereverse function to the cipher-sequence. Since differ-ent paths generate different cipher-sequences, thereverse function for each subgroup is different.When a member joins or leaves a subgroup, the lastinner node on the path closest to the subgroup’smembers changes its encryption function; thus, anew cipher-sequence and a corresponding reversefunction are generated for that subgroup. Althoughthis framework is secure and scalable for messagedelivery, it still requires a centralized key distribu-tion center to understand the topology, assignencryption functions to non-leaf nodes, and com-pute reverse functions for subgroup members.

It is widely recognized that [7] was the first paperto discuss the possibility of applying proxy cryptog-raphy to secure multicast communications. Theapproach uses a similar network model to that ofcipher-sequence; however, instead of assigning cryp-tographic functions to nodes, it assigns crypto-graphic keys. A key control component associatedwith the group controller generates encryption anddecryption keys for the sender, receiver, and allintermediate transformation nodes (proxies). Whena node joins the multicast tree, the group controllersplits the decryption key of the new-comer’s parentnode into an encryption key and a decryption key.The new encryption key is kept by the parent nodefor further message transformation. Meanwhile, thenew decryption key is sent to the new-comer todecrypt confidential messages. This approach, how-ever, still requires a controller to handle key distri-bution, so it has similar drawbacks and limitationsto the cipher-sequence approach.


Our work differs from previous studies in threeways: (1) We do not require a centralized key con-trol component to distribute keys. Encryption keysare generated by the transformation nodes them-selves. (2) The decryption keys for message receiversare obtained by running the proposed key composi-tion protocol, which should be done in roughly asingle round trip time. (3) Since the key distributionprocess is totally decentralized and distributed, theproposed protocol can be used to construct a gen-eric security service for multicast networks thatcan be shared by different communication groups.

3. Proxy cryptography and key composition

Proxy cryptography [12] comprises encryptionand digital signature schemes. In secure multicast,we only leverage the encryption part of the tech-nique. Proxy encryption allows a semi-trusted proxyto transform a ciphertext from Alice into a cipher-text for Bob without seeing the underlying plain-text. The proxy encryption scheme can be imple-mented using the ElGamal cryptosystem in whichtwo public parameters, p and g, are shared by allusers, where p is a prime of the form 2q + 1 and g

is a generator in Z�p. The sender, A, randomly selectsa secret key x in Zq and releases its public key as gx

modp. The message m is then encrypted with a ran-domly selected secret parameter k 2 Zq and sent inthe form of two cipher values (c1,c2), wherec1 = gk (mod p) and c2 = m((gx)k) (mod p). Decryp-tion just reverses the process. Therefore, it is easyfor a node that knows �x to recover the originalplain-text by computing m ¼ c2=cx

1 (mod p).To implement proxy encryption using the above

example, we assume that the message receiver Bhas a secret key y, and an intermediate proxy P

between A and B has a transformation key

A P1 P2 P3

k0 k1 k2 k3

k0 k1-k0 k2-k1 k3-k2

Key Distributio

gr,mgrk0

gr,mgrk1

gr,mgrk2

DeliveryProcess

Fig. 1. An example of chaining proxies. The key distribution center greceiver. On receipt of the transformed message, the receiver can decry

(y � x). Then, the intermediate proxy P transformsthe cipher values (c1,c2) from A by computingc02 ¼ c2 � cðy�xÞ

1 and sends ðc1; c02Þ as the new cipher-text to B. Thus, B can extract the original messagem from the transformed ciphertext with its ownsecret key y. To improve flexibility, the single proxymechanism can be extended to a multiple proxiesmechanism, as shown in Fig. 1. Assume there is asender A, a receiver B, and n intermediate proxiesPi (i = {1,2, . . . ,n}) on the path between A and B.To deliver a message from A to B, the message pathwill be A–P1–P2– � � � –Pn—B. The key distributioncenter first assigns secret keys k0 and kn to A andB, respectively. Then, it randomly generatesk1,k2, . . . ,kn�1 and computes proxy keys kP i aski � ki�1 for each proxy on the path. Note that only

the kP i (i = {1,2, . . . ,n � 1}) keys are sent to the

proxies. The ki keys are only used to compute the final

proxy keys, so they are not sent to the proxies.

The concept of chaining proxies can be used toconstruct a secure multicast framework easily. In amulticast network like that in Fig. 2, the key distri-bution center (KDC) first assigns secret keys ks andkR1

–kR4to node S and R1–R4, respectively. Then, it

computes proxy keys according to the networktopology. For example, the proxy nodes P1, P3,and P4 are assigned proxy keys k1 � ks, kR1

� k1,and kR2

� k1, respectively. When a member joinsor leaves, the proxy closest to the event has to notifythe KDC to perform a re-keying operation byupdating the secret keys of the proxy and all themembers directly connected to it.

Since the above framework requires a centralizedkey distribution center, it has several drawbacks.First, its scalability is restricted by the single key ser-ver or cluster, which could be overloaded by a largenumber of member join/leave requests. Second, it iscommon for a centralized service to encounter the

Pn B

kn

Pn-1

kn-1

knkn-1-kn-2 kn-kn-1

n Center

gr,mgrkn-2

gr,mgrkn-1

gr,mgrkn

enerates cryptographic keys for the sender, the proxies, and thept the ciphertext with its own secret key.

S

P1 P2

P3 P4 P5 P6

R1 R2 R3 R4

S

P1

P4

R2

KS

KR2

KP1

KS

KP1-KS

KR2

KR2-KP1

Key D

ist. Center

Fig. 2. An example of applying chaining proxies on a source-based multicast tree. Node S is the sender, nodes P1–P6 aremulticast routers, and nodes R1–R4 are groups of receivers.

S

P1

P3

R1

S

P2

P6

R4

P2

P5

R3

SS

P1

P4

R2

Path I Path II Path III Path IV

Subgroup I Subgroup II Subgroup III Subgroup IV

Fig. 3. The paths extracted from the network in Fig. 2. Eachsubgroup has a different composed key because the nodes on eachmessage path are different.


single point of failure problem. Third, since thesecret keys for nodes are assigned by the key distri-bution center, the latter must be well protected andtotally trusted. Furthermore, if there is a networkdynamics issue, such as a proxy shutdown or acrash, it is hard for a single point to monitor andhandle the whole network topology.

To eliminate the key distribution center, we pro-pose a novel technique of key composition for proxyencryption. The basic idea is simple: all stable nodes,including the sender and the proxies, decide their own

secret keys. When a receiver joins the group, it

obtains the decryption key by using the proposed

key composition protocol. Suppose there is a senderA, a receiver B, and the proxies P1–Pn sit on thepath between A and B. The sender A chooses asecret key k0 and each proxy Pi (i = {1,2, . . . ,n})chooses a secret key ki. When the ciphertextfc1; c2g ¼ fgr;m � grk0g of a message m sent from A

finally reaches B, the encrypted and transformedmessage will be in the form of

fc1; c2g ¼ fgr;m � grðk0þk1þk2þ��þknÞg;where r is the random ephemeral key. The reasonfor this form is that when an arbitrary proxy Pi

receives the ciphertext {c1,c2} from the previousnode, it always computes the new fc01; c02g byc01 ¼ c1, c02 ¼ c2 � cki

1 and then forwards the resultfc01; c02g to the next node. Thus, to decrypt the mes-sage, the receiver must know the decryption keywith a value kc of (k0 + k1 + k2 + � � � + kn). We alsocall kc the composed key for receiver B, since allnodes on the path from the sender to the receivercontribute to the secret key. In Fig. 3, four differentmessage paths are extracted from the networkshown in Fig. 2. As the value of a composed keyis contributed by all nodes on the message path,the composed key for each message path is different.Members that share the same message path have thesame composed key; hence, they form a subgroup.Since the composed key varies according to the mes-sage path, we also call it a path key. In the example

in Fig. 3, suppose that node S has a secret key k0

and node Pi has a secret key ki; then, the composedkeys for R1, R2, R3, and R4 are (k0 + k1 + k3),(k0 + k1 + k4), (k0 + k2 + k5), and (k0 + k2 + k6),respectively. With these observations, our problemis reduced to ‘‘How can we securely generate and up-

date the composed key for the group members in an

efficient and distributed manner?’’

4. The framework

In this section, we explain the construction of ourframework. First, we describe the roles and theassumptions used in this paper. Second, we definethe operations and notations used in our frame-work. Then, the framework is constructed withessential group operations, namely, members join-ing and leaving, re-keying, and message delivery.Finally, we propose algorithms for handling net-work dynamics, such as topology changes and nodefailures.

There are three kinds of role in our framework:the sender, the proxy, and the receiver. The senderdelivers messages to the receiver, while the proxiesare responsible for transforming a received cipher-text into a new ciphertext that can be decrypted witha different secret key. We make the followingassumptions.

• We assume that both the sender and the receivers

are trustworthy. The definition of a receiver is anode that is authenticated by the sender andallowed to join the multicast network. Since areceiver can always access plain-text messages,we trust the receivers in our framework. Theissue of leakage of confidential messages byreceivers is not within the scope of this paper.

• We assume that the proxies are only partially

trusted. That is, we trust a proxy to transform areceived ciphertext and forward it to the next


node correctly. Since we use proxy encryption,the proxies cannot decipher the original plain-text message concealed in the received ciphertext.Thus, there is no concern about leakage of confi-dential messages by proxies. Note that a proxycan also be a receiver. In this special case like areceiver, the proxy is totally trusted.

• We assume that a proxy knows about other prox-

ies within a distance of at least two hops. This is arequirement of dynamic networks. When thestate of a proxy changes from on-line to off-lineor vice versa, it should announce its new stateto all its neighbors within at least two hops.

• We assume that a secure channel can be estab-

lished between any two nodes. This can be doneby using either a symmetric key cryptographicsystem or a public key cryptographic system.Although a secure channel between two nodesis sometimes required, the use of such channelsshould be kept to a minimum since they impacton the performance of key distribution, keyupdating, and message delivery.

Our framework is constructed over a multicasttree network. Thus, we also assume that there isalready a source-based multicast tree network. Asit is built on an overlay network, there should beno asymmetric logical link in the multicast tree net-work. However, messages exchanged between twoadjacent overlay nodes may be transmitted usingasymmetric physical links. Although asymmetricphysical links do not affect the operation of the pro-posed protocol, it may affect the performance ofcommunications between overlay nodes. Thus, theasymmetric physical links between two adjacentoverlay nodes should be minimized. Readers mayrefer to [15] for optimizing the asymmetric link per-formance during multicast tree construction.

Table 1Notations used in the key composition process

Notation Meaning

R The message receiverS The message senderSID Session ID. The SID is used by a receiver to idPi The intermediate proxy i on the message pathki The secret key of proxy Pi

k0 The secret key of sender S

kSID A randomly generated session key for the keyPCK Partially composed key, an incomplete key duCCK Complete composed key. The final result of a

4.1. Operations and notations

Given two arbitrary keys, k1 and k2, the primitiveoperations used in our framework are the key com-pose operation COMP(k1,k2) and the key decomposeoperation DECOMP(k1,k2). The two operations aredefined as

COMPðk1; k2Þ ¼ k1 þ k2

and

DECOMPðk1; k2Þ ¼ k1 � k2;

respectively. In the key compose operation, a nodeadds its own secret key to a composed key, whichis usually forwarded to the next node securely.The first key composition operation is always initi-ated by the sender. Before the composed key reachesthe receiver, it is called a partially composed key

(PCK). To generate the correct key for a receiver,each node on the path between the sender and recei-ver iteratively incorporates its own secret key intothe PCK. This chain key composition operation iscalled the key composition process. The notationsused in our framework are listed in Table 1.

4.2. The key composition protocol: joining a group

The key composition protocol (KCP) is initiatedwhen a newcomer, R, requests to join a group. First,R has to enter the network by sending a networkjoin request to the closest proxy, which then actsas the parent proxy of R. After R is admitted, thejoin request is forwarded along the upstream pathto the root node. If the sender approves the request,it sends a session ID SID and a randomly generatedsession key, kSID, to R securely via a direct connec-tion or an indirect relayed channel. At the sametime, the sender initiates a key composition process

entify the key composition processthat transforms ciphertexts during the message delivery process

composition process, which is identified by an SID

ring the key composition processkey composition process

S

R

P1

P2

P3

MemberJoinRequest

2

Reply{SID, kSID}

3

4 SID,COMP( k0, kS ID)

5 SID,COMP( k0+ kSID, k1)

6 SID,COMP( k1+ k0+ kS ID, k2)

7 SID,COMP( k2+ k1+ k0+ kSID, k3)

8 SID,DECOMP( k2+ k1+ k0+ kSID, kSID)

MemberJoin Request

1

UserDatabase

Fig. 4. An example of joining a group. Node S is the sender,nodes P1, P2, P3 are the proxies, and node R is the newcomer.


by sending a partially composed key (PCK) ofCOMP(k0,kSID) to the first proxy securely. The k0

key is the secret key of the sender. When a proxyPi receives a PCK, it performs the COMP(received-PCK,ki) operation and forwards the new PCK tothe next node securely. On receipt of the PCK, thereceiver runs the DECOMP(received-PCK,kSID)operation to obtain the final key, which is the com-plete composed key (CCK). Note that during the keycomposition process, the composed PCK is sent withan SID to guarantee that the newcomer can properlydecompose the corresponding kSID and obtain thefinal CCK. Also, when the parent proxy of the new-comer R receives a CCK for R, a re-keying operationmust be performed before computing and returningthe new CCK to R. This operation is discussed in thenext subsection, and an example of a newcomerjoining a group is illustrated in Fig. 4.

The success of the key composition processdepends on whether the sender has delivered thekSID to the receiver. The sender can reject sendinga kSID key to an unknown client. Thus, access con-trol can be applied when the sender receives arequest from a newcomer. In our framework, thegeneration of kSID and access control can be off-loaded to other trusted proxies. We discuss load-sharing with trusted proxies in Section 5.1.

4.3. Leaving a group and re-keying

Leaving a group is much easier than joining, as amember just needs to notify its parent proxy. Thelatter then performs a re-keying operation to changeits own key, and sends the updated key to all mem-bers, except the departing member. Two problemsin secure multicast are maintaining forward secrecyand backward secrecy. Maintaining the formermeans that a member that has left should not be

able to read future confidential messages, while lat-ter means that a newcomer should not be able toread previous confidential messages. Thus, whenthe membership of multicast group changes due toa member joining or leaving, a re-keying operationis always performed.

In our framework, a re-keying operation can beconfined to a subgroup. Only the parent proxyand the subgroup members directly connected tothe proxy need to perform the re-keying operation.Suppose a proxy has a key, k. To perform the re-keying operation, the proxy first chooses a newkey, k 0, and computes Dk = k 0 � k. Then, it sendsthe result of Dk to all connected subgroup memberssecurely. On receipt of a Dk from the parent proxy,a member updates its own key by COMP(original-CCK,Dk). Future ciphertexts can then be decryptedusing the new CCK. A non-leaf node (e.g., the rootnode or any non-leaf proxies) may also perform are-keying operation. In this case, the non-leaf nodeuses the same re-keying methodology as subgroups.Then, the Dk is multicast to all group membersusing the usual message delivery process.

The re-keying operation described above is quitestraightforward. The cost of delivering key updatesto each subgroup member is O(n), where n is thenumber of valid subgroup members. This, however,restricts the scalability of the subgroup. To solve theproblem, we can adopt either distributed or central-ized group key management mechanisms, such asTGDH [10] or LKH [3,4], to improve the re-keying performance of subgroups. Take the LKHapproach as an example. A leaf proxy, which isthe proxy closest to subgroup members, acts as asubgroup controller and maintains a logical key treefor all directly connected subgroup members. Whena member joins or leaves the subgroup, the proxyupdates the keys in the logical tree and then multi-casts the encrypted Dk along with updated logicalkeys to all subgroup members. The LKH approachis efficient because it only requires O(1) multicastsand O(log(n)) computations to update the secretkeys of all subgroup members.

4.4. The message delivery process

The message delivery process follows the nodeson a message path, as shown in Fig. 3. During theprocess, a message is encrypted by the sender andthen transformed by each node on the path. Atransformation is only performed as a message isleaving a node. Note that a message can only be


encrypted/transformed once by the same node,which means there is no loop during the deliveryprocess. Given the ElGamal encryption algorithmEnck(Æ) and the decryption algorithm Deck(Æ) withan arbitrary secret key k, the message delivery pro-cess on Path-II in Fig. 3 is as follows:

1. The sender S encrypts the plain-text message m

with its own secret key k0 and sends out Enck0ðmÞ.

2. The transformation node P1 encrypts thereceived message with its own secret key k1 andsends out Enck1

ðEnck0ðmÞÞ.

3. The transformation node P4 encrypts thereceived message with its own secret key k4 andsends out Enck4

ðEnck1þk0ðmÞÞ.

Finally, the receiver gets an encrypted messageEnck4þk1þk0

ðmÞ, which can be decrypted using thepreviously obtained CCK of k0 + k1 + k4.

When deploying proxy encryption or similartechniques in a secure multicast network, we use a‘‘hybrid encryption’’ [16] technique to improve theoverall performance. These techniques are mainlyused to deliver key encryption keys (KEKs). Inour scheme, the sender randomly generates a sym-metric secret key kr for a symmetric encryptionalgorithm Enc0kð�Þ and uses the key to encrypt theto-be-delivered message, m, as Enc0kr

ðmÞ. Duringthe message delivery process, kr and Enc0kr

ðmÞ aresent together. However, the symmetric secret keykr is encrypted and transformed by all the nodesthat it passes. On receipt of the message, the receivercan decrypt kr with its own CCK and then use kr todecrypt the message m. In summary, the hybridencryption technique uses the subgroup key, whichacts as a key encryption key (KEK), to deliver asymmetric secret key so that a receiver can decryptthe encrypted message. The symmetric secret keyshould be changed periodically to guarantee bothforward and backward secrecy.

4.5. Handling network dynamics

In a dynamic network, a proxy may join or leavethe multicast tree network at any time. A proxy mayalso crash due to unexpected fatal errors. Suchevents make it necessary to modify the multicasttree’s topology, which affects the path keys ofrelated receivers. Since the receivers do not knowthe exact key of the affected proxy, the only wayto update the path keys is to ask all receivers torun the key composition protocol again. This cre-

ates a substantial extra workload for both the sen-der and the network, especially when the numberof affected receivers is large. To prevent this situa-tion, we propose solutions that handle the networkdynamics by only altering the keys of nodes close tothe problematic proxy.

Assume there is already a working secure multi-cast network, and a new proxy can join the networkas either a leaf proxy or a non-leaf proxy. Joining asa leaf proxy is fairly easy, since the new proxy onlyneeds to randomly generate a secret key for itselfand then find the closest available parent proxy tojoin the network. However, to join as a non-leafproxy, the new proxy must first find the closestavailable parent proxy and a child proxy of theparent proxy. Then, the newcomer has to ‘‘insert’’itself on the link between the child proxy and theparent proxy. The new proxy does not make thedecision about its own secret key. Instead, the keyis randomly generated by the child proxy andassigned to the new proxy. Assume that the childproxy randomly generates a secret key kx to thenew proxy. At the same time, the child must alterits own secret key, kchild, by DECOMP(kchild,kx).The two ways for a proxy to join a network are illus-trated in Fig. 5. In the Part I of Fig. 5, a new proxyPx may join as a leaf proxy under proxy P3 or as anon-leaf proxy under the sender S. As shown in PartII-1, Px can decide its own secret key as kx, sincejoining as a leaf proxy does not affect any receivers.In the Part II-2, joining between the link of S and P1

may affect the path keys of R1 and R2. Thus, thesecret key of Px is assigned by P1 as kx securely; thenthe secret key of P1 is changed to k1 � kx.

Unlike membership operations, proxy leaving ismore complex than proxy joining. When a proxycrashes or is off-line, the link between the senderand several receivers that passes the problematicproxy is broken. Thus, the proxies close to the prob-lematic node should be responsible for repairing thetopology. Here we make the following additionalassumption: when a proxy joins a network, it sendsinformation about its secret key to its parent and itschildren securely as kP + kx and kP � kx, respec-tively. (kP is the secret key of the proxy and kx isa randomly generated value.) When the proxycrashes or is off-line, its parent node chooses oneof its children to replace the problematic node.Then, the parent node sends kP + kx to the chosennode securely. The secret key of the chosen node,kchosen, is then set to COMP(kchosen,kP). Fig. 6 showsthe procedures for handling proxy leaving. Assume

Fig. 5. Procedures to handle a newly joined proxy in a dynamic network.

Fig. 6. Procedures for handling a crashed or off-line proxy in a dynamic network.


that the proxy P1 will be off-line later. In Part I, P1

sends secret key information k1 + kx and k1 � kx toits parent and children, respectively. When P1 is off-line, the parent node S chooses node P3 to replaceP1 and sends k1 + kx to P3; then, P3 sets its ownsecret key to k1 + k3.

As the receivers’ secret keys do not need to beupdated with information about proxies joining orleaving, after a join or leave operation has beencompleted successfully, the receivers can decryptencrypted messages as usual.

An important task for handling network dynam-ics is to detect proxy failures. An off-line node mustbroadcast the event to all its adjacent beforehandfor them to prepare well for the possible topologychanges. However, as a failed or a crashed proxyis mostly unable to complete the sign-out process,there should be some alternatives to detect failuresof neighborhood proxies. While the failure of anode can be corrected locally, a simple way to detect

unexpected node failures is to use heartbeat mes-

sages. Since a proxy knows all the adjacent childrenproxies, it can always periodically send ‘‘ping’’ mes-sages to all these children and then wait for the cor-responding ‘‘pong’’ messages. Thus, a node failurecan be identified within at most the interval of two‘‘ping’’ messages. Although heartbeat messagescan detect unavailable children, it cannot tellwhether the problem is on the child itself or iscaused by link failures. No matter what the problemis, on detecting a child failure, the node will alwaystry to contact the grandchildren under the problem-atic child proxy and try to pick one of the grandchil-dren to replace the possible crashed proxy. This alsoisolates only the problematic proxy. Then, an iso-lated proxy can detect link failures by both (1) itdoes not receive heartbeat messages from its parentand (2) it also does not receive notifications of par-ent crash from its grandparent. If a link failure isdetected by an isolated node, the node can reenter

S

R

P2

P3

P4

P1

UserDatabase

P2 - KC: Obtain { k0+ k1}

1

P2- Intercept

Member JoinRequests

2MemberJoin Request

3

Reply{SID, kS ID}

4

SID,COMP( k0+ k1+ k2, kSID)

5

SID,COMP( k2+ k1+ k0+ kS ID, k3)

6

SID,COMP( k3+ k2+ k1+ k0+ kSID, k4)

7

SID,DECOMP( k4+ k3+ k2+ k1+ k0+ kS ID, kS ID)

8

Fig. 7. An example of delegating access control to proxy nodes.


the network by initiating a new network joinrequest.

It is also worth noting that when a left proxycomes back, it cannot be placed at its original loca-tion before it leaves. Such a proxy is treated as anew comer and it must connect to the network asa leaf member or a leaf proxy. The reason for thisdesign is to prevent the tree topology from oscilla-tions caused by frequently joining or leaving ofunstable nodes.

5. Evaluations and discussions

We now evaluate and discuss several aspects ofthe proposed framework. First, we discuss the possi-bility of sharing the load on the root node. Then, wediscuss the security of our framework in detail. Wealso compare the performance of our frameworkwith that of similar secure multicast frameworks.

5.1. Load-sharing with trusted proxy nodes

In our framework, a receiver initiates the net-work join process by forwarding a ‘‘member joinrequest’’ to the sender. As a result, all the joinrequests from potential members are gathered atthe root node. However, this may increase the loadon the root node substantially and hence reduce theoverall performance of the framework. To solve theproblem, the loads induced by member join requestsshould be shared among several trusted proxies.

To do this, a root node must choose some trustedproxies. A selected proxy initiates the key composi-tion protocol to obtain the CCK between the rootand the parent proxy of the selected proxy. Aftersuccessfully completing the key composition pro-cess, the selected proxy becomes a delegated proxy

and handles future join requests generated by alldownstream members. On intercepting a joinrequest, just like a root node, the delegated proxyinitiates the key composition process. The keys usedfor the key composition process are the previouslyobtained CCK plus the secret key of the delegatedproxy and a randomly generated session key. Anexample of a running delegated proxy is illustratedin Fig. 7. In the figure, the proxy P2 is chosen as adelegated proxy. Thus, it has to obtain the CCKbetween the root S and its parent proxy P1, i.e.,k0 + k1. A newcomer R joins the network as usualand initiates a member join request, which is sentto the root. However, the request does not reachthe root, as it is intercepted by P2. The remainder

of the key composition process is the same as inthe original (proposed) framework.

It should be noted that the delegated proxy mustbe trustworthy because it has the key to decryptciphertexts sent from the root. Besides, since a dele-gated proxy is responsible for access control, itshould be able to access or at least query the mem-bership database. The design of proxy delegation inour framework is inherently reliable. Once it isdetected that a delegated proxy has crashed or isoff-line, network join requests can simply beforwarded to the root node after the topology hasbeen repaired. The root node can then choose anew delegated proxy.

5.2. Security analysis

In this section, we focus on several securityissues. First, we discuss the common criteria that asecure multicast framework must possess. Then,we describe the use of ElGamal-based proxy cryp-tography for message delivery. We also examinethe strength of the key composition process in termsof security. Finally, we discuss the problem of proxycompromise. The common criteria that a securemulticast framework must possess are: guaranteedof forward/backward secrecy, the ability to preventcollusion, and the ‘‘containment’’ property. In ourframework, both forward and backward secrecyare achieved by re-keying at the parent proxy nodes.When a newcomer joins, or an existing memberleaves, the parent proxy node must change its secretkey and update the decryption keys of membersunder its control. With regard to collusion, as thedecryption keys of members under different proxiesare isolated because of different message paths, it ishard for those members to collude. Also, since

R

A2A2

k2k2+ k3+ k3

S

A1A1K3K3P4

P3

P1 P2

Fig. 8. An example of proxy compromises. There are twoadversaries A1 and A2. The sender has a secret key k0, and eachproxy Pi has a secret key ki. In this example, the adversary A1

compromises the parent proxy P2 and the child proxy P4 of proxyP3. Thus, it obtains the secret key of P3. The adversary A2

compromises the leading proxy P1 and the trailing proxy P4 ofthe message path and hence obtains k2 + k3.


subgroups are isolated, if one is compromised, itdoes not affect the whole multicast network. Hence,the framework can limit damage to one part of thenetwork.

Our framework delivers messages using ElGamal-based proxy cryptography. Suppose an encryptedmessage fcð1;0Þ; cð2;0Þg ¼ fgr;m � grk0g sent from theroot node is being delivered via a message path con-taining n proxies P1,P2, . . . ,Pn, and each proxy has asecret key ki (1 6 i 6 n). A message transformed bythe kth proxy Pk is denoted as {c(1,k),c(2,k)}. Whena transformed message {c(1,j�1),c(2,j�1)} sent fromthe (j � 1)th proxy passes the jth proxy Pj, the lattertransforms the received message to another cipher-text {c(1,j),c(2,j)} by fcð1;jÞ; cð2;jÞg ¼ fcð1;j�1Þ; cð2;j�1Þ�ckj

ð1;j�1Þg. In this scenario, an adversary could eaves-drop on network traffic of proxy Pj and know about{c(1,j),c(2,j)} and {c(1,j�1),c(2,j�1)}. However, to breakthe secret key of Pj, the adversary has to solvecð2;jÞ ¼ cð2;j�1Þ � ckj

ð1;j�1Þ, which is equivalent to solvingthe discrete logarithm problem (DLP); that is, givena prime number p, a group generator g, and y = gx

(mod p), find x. The security of message delivery isthus guaranteed, since it is infeasible to computethe DLP, especially when p is large. It is recognizedthat the ElGamal cryptosystem is only secure againstCPA (chosen plain-text attacks) [17], and cannotresist chosen ciphertext attacks (CCA). However,this is not a problem in our framework becauseproxies only transform passed ciphertexts byencrypting them again. Therefore, attackers cannotuse these proxies as oracles to attack the ElGamalcryptosystem.

The security of the key composition process isguaranteed by the randomly generated session keykSID, which is decided by the message sender. SincekSID is added with real secret keys, the possibility ofguessing kSID and the real secret keys depends on thelength of the secret keys, which vary from 256 bitsto 2048 bits. Thus, it is impossible to determineeither kSID or the secret keys from the composedvalue of kSID and the secret keys.

Two methods can be used to obtain the secret keyof a proxy. One is to compromise the proxy, whichallows an adversary to find out and access the secretkey directly. The other method is to compromiseboth the parent proxy and a child proxy of the givenproxy. In this case, if an adversary knows the secretkeys of both the parent proxy and a child proxy, hecan compute the difference between the PCKs of theparent and the child proxy during the key composi-tion process. Extending such an attack, an adver-

sary may compromise any two proxies on amessage path and hence know the contributorysecret keys of all proxies between the two compro-mised proxies. An example of compromising proxieson a message path is illustrated in Fig. 8. However,these kinds of compromise do not affect the securityof the framework. Even if an adversary knows thesecret keys of all the proxies on a message path, todecrypt the message sent out from a sender orreceived by the receivers, an adversary still has tocompromise either the sender or one of the receiversto obtain the encryption key or the decryption CCK,respectively. The problem of compromising the sen-der or a receiver is not within the scope of thispaper. If a sender or a receiver is compromised,the adversary does not need to know the key todecrypt the ciphertexts, since a decrypted messagecan be accessed directly via a compromised senderor receiver.

5.3. Performance evaluation and comparison

The performance evaluation of our frameworkfocuses on the storage, computation, and communi-cations costs of the message delivery and key com-position processes. The message delivery process isvery efficient. When a message is being deliveredto a receiver, each proxy passed only applies oneencryption to transform the message. Receivers onlyneed storage space for CCK, which is the decryptionkey. However, the root node and proxies requirestorage space for 2 + d keys, where d is the averagenumber of branches for intermediate nodes, since

Table 2Performance comparison with similar frameworks

LKH IOLUS DEP CS/PE Ours

Number of keys per member O(log(m)) 1 2 1 1

Number of keys at key server O(m) 2 O(s) O(s) –Number of keys at intermediate nodes – d 2 1 2 + d

Cost of re-keying O(log(m)) O(d) O(m) O(n) O(log(n))Number of encryptions by a distributor O(1) O(d) O(s) O(1) O(1)Need to trust intermediate nodes – Yes No Partially Partially


they need to store extra key information for the useif the network fails.

The cost of joining or leaving a group dependsmainly on the re-keying cost. In our framework,the re-keying cost is O(log(n)), where n is thenumber of members in a subgroup. An additionalcost of members joining is running the key compo-sition process because a request must be sent fromthe receiver to the root node and then returnedto the receiver. Thus, each proxy has to performtwo forwarding operations. The process shouldtake roughly a round trip time between the receiverand the root node.

We further evaluate the performance of ourframework by comparing it with other similarframeworks. For the ease of comparison, we assumeall these frameworks construct a balanced tree net-work. Table 2 shows the performance of all thecompared frameworks. In the table, the number ofgroup members is denoted by m, the number of sub-groups for a scheme that uses a subgrouping tech-nique is denoted by s, the number of members in asubgroup is denoted by n, and the average numberof branches of intermediate nodes is denoted by d.The performance of our framework is shown inthe column marked ‘‘Ours’’.

6. Conclusions

In this paper, we have proposed a scalable andlightweight framework that provides secure multi-cast communications in a dynamic environment.The framework is based on a simple and novel tech-nique called key composition, and can be applied toany source-based multicast tree network. With theproperties of key composition and proxy encryp-tion, our framework eliminates the need for keydistribution centers used in proxy cryptography.In addition, our network’s robustness against fail-ure enables it to work in a distributed manner.The proposed framework is also efficient. Each node

only needs to perform one encryption or transfor-mation to guarantee the confidentiality of a mes-sage. The storage and computation costs of thekey composition process are both constants. There-fore, our framework is scalable for large anddynamic multicast groups. For the above reasons,it can be easily applied in dynamic networks, suchas peer-to-peer or overlay networks. The perfor-mance comparison also shows that our frameworkis more efficient than the compared frameworks.

References

[1] S.E. Deering, D.R. Cheriton, Multicast routing in datagraminternetworks and extended lans, ACM Transactions onComputer Systems (TOCS) 8 (2) (1990) 85–110.

[2] S. Rafaeli, D. Hutchison, A survey of key management forsecure group communication, ACM Computing Surveys(CSUR) 35 (3) (2003) 309–329.

[3] D. Wallner, E. Harder, R. Agee, Key management formulticast: issues and architectures, RFC 2627.

[4] C.K. Wong, M. Gouda, S.S. Lam, Secure group communi-cations using key graphs, IEEE/ACM Transactions onNetworking 8 (1) (2000) 16–30.

[5] S. Mittra, Iolus: a framework for scalable secure multicast-ing, in: Proceedings of the Conference on Applications,Technologies, Architectures, and Protocols for ComputerCommunication, ACM SIGCOMM, 1997, pp. 277–288.

[6] L. Dondeti, S. Mukherjee, A. Samal, Scalable secure one-to-many group communication using dual encryption, Com-puter Communication 23 (17) (2000) 1681–1701.

[7] R. Mukherjee, J. Atwood, Proxy encryptions for securemulticast key management, in: Proceedings of the 28thAnnual IEEE Conference on Local Computer Networks,IEEE LCN, 2003, pp. 377–384.

[8] R. Molva, A. Pannetrat, Scalable multicast security withdynamic recipient groups, ACM Transactions on Informa-tion and System Security 3 (3) (2000) 136–160.

[9] M. Steiner, G. Tsudik, M. Waidner, Diffie-Hellman keydistribution extended to group communication, in: CCS’96:Proceedings of the 3rd ACM Conference on Computer andCommunications Security, ACM Press, 1996, pp. 31–37.

[10] Y. Kim, A. Perrig, G. Tsudik, Simple and fault-tolerant keyagreement for dynamic collaborative groups, in: CCS’00:Proceedings of the 7th ACM Conference on Computer andCommunications Security, ACM Press, 2000, pp. 235–244.


[11] T. Elgamal, A public key cryptosystem and a signaturescheme based on discrete logarithms, IEEE Transactions onInformation Theory 31 (1985) 469–472.

[12] M. Blaze, G. Bleumer, M. Strauss, Divertible protocols andatomic proxy cryptography, in: Proceedings of Advances inCryptology: EUROCRYPT’98: International Conference onthe Theory and Applications of Cryptology Techniques,LNCS, 1998, pp. 127–144.

[13] A. Ivan, Y. Dodis, Proxy cryptography revisited, in:Proceedings of Network and Distributed System SecuritySymposium, ISOC, 2003.

[14] W. Diffie, M.E. Hellman, New directions in cryptography,IEEE Transactions on Information Theory 22 (1976) 654–655.

[15] S. Ramanathan, Multicast tree generation in networks withasymmetric links, IEEE/ACM Transactions on Networking4 (4) (1996) 558–568.

[16] V. Shoup, A proposal for an ISO standard for public keyencryption, Cryptology ePrint Archive, Report 2001/112,http://eprint.iacr.org/2001/112, September 2001.

[17] Y. Tsiounis, M. Yung, On the security of elgamal basedencryption, in: PKC ’98: Proceedings of the First Interna-tional Workshop on Practice and Theory in Public KeyCryptography, Springer-Verlag, London, 1998, pp. 117–134.

Chun-Ying Huang received his B.S.degree in Computer Science fromNational Taiwan Ocean University in2000 and the M.S. degree in ComputerInformation Science from NationalChiao-Tung University in 2002, respec-tively. He is now a Ph.D. candidate inthe Department of Electrical Engineer-ing, National Taiwan University. Hiscurrent research interests focus on com-puter networks and network security,

including key management, attack mitigation, intrusion detec-tion, and traffic analysis.

Yun-Peng Chiu received his B.S. degreein Electrical Engineering from NationalTsing-Hua University, Taiwan, in 1996,and the M.S. degree in Electrical Engi-neering from National Taiwan Univer-sity, Taiwan, in 1998. He is now a Ph.D.candidate of Electrical Engineering atNational Taiwan University, Taiwan.His current research interests includenetwork security and cryptography. Heis a student member of the Association

for Computing Machinery, the Chinese Cryptology and Infor-mation Security Association, the Institute of Electrical and

Electronic Engineers, and the Institute of Electronics, Informa-tion, and Communication Engineers.

Kuan-Ta Chen received his B.S. and M.S.in Computer Science from NationalTsing-Hua University in 1998 and 2000,respectively. He received his Ph.D. inElectrical Engineering from NationalTaiwan University in 2006. Since then hejoined the Institute of Information Sci-ence, Academia Sinica as an assistantresearch fellow. His research interestsinclude multimedia networking, Internetmeasurement, network security, and

entertainment networking. Much of his recent work focus on theanalysis and design of networked entertainment systems,
including traffic characterization, transport protocols, quality ofservice, human factors, and game cheat detections. He is amember of ACM and IEEE.
Chin-Laung Lei received his B.S. degreein Electrical Engineering from NationalTaiwan University in 1980, and hisPh.D. degree in Computer Science fromthe University of Texas at Austin in1986. From 1986 to 1988, he was anassistant professor in the Computer andInformation Science Department at theOhio State University, Columbus, OH,USA. In 1988, he joined the faculty ofthe Department of Electrical Engineer-

ing, National Taiwan University, where he is now a professor.His current research interests include computer and network
security, cryptography, parallel and distributed processing,design and analysis of algorithms, and operating system design.He is a member of the Institute of Electrical and ElectronicsEngineers and the Association for Computing Machinery.
http://eprint.iacr.org/2001/112

Documents

Secure multicast in dynamic environments