214 IEEE TRANSACTIONS ON COMPUTERS, VOL. 54, NO.

2, FEBRUARY 2005

A Novel High-Order Tree for

Secure Multicast Key Management
Haibin Lu, Member, IEEE

Abstract—Multicast is used to deliver packets to a group of users. To prevent users outside the group from eavesdropping, a group key
is maintained to encrypt the group communication, and the group key is changed (rekeying) when a new member joins the group or an
existing member leaves the group. Rekeying costs could be as high as n for a group with n members. The hierarchical key-tree approach
is widely used to achieve logarithmic rekeying costs. However, the key tree has to be kept balanced in order to keep logarithmic rekeying
costs. Goshi and Ladner [8] propose the height-balanced 2-3 tree (a B-tree of order m ¼ 3) and found that it has the best performance
among the balancing strategies tested. However, balancing a B-tree [8] after member joining involves splitting oversized tree nodes and
results in ðm þ 2Þh worst-case rekeying cost, where h is the tree height. We propose an NSBHO (Non-Split Balancing High-Order) tree in
which balancing tree after member joining does not involve node splitting, thus having 2h worst-case rekeying cost. An NSBHO tree is
always balanced and its nodes may not satisfy the node properties of a standard B-tree. Our proposed NSBHO tree has the same worst-
case rekeying cost incurred by a member removing as a B-tree [8] does. Our experiments show that the NSBHO tree has better average-
case rekeying performance and far superior worst-case rekeying performance than a B-tree.

Index Terms—Group key management, secure multicast, dynamic group, high-order tree, balanced tree, rekeying.

1 INTRODUCTION

M Internet applications, such as online multiplayer

ANY
gaming, pay-per-view, and group meeting, require
delivering packets from one or many sources to a group of
destinations. Multicast (IP multicast or end-host multicast)
is often used to efficiently deliver the packets to the group
members [15]. Multicast greatly reduces server load and
network resource consumption by sending one multicast
message instead of n unicast messages to n destinations.
However, multicast traffic also reaches unsubscribed
destinations, e.g., workstations on the Ethernet where at
least one multicast destination exists can also receive the
multicast packets. To prevent eavesdropping and protect
the content of multicast traffic, multicast packets must be
delivered securely so that only the intended receivers can
decode it and no one else can (nongroup confidentiality).
Multicast group is usually dynamic, i.e., new members may
join in and existing members may leave. As a result, the
confidentiality requirement also includes past confidentiality
(a new member joining in at time t can’t decode any
multicast messages before t), future confidentiality (an
existing member leaving at time t can’t decode any
multicast messages after t), and collusion freedom (no set of
deleted members can cooperate to decode future multicast
messages) [21].
The simple solution to achieving secure multicast is to
use a group key to encrypt group communication [9], [10].
When a new member joins in or an existing member leaves,
the group key needs to be replaced (rekeying). The rekeying
cost is often measured in terms of client computation cost,
. The author is with the Department of Computer Science, University of
Missouri, Columbia, MO 65211. E-mail: luhaibin@missouri.edu.
Manuscript received 19 May 2004; revised 10 Sept. 2004; accepted 21 Sept.
2004; published online 15 Dec. 2004.
For information on obtaining reprints of this article, please send e-mail to:
tc@computer.org, and reference IEEECS Log Number TC-0167-0504.
0018-9340/05/$20.00 ß 2005 IEEE
Authorized licensed use limited to: Arulmigu Kalasalingam College of Engineering. Downloaded on February 5, 2010 at 23:16 from IEEE Xplore. Restrictions apply.
server computation cost, and message cost [24]. The client
computation cost is the size of the messages the client has to
decode, the server computation cost is the size of the
messages the server has to encrypt, and the message cost is
the sum of the size of the unicast and multicast messages
the server sent out. The message cost is usually measured as
the sum of the number of keys in the unicast and multicast
messages. We will use the message cost to measure the
efficiency of the proposed scheme since “communication
complexity is probably the most important measure, as it is
the biggest bottleneck in current applications” [2] and the
client computation cost and the server computation cost of
the scheme proposed in this paper are asymptotically no
larger than the message cost.
The group key needs to be securely conveyed to the
group members every time the group key is changed. The
widely used hierarchical key-tree approach proposed by
Wallner et al. [23] and independently by Wong et al. [24] is
an efficient way to the reduce rekeying cost. Given that the
underlying tree is balanced, the hierarchical key-tree
approach achieves logarithmic rekeying costs. However,
the key tree may become out of balance after inserting/
deleting members. Once it is unbalanced, the tree remains
unbalanced until either insertions/deletions bring the tree
back to a balanced state or some actions are taken to
rebalance the tree. The former relies on the insertion/
deletion pattern. The latter may have very high rebalance
cost. Balanced tree approaches [13], [16], [8] spread
rebalance costs over many updates and, more importantly,
guarantee the worst-case rekeying cost. Goshi and Ladner
[8] compared the performance of their proposed schemes
with other tree-balancing schemes and found that the
order-3 B-tree has the best performance. However, rebalan-
cing a B-tree after insertion is achieved by node splitting,
which is expensive in terms of the message cost. We
propose in this paper an NSBHO (Non-Split Balancing
Published by the IEEE Computer Society
LU: A NOVEL HIGH-ORDER TREE FOR SECURE MULTICAST KEY MANAGEMENT
High-Order) tree which does not use node splitting to
balance the tree. The worst-case rekeying cost incurred by a
member joining is 2h and the worst-case rekeying cost
incurred by a member leaving is d
1 þ mh, where h is the
tree height, m is the order of tree,1 and d ¼ dm=2e. Rekeying
costs for both insertion and deletion can be further reduced
by h
1 when the improvement proposed by Canetti et al.
[1] is applied.
This paper is organized as follows: In Section 2, we
describe related work and explain why node splitting
should be avoided for tree balancing. Section 3 gives the
theoretical development of the NSBHO tree and Section 4
shows the rekeying costs when the NSBHO tree is applied
to group key management. Experimental results are
presented in Section 5. Our results are summarized in
Section 6.
2 RELATED WORK
We use the following notations:
. K{action}: action encrypted using secret key K. Any
member receiving Kfactiong and possessing key K
will decrypt the message and perform the action.
. action includes:
- k1 ! k2 : change key k1 to key k2 .
- add k1 : add key k1 to the key list.
- setGroupKey k1 : use key k1 as the group key.
We will introduce the hierarchical key-tree approach in
Section 2.1. Readers who are familiar with it can skip this
subsection. Section 2.2 discusses existing approaches to
rebalancing the key tree after adding/deleting a member.
Section 2.3 explains why node splitting should be avoided
during tree rebalancing.
2.1 Rekeying Approaches
The group key needs to be securely conveyed to the group
members every time the group key is changed. A simple
approach is for the server to assign each group member a
unique member key. When a new member joins in, a new
group key is generated to achieve past confidentiality. Since
the new member does not know the old group key, the
server can use the old group key to encrypt the new group
key and to multicast the result to all group members. The
server also uses the member key of the new member to
encrypt the new group key and to unicast the result to the
new member. When an existing group member leaves, the
server generates a new group key to achieve future
confidentiality. This time the server can’t use the old group
key to encrypt the new group key because the leaving
member knows the old group key. A straightforward
solution is for the server to encrypt the new group key
using the unique member key of each of the remaining
members and to send a unicast message to each member.
n
1 unicast messages are needed. This poses a scalability
problem for large dynamic groups.
Public key rekeying approaches such as group Diffie-
Hellman [22] require a linear number of public key
1. The order is the maximum number of children a tree node can have.
Authorized licensed use limited to: Arulmigu Kalasalingam College of Engineering. Downloaded on February 5, 2010 at 23:16 from IEEE Xplore. Restrictions apply.
215
Fig. 1. Key trees for member u3 leaving and joining the group.
operations, which is too high for software implementation.
The widely used hierarchical key-tree approaches [23], [24],
[2], [1], [3], [12], [13], [14], [20], [19] have logarithmic
rekeying costs when the key trees are balanced. It is this
approach upon which this paper focuses. Canetti et al. [2]
modify the key-tree scheme proposed by Wallner et al. [23]
and enable the trade off between message costs and storage.
Snoeyink et al. [21] prove a
ðlog nÞ lower bound for
rekeying costs under the key-based multicast model [2] and
show that the 3-ary tree is optimal for group key
distribution without considering the message cost due to
tree rebalancing. The broadcast encryption [7] takes a
different approach than the hierarchical key-tree approach.
Its rekeying message cost is independent of the number of
members left. However, it is only resilient against any
coalition of k past members. High resilience requires a large
value of k, which greatly increases the message cost. In
contrast, the hierarchical key-tree approaches with past
confidentiality are often secure against the coalition of any
number of past members.
Chen and Dondeti [5] compare the performance of
stateful and stateless group rekeying algorithms. Eskicioglu
[6] reviews the security issues in group multimedia
communication, including group key management.
Below, we will illustrate the idea of hierarchical key-tree
approach proposed by Wallner et al. [23] and independently
by Wong et al. [24]. The server maintains a tree to organize the
existing group members. Fig. 1 shows two key trees. Each
member (square node) has a unique member key, e.g., u3 has a
member key (k3 ). Each internal (round) node has a unique
subgroup key that is known only to the group members in the
subtree rooted at this node, e.g., sk2 is known only to u8 , u9 ,
u10 , and u11 . Therefore, ui knows only the keys on the path
from the root to the square node for ui . In Fig. 1, member u1
knows only gk, sk1 , sk3 in addition to k1 . The key at the tree
root is used as the group key and other subgroup keys are
used for rekeying purposes.
216
When member u3 leaves the group (Fig. 1), the subgroup
keys possessed by u3 have to be changed to ensure that u3
can’t decode any future multicast messages. That is, sk3 is
changed to sk03 , sk1 is changed to sk01 , and gk is changed to
gk0 . The server uses multicast to distribute the new
subgroup keys (including the group key) to the members
affected by the rekeying. The rekeying process works from
the bottom up. Message k1 fsk3 ! sk03 g is sent to u1 , and
message k2 fsk3 ! sk03 g is sent to u2 . Members u1 , u2 , u4 , u5 ,
u6 , and u7 need to know sk01 . Instead of six unicast
messages, three multicast messages, sk03 fsk1 ! sk01 g,
sk4 fsk1 ! sk01 g, and sk5 fsk1 ! sk01 g, are enough to inform
them of sk01 . It is safe to multicast sk03 fsk1 ! sk01 g to the
whole group since only u1 and u2 know the sk03 that is
needed to decrypt the message. Similarly, it is safe to
multicast sk4 fsk1 ! sk01 g and sk5 fsk1 ! sk01 g. Finally, two
multicast messages, sk01 fgk ! gk0 g and sk2 fgk ! gk0 g, are
used to inform all the members of the new group key (gk0 ).
Notice that, in practice, it is not necessary to include key skj
in the message ski fskj ! sk0j g since skj is the parent of ski
during the rekeying process for member leaving. Therefore,
the total number of messages needed (i.e., message cost) is
equal to the sum of the number of children of the nodes on
the path from the root to the parent of u3 minus one (since
u3 is removed).
When member u3 joins the group, u3 gets a unique
member key and becomes a child of sk03 (Fig. 1). We
certainly need to change the current group key, gk0 ;
otherwise, u3 will be able to decode previously recorded
messages such as pay-per-view movies. We also need to
change the other subgroup keys, sk03 and sk01 , on the path
from the root to u3 ; otherwise, if u3 overheard the sk03 fsk1 !
sk01 g and sk01 fgk ! gk0 g that were used in the rekeying
process following a member leaving (as described in the
previous paragraph), then u3 will be able to discover gk0
since knowing sk03 enables u3 to discover sk01 and knowing
sk01 enables u3 to discover gk0 . Therefore, we have to change
all subgroup keys on the path from the root to u3 . sk03 fsk03 !
sk3 g is used to tell u1 and u2 to replace sk03 with the new
subgroup key sk3 . (The sk3 here is not the same as the sk3
described in the previous paragraph since the new
subgroup keys will invariably be randomly generated.)
Notice that we can use the old subgroup key sk03 to encrypt
the new subgroup key sk3 because the joining member u3
does not know sk03 . sk01 fsk01 ! sk1 g and gk0 fgk0 ! gkg are
used for changing the subgroup keys sk01 and gk0 , respec-
tively. Therefore, the total number of the multicast
messages needed is the number of nodes on the path from
the root to the parent of u3 . In addition, the server needs to
tell u3 the subgroup keys, sk3 , sk1 , and gk. The message,
k3 fadd sk3 ; sk1 ; gkg, of size three is unicast to u3 . Hence, the
overall rekeying cost is equal to twice the number of nodes
on the path from the root to the parent of u3 . It is easy to see
that the above rekeying procedures for member joining and
leaving meet the confidentiality requirement.
In contrast to rekeying immediately after member joining
or leaving, batch rekeying [4], [11], [18], [25] reduces the
message cost, but violates the confidentiality requirement
since it allows the deleted member to continue to access
multicast content for a period of time.
Authorized licensed use limited to: Arulmigu Kalasalingam College of Engineering. Downloaded on February 5, 2010 at 23:16 from IEEE Xplore. Restrictions apply.
IEEE TRANSACTIONS ON COMPUTERS, VOL. 54, NO. 2, FEBRUARY 2005
Fig. 2. node sk1 splits into nodes sk01 and sk001 . B-tree order m ¼ 3.
2.2 Keeping the Key Tree Balanced
If the key tree in Fig. 1 is balanced, the rekeying cost
incurred by a member joining or leaving is Oðlog nÞ since
h ¼ Oðlog nÞ. However, the key tree may gradually become
out of balance after a number of members leave. In order to
keep the message cost at Oðlog nÞ, the key tree should be
kept balanced. Maintaining balance for member joining is
relatively easy since the server can control where to add a
new member in the key tree. Moyer et al. [13] always insert
the new member at the shallowest point in a binary key tree
to keep the tree height as low as possible. However,
deleting members may cause the key tree to become out of
balance since there is no control over the location of where
the member will be deleted. This may result in
OðnÞ message cost for member deleting (e.g., the left/right
skewed key tree has tree height n). Moyer et al. [13] use two
methods to rebalance the key tree following a member
deletion. The first method is to move a member at the
deepest tree level to the place where the deleted member
just was. This method has up to 4h cost, where h is the
height of the binary key tree. The second method allows the
key tree to become out of balance for a period of time, then
rebalanced. Rodeh et al. [16] use the merging method of the
AVL tree for tree rebalancing. After a member leaves, the
key tree is split into h subtrees, then these subtrees are
merged into a balanced tree. However, the technique
discussed in [16] does not satisfy past confidentiality
requirements. Goshi and Ladner [8] propose three schemes
for maintaining a balanced high-order key tree. The
schemes are optimal tree with switching, height-balanced
2-3 tree, and weight-balanced 2-3 tree. Goshi and Ladner
compare the performance of proposed schemes with other
tree-balancing schemes. In their experiment, the height-
balanced 2-3 tree had the best performance.
2.3 Splitting One Node Costs m þ 1 Multicast
Messages
The height-balanced 2-3 tree [8] is a B-tree of order m ¼ 3.
Rebalancing a B-tree after insertion is achieved by node
splitting. While the rekeying message cost is one multicast
message per tree level without node splitting, it requires
m þ 1 multicast messages per level with node splitting.
Fig. 2 shows an example of node splitting. Since the B-tree
order is equal to 3, an internal node can have at most three
children. Therefore, node sk1 needs to be split into two
nodes, sk01 and sk001 . The subgroup keys, sk01 and sk001 , should
be randomly generated and can’t be the same as sk1 .
Otherwise, assume sk01 ¼ sk1 , the members in the subgroup
sk001 know sk1 , which gives them the ability to trace the
subgroup keys from sk01 ð¼ sk1 Þ up and eventually to get the
group key, even if, later on, they leave the group. To achieve
further confidentiality, the server could change sk01 ð¼ sk1 Þ
LU: A NOVEL HIGH-ORDER TREE FOR SECURE MULTICAST KEY MANAGEMENT
Fig. 3. An NSBHO tree of order 3. The shaded nodes are in the special
path (SP ). The tree height h ¼ 3 (the external nodes are excluded).
when a member in the subgroup sk001 leaves. However, since
sk01 ð¼ sk1 Þ is not on the path from the root to the members
in sk001 , changing sk01 ð¼ sk1 Þ requires the server to remember
which keys out of the path are known by the members in
the subgroup sk001 . This causes the rekeying procedure to
become complicated and may raise the rekeying cost to as
high as n (when a leaving member knows many subgroup
keys out of the path).
Following nodes splitting, the new subgroup keys
sk01 and sk001 are distributed in four multicast messages,
sk2 fsk1 ! sk01 g, sk3 fsk1 ! sk01 g, sk4 fsk1 ! sk001 g, a n d
sk5 fsk1 ! sk001 g. Notice that we can’t use sk1 fsk1 ! sk01 g
and sk1 fsk1 ! sk001 g because the members in the subgroups
sk01 and sk001 know sk1 and can decrypt both messages.
Therefore, splitting one node requires m þ 1 multicast
messages. Since insertion may split up to h nodes and a
unicast message of size h is used to tell the new member the
subgroup keys, the worst-case rekeying cost for inserting a
new member is ðm þ 2Þh.
3 NSBHO (NON-SPLIT BALANCING HIGH-ORDER)
TREE
In this section, we first give the definition of the NSBHO
tree, then, in Section 3.1, we compare the height of the
NSBHO tree with that of the standard B-tree of the same
order. The algorithm for inserting an external node into the
NSBHO tree is discussed in Section 3.2 and that for
removing an external node from the NSBHO tree in
Section 3.3. Both algorithms ensure that the resulting trees
are still NSBHO trees.
We call the nodes for group members external nodes. In
Fig. 1, square nodes ki , 1  i  11, are external nodes. All
other nodes are internal nodes. We define the level of node
x as x:level ¼ x:parent:level þ 1 and root:level ¼ 0. Assum-
ing that h is the height of the tree (the external nodes are
excluded), then the external nodes are at level h. In Fig. 3,
the external nodes are at level 3 and the tree height is 3.
Definition 1. An empty tree is an NSBHO (Non-Split
Balancing High-Order) tree of order m. A tree with only one
external node and no internal nodes is an NSBHO tree of order
m. If an NSBHO tree of order m is not empty and has more
than one external node, it has the following properties
(d ¼ dm=2e):
P1. The root has at least two children and at most
m children.
Authorized licensed use limited to: Arulmigu Kalasalingam College of Engineering. Downloaded on February 5, 2010 at 23:16 from IEEE Xplore. Restrictions apply.
217
P2. All external nodes are at the same level.
P3. All internal nodes other than the nodes in special path
(defined below) and the root have at least d children
and at most m children.
P4. There is at most one special path.
P5. A special path (SP) is a sequence of internal nodes,
(z0 ; z1 ; . . . ; zk ), where zi is an ancestor of ziþ1 for
0  i < k, zi has at least one child and at most
d
1 children for 0  i  k, and z0 is not the root.
Fig. 3 gives an example of an NSBHO tree of order 3. The
shaded nodes are in a special path. Node z0 is the parent,
certainly an ancestor, of node z1 .
The difference between the NSBHO tree and the
standard B-tree [17] is that the NSBHO tree is not a search
tree and it allows a special path on which the nodes do not
satisfy the property of a standard B-tree node. Note that the
B-tree scheme proposed by Goshi and Ladner [8] is not a
search tree either, but the tree nodes strictly satisfy the
property of a standard B-tree node.
3.1 Height of the NSBHO Tree
Lemma 1. Let h be the height of an order-m NSBHO tree, n be
the number of external nodes, and d ¼ dm=2e.
1. mh  n  dh
1 þ 1,
2. logd ðn
1Þ þ 1  h  logm n.
Proof. We first prove the upper bound on n. Level 0 has one
node, level 1 has at most m nodes, level 2 has at most m2
nodes, . . . , level i has at most mi nodes. Hence, there are
at most mh external nodes.
Now, we prove the lower bound on n. Level 0 has one
node. We claim that level i (i > 0) has at least di
1 þ 1
nodes. We prove this claim by induction. Since the root is
never in the special path, level 1 has at least two nodes.
Assume level i
1 has at least di
2 þ 1 nodes. At most
one of them may be in the special path (Definition 1). The
nodes not in the special path have at least d children per
node. Thus, level i has at least di
1 þ 1 nodes. This
proves the lower bound on n.
The bound on h follows the bound on n. u
t
Lemma 2 gives the height of an order-m B-tree. An order-3
B-tree is the base for the height-balanced 2-3 tree
discussed in [8].
Lemma 2. Let h be the height of an order-m B-tree, n be the
number of external nodes, and d ¼ dm=2e.
1. mh  n  2dh
1 ,
2. logd ðn=2Þ þ 1  h  logm n.
Proof. It is easy to see that mh  n since each internal node
can have at most m children.
Since all the internal B-tree nodes except the root have
at least d children and the root has at least two children,
the minimum number of nodes at level 0, 1, 2, 3, . . . , h is
1; 2; 2d; 2d2 ; . . . ; 2dh
1 , respectively. Therefore, there are
at least 2dh
1 external nodes.
The bound on h follows the bound on n. u
t
218
TABLE 1
Rekeying Message Costs of the B-Tree [8]
and the NSBHO Tree
h is the height of the corresponding B-tree or the NSBHO tree, m is the
order of the tree, and d ¼ dm=2e.
From Lemmas 1 and 2, the difference between the worst-
case height of an order-m NSBHO tree and that of an order-m
B-tree is
ðlogd ðn
1Þ þ 1Þ
ðlogd ðn=2Þ þ 1Þ ¼ logd ð2ðn
1Þ=nÞ:
When n  1, logd ð2ðn
1Þ=nÞ ¼ logd 2  1. This means, in
the worst case, an NSBHO tree is at most one level taller
than a B-tree of the same order. In our experiment
(Section 5), we rarely find any height difference between
these two trees. The tree height is related to the rekeying
cost of each tree (see Table 1 for comparison).
3.2 Insert an External Node
When a new member joins the group, an external node z is
created for the new member and is inserted into the NSBHO
tree. The general idea is to create a chain of nodes with z as
the tail and then attach the head of the chain as a child of a
suitable internal node of the current NSBHO tree. The
purpose of the chain is to put z at the correct level of the
external nodes, thus the length of the chain is such that the
new external node z is at the same level as the existing
external nodes.
The key is to find a suitable insert point (internal node) such that
the resulting tree is still an NSBHO tree. When the special path
SP is not empty, a node 2 SP with the largest level is the
suitable insert point. Recall that x:level ¼ x:parent:level þ 1
and root:level ¼ 0. In Fig. 3, the special path is (z0 ; z1 ),
z0 :level ¼ 1, and z1 :level ¼ 2, thus z1 is the suitable insert
point. Fig. 4b shows the resulting tree using z1 as the insert
point. One may verify that it is an NSBHO tree. z0 can’t be
used as the insert point because, otherwise, the resulting
tree (as shown in Fig. 4a) has two special paths, (z1 ) and
(x0 ). The root can’t be used as the insert point either
because, otherwise, the resulting tree (as shown in Fig. 4c)
has two special paths, (z0 , z1 ) and (x0 , x1 ). When the special
path SP is empty, an arbitrary internal node that has fewer
than m children can be the insert point. When all the
Fig. 4. An external node z is inserted into the NSBHO tree in Fig. 3 using the insert point. (a) z0 . (b) z1 . (c) root. The resulting trees at (a) and (c) are
not NSBHO trees. The resulting tree at (b), however, is an NSBHO tree.
Authorized licensed use limited to: Arulmigu Kalasalingam College of Engineering. Downloaded on February 5, 2010 at 23:16 from IEEE Xplore. Restrictions apply.
IEEE TRANSACTIONS ON COMPUTERS, VOL. 54, NO. 2, FEBRUARY 2005
internal nodes are full (i.e., having m children each), a new
root will be created which becomes the insert point.
The algorithm for inserting an external node z is listed
in Fig. 5. If the tree is empty, z becomes the root.
Otherwise, getInsertP oint (Fig. 6) is invoked. If
getInsertP oint returns null, a new root y is created and
the current root becomes a child of the new root. Now, y
has fewer than m children. A chain of internal nodes
(x0 ; x1 ; . . . ; xl ) is created, where xi ¼ xiþ1 :parent for
0  i < l, x0 :level ¼ y:level þ 1, and xl :level ¼ h
1. The
purpose of the chain is to put z at the correct level of the
external nodes. The new external node z becomes a child of
xl and x0 becomes a child of y. In the case of y:level ¼ h
1,
there is no need to create a chain and, thus, z itself becomes
a child of y.
Fig. 6 gives the algorithm for getInsertP oint. The
algorithm returns null if there is no internal node or all
internal nodes are full. If SP is not empty, a node 2 SP with
the largest level (e.g., z1 in Fig. 3) is returned. Otherwise, a
nonfull internal node 62 SP is returned.
Special path SP can be maintained by a simple array of
size h. Adding (removing) a node to (from) SP can be done
in Oð1Þ time. Returning the node 2 SP with the largest level
is the key to making the insertion algorithm work.
Lemma 3. If the tree is an NSBHO tree of order m, it is still an
NSBHO tree of order m after inserting an external node using
the algorithm in Fig. 5.
Proof. If the tree is empty, it has one external node after
insertion. It is an NSBHO tree of order m. When
getInsertP oint returns null, either there is no internal
node or all internal nodes are full. In the former case, the
tree has only one external node and no internal nodes.
Thus, following the insertion, it has a root and two
external nodes that are the children of the root. It is an
NSBHO tree of order m. In the latter case, there is no
special path in the current tree. A new root is created and
the newly created chain (x0 ; x1 ; . . . ; xl ) becomes the only
special path. Therefore, the tree is still an NSBHO tree of
order m.
If SP is not empty, a node 2 SP with the largest level
is returned by getInsertP oint. The newly created chain
(x0 ; x1 ; . . . ; xl ) becomes the tail of the existing special
path. Since x0 becomes a child of the insert point and xi ,
0  i  l, has larger level than that of the existing node
2 SP , there is only one special path after insertion.
If SP is empty, a node 62 SP is returned. This node has
fewer than m children. The newly created chain
(x0 ; x1 ; . . . ; xl ) becomes the only special path. Apparently,
LU: A NOVEL HIGH-ORDER TREE FOR SECURE MULTICAST KEY MANAGEMENT
Fig. 5. Insert an external node z.
the choice of this node does not affect the correctness of
the algorithm. t
u
While an arbitrary nonfull internal node can serve as the
insert point when SP is empty, we may wish to balance
the number of children these internal nodes have so that
the future deletion has less chance of causing internal
nodes to become one-child deficient. We can achieve this
by assigning the internal node x 62 SP a priority,
m
x:size, and by maintaining these nodes in a max
priority queue [17]. Each operation of the priority queue
can be done in Oðlog pqueueSizeÞ, where pqueueSize (< n) is
the number of the nonfull internal nodes in the priority
queue. Notice that only the insert point has its size changed.
Time Complexity. It takes h time to create the chain
and Oðlog pqueueSizeÞ (¼ Oðlog nÞ) time to update the
priority queue. Therefore, the overall time complexity of
insertion algorithm is Oðh þ log nÞ, where n is the number
of external nodes.
3.3 Remove an External Node
No rebalancing is needed after an external node z is
removed if the parent of z is not one child short (i.e., if
z:parent is in SP , z:parent should have at least one child
and, if z:parent is not in SP , z:parent should have at least
d children). The tree rebalancing is carried out only when
z:parent is one child short. If z:parent is in SP , “one child
short” means z:parent has no children left and, thus,
z:parent can be removed, which causes z:parent:parent to
lose a child. We need to move one level up the tree and
check z:parent:parent to see whether or not rebalancing is
Fig. 6. The algorithm getInsertP oint. The level of the root is 0 and the
level of node x is the level of x:parent plus one.
Authorized licensed use limited to: Arulmigu Kalasalingam College of Engineering. Downloaded on February 5, 2010 at 23:16 from IEEE Xplore. Restrictions apply.
219
Fig. 7. Remove an external node z.
necessary there. If z:parent is not in SP , we will use the
standard B-tree rebalance technique (i.e., borrowing a child
from a sibling or merging z:parent with its sibling). If it is
possible for z:parent to borrow a child from its sibling,
rebalancing ends. Merging z:parent with its sibling causes
z:parent:parent to lose a child. Thus, we need to move one
level up and check z:parent:parent. Due to the existence of
SP , z:parent:parent may have only one child. In this case,
borrowing or merging is not possible. However, we can add
z:parent to SP without violating the NSBHO property and
thereby terminate the rebalancing.
Fig. 7 gives the algorithm for removing an external
node z. The siblings of z include all the children of z:parent
except z. The function richSiblingðzÞ returns a sibling sz of z
such that (sz 2 SP and sz:size > 1) or (sz 62 SP and
sz:size > d). However, if no such sz exists, richSiblingðzÞ
returns null.
The while loop is executed when z is an internal node, z
is not the root, and z is one child short (deficiency). If z is in
SP , “one child short” means z has no child, thus z can be
deleted (lines 8 and 9). If z is not in SP , “one child short”
means z has d
1 children. The deficiency can be
compensated for by borrowing a child from the sibling of
z (line 15) if z has a rich sibling, by merging with a sibling
(line 17) if z has at least one sibling, or by adding z into SP
(line 21) if z has no sibling. The deficiency may propagate
one level up after executing line 9 or line 17, thus we need to
move one level up to check the parent of z. In other cases,
we terminate the while loop by setting z to the root (line 15
220 IEEE TRANSACTIONS ON COMPUTERS, VOL. 54, NO. 2, FEBRUARY 2005

Fig. 8. (a) Remove the rightmost external node in Fig. 3. (b) Remove shaded node in (a). (c) Remove shaded node in (b).

and line 21). If the deficiency propagates up to the root, the b. z 62 SP . Thus, z:size ¼¼ d
1. Lines 12-22 deal
tree height is decreased by one (lines 25-26). with this case. There are two possible subcases, z
Fig. 8a is the result of removing the rightmost external either has or does not have a rich sibling.
node in Fig. 3, Fig. 8b is the result of removing the shaded b1. z has a rich sibling. Lines 14-15 deal with this
node in Fig. 8a, and Fig. 8c is the result of removing the case. A rich sibling can give z a child without
shaded node in Fig. 8b. affecting its own status (i.e., after giving z a
child, it still has at least one child if it is in SP
Lemma 4. If the tree is an NSBHO tree of order m, it is still an
and at least d children if it is not in SP ).
NSBHO tree of order m after removing an external node using Hence, removing a child from the rich sibling
the algorithm in Fig. 7. does not introduce new violations. Adding a
Proof. If z ¼¼ root (line 1), the tree has only one external child to z raises the size of z to d. Thereafter,
there are no more violations in the tree. We
node and no internal nodes. After removing z, the tree is
simply set z to the root to end the while loop.
empty and is an NSBHO tree. b2. z does not have a rich sibling. Hence, the size of
The loop invariant for the while loop in lines 5-23 is: the sibling of z is either d or 1. There are two
subcases, either pz:size > 1 or pz:size ¼¼ 1.
1. z is an internal node.
2. Property 2 of Definition 1 is not violated (i.e., all b2.1pz:size > 1. We merge a sibling of z with
external nodes are at the same level). z in line 17. After merging, the size of z is
3. If there is a violation, it is because z lost a child either d or 2d
1 and pz loses one child.
and is now one child short. Thus, z is no longer one child short and
“z is one child short” means z:size ¼¼ 1 if z is the root, recovers its status as one of the nodes
z:size ¼¼ d
1 if z 62 SP [ frootg, and z:size ¼¼ 0 if 62 SP . Notice that we did not touch other
z 2 SP . internal nodes except z, pz, and the
Initialization: sibling of z that was merged with z. If
there is a violation, it is because pz lost a
1. When line 2 is executed, the tree has at least one
child and is now one child short. The
internal node. After line 4 is executed, z points to
pointer z moves one level up in line 18.
an internal node.
b2.2pz:size ¼¼ 1 (i.e., z is the only child of
2. Lines 2-4 do not change the levels of the external
pz). Thus, pz is in SP . Adding z to SP in
nodes.
line 21 allows z to legitimately have d
1
3. Lines 2-4 remove a child from pz and do not touch
children (i.e., z is no longer one child
other internal nodes. Therefore, if there is a
short). Therefore, the violation caused by z
violation, it is because z ¼ pz (line 4) lost a child
is fixed. Adding z to SP could potentially
and is now one child short.
introduce violation of property 4. How-
Maintenance: Since the loop is entered, z 6¼ root. ever, since z is the only child of pz and pz is
Thus, pz ¼ z:parent is an internal node. There are two in SP , adding z to SP will not create a
cases, z 2 SP and z 62 SP . Note that property 2 is never different SP , but rather it will extend the
violated since the loop does not change the level of any length of the existing SP by one. There-
external node. fore, there are no more violations after line
a. z 2 SP . Thus, z:size ¼¼ 0. Lines 7-11 deal with 21 and we simply set z to the root in order
this case. Since z has no children, z is deleted in to end the while loop.
line 9 and there is no further violation due to z. pz Termination: When the loop terminates, either z ¼¼
loses a child in line 9. Lines 7-11 do not touch root or (z 6¼ root and z:size 6¼ d
1 and z:size 6¼ 0). In the
other internal nodes except z and pz. Therefore, if former case, z is the root. If there is a violation,
there is a violation after lines 7-11, it is because pz root:size ¼¼ 1 by the loop invariant. Lines 24-26 fix this
lost a child and is now one child short. After violation and do not introduce any new violations.
lines 7-11, z (¼ pz) is still an internal node. (Although the levels of external nodes are decreased by

Authorized licensed use limited to: Arulmigu Kalasalingam College of Engineering. Downloaded on February 5, 2010 at 23:16 from IEEE Xplore. Restrictions apply.
LU: A NOVEL HIGH-ORDER TREE FOR SECURE MULTICAST KEY MANAGEMENT
Fig. 9. Rekeying after inserting a new member.
one, they are still at the same level.) In the latter case,
z is an internal node, but not the root. If there is a
violation, either z:size ¼¼ d
1 or z:size ¼¼ 0 by the
loop invariant. However, this violation will not happen
since z:size 6¼ d
1 and z:size 6¼ 0. u
t (expected) if the hash table is used or in Oðlog nÞ time if the
Time Complexity. Merging two internal nodes takes
OðmÞ time. Moving a child from an internal node to another
takes OðmÞ time. At most h
1 merging and at most one
moving can occur. OðhÞ internal nodes may have their size
changed. It takes Oðlog nÞ time to update the priority queue
for each node-size change. Hence, the overall time complex-
ity of removing an external node is Oðhðm þ log nÞÞ.
4 NSBHO TREE FOR MULTICAST KEY
MANAGEMENT
4.1 Rekeying Cost for Inserting a New Member
Fig. 9 shows the rekeying for inserting a new member. The
new member is represented by the external node z and is
assigned an individual key kz . The internal node returned
by getInsertP oint is node sk9 . The chain created is (x0 , x1 ).
After inserting the external node z, the keys along the path
from the root to z need to be changed. gk is changed to gk0 ,
sk5 is changed to sk05 , and sk9 is changed to sk09 . The node x0
gets key skx0 and the node x1 gets key skx1 . Rekeying
messages include three multicast messages and five unicast
messages. The multicast messages are gkfgk ! gk0 g,
sk5 fsk5 ! sk05 g, and sk9 fsk9 ! sk09 g. The unicast message
is kz fadd gk0 ; sk05 ; sk09 ; skx0 ; skx1 g.
When a new root is created, it gets a new group key. A
multicast message is used to set the new group key and, at the
same time, to degrade the old group key to a subgroup key.
Therefore, if the insert point is at level j and the tree
height is h, the rekeying messages include a multicast
message of size j þ 1 and a unicast message of size h. Since
j < h, the worst-case rekeying cost is 2h, which only
happens when j ¼ h
1. The best-case rekeying cost is
h þ 1, which happens when a new root is created. Note that
increasing the tree order m reduces the rekeying cost since
h  logd ðn
1Þ þ 1 and d ¼ dm=2e (Lemma 1).
The improvement proposed by Canetti et al. [1] can be
applied here to reduce the unicast message cost from h to 1.
This improvement [1] makes gk0 depend on sk05 , sk05 on sk09 ,
sk09 on skx0 , and skx0 on skx1 . One can compute skx0 from skx1 ,
sk09 from skx0 , and so on. However, the reverse is not true (i.e.,
one can’t compute skx1 from skx0 , skx0 from sk09 , and so on).
Authorized licensed use limited to: Arulmigu Kalasalingam College of Engineering. Downloaded on February 5, 2010 at 23:16 from IEEE Xplore. Restrictions apply.
221
Fig. 10. Merging two internal nodes (d ¼ 3). The rekeying message cost
is d.
Therefore, a unicast message containing skx1 and x1 :level is
enough for z to generate the keys along the path. The same
improvement can be applied to the B-tree scheme [8].
4.2 Rekeying Cost for Deleting an Existing Member
The server maintains a list of pairs in the form of (member
ID, external node). This list can be maintained by a hash
table or a binary search tree. When a member leaves, the
server obtains the corresponding external node in Oð1Þ time
binary search tree is used. The external node will be deleted
using the algorithm in Fig. 7.
Tree reconstruction following the deletion of an external
node may merge an internal node with its sibling and/or
move a child from an internal node to its sibling. When no
tree reconstruction is needed, the rekeying cost is the sum of
the size of the internal nodes along the path from the root to
the deleted external node. Therefore, the worst-case rekey-
ing cost is mh
1, when all internal nodes along the path
have m children before the deletion of the external node.
In Fig. 7, merging two nodes (line 17) happens when
z 62 SP , z has d
1 children, and no sibling of z can give z a
child. For example, in Fig. 10, node z merges with its
sibling y. To inform all members in the subtree rooted at y of
the new key sk0z , we can use sky fsky ! sk0z g since the
deleted member is in the subtree rooted at z and does not
know sky . However, we need two messages, sk2 fskz ! sk0z g
and sk3 fskz ! sk0z g, one for each child of z, to inform the
members in the subtree rooted at z of the new key sk0z .
Therefore, the rekeying cost of merging two nodes is d,
including d
1 multicast messages for the children of z
and one multicast message for y.
In Fig. 7, moving a child from a rich sibling of z to z
(line 15) occurs when z 62 SP , z has d
1 children, and there
is a rich sibling of z who can give z a child. Such siblings
include the sibling sz such that (sz 2 SP and sz:size > 1)
and the sibling sz such that (sz 62 SP and sz:size > d). For
example, in Fig. 11, z gets a child from y. Key sky needs to be
changed since the subgroup sk4 has become a child of z and
the members in the subgroup sk4 know sky . In order to
inform the members in subgroups sk5 , sk6 , and sk7 of the
new key sk0y , three multicast messages are needed
(sk5 fsky ! sk0y g, sk6 fsky ! sk0y g, and sk7 fsky ! sk0y g). Note
Fig. 11. Move one child from y to z (d ¼ 3). The rekeying message cost
is d
1 þ y:size.
222 IEEE TRANSACTIONS ON COMPUTERS, VOL. 54, NO. 2, FEBRUARY 2005

that we can’t use sky fsky ! sk0y g since the members in

subgroup sk4 can also decrypt this message. To inform sk2 ,
sk3 , and sk4 of the new key sk0z , three multicast messages
(sk2 fskz ! sk0z g, sk3 fskz ! sk0z g, and sk4 fskz ! sk0z g) are
needed. Therefore, the rekeying message cost of moving one
child is d
1 þ y:size. We know that y:size  m. In order to
reduce the rekeying cost, we should choose the rich sibling
who has the smallest number of children.
When the root is one child short (Lines 24-27 in Fig. 7),
the only child of the root becomes the new root and the old
root is deleted. The key at the new root is promoted to the
group key and the old group key is deleted by default.
The rekeying cost of merging two nodes is d ¼ dm=2e,
while the rekeying cost of changing the subgroup key at a
size-m node is m. Thus, merging two nodes does not Fig. 12. Height difference between a height-balanced 2-3 tree and an
order-3 NSBHO tree. Ten thousand random deletions. Initial tree size
contribute to the worst-case rekeying cost. The worst-case
10,000.
rekeying cost occurs when the parent of the external node
for the leaving member is one child short and all of its
is very general and can be applied to many, if not all, of the
siblings have m children (thus, this parent borrows a child
hierarchical key-tree schemes.
from its sibling, which costs d
1 þ m messages) and the
rest of the internal nodes along the path from the root to this
external node have m children (thus, changing one 5 EXPERIMENTAL RESULTS
subgroup key costs m message). Therefore, the worst-cast We implemented the NSBHO tree in C++ and compared it
rekeying cost for a member leaving is d
1 þ mh. The with the B-tree scheme proposed by Goshi and Ladner [8].2
argument is also true for the B-tree scheme [8]. The height-balanced 2-3 tree is an order-3 B-tree. It is shown
The best-case rekeying cost is one. It happens when the in [8] that the height-balanced 2-3 tree has the best
root has two children and all of the other internal nodes performance among the tree balancing schemes tested.
along the path from the root to the external node for the First, we compared the height of an order-m NSBHO tree
leaving member have one child each. These internal nodes and an order-m B-tree. The insert point for the new member
will be deleted, the root will lose one child, the remaining in the B-Tree is chosen to minimize the increase of tree
child of the root will become the new root, and the weight [8]. Note that the insert point in the B-Tree is the
subgroup key at this child will be promoted to the group parent of the external node, while the insert point in the
key. In this case, only one multicast message is needed to set NSBHO tree can be any internal node. Fig. 12 shows the
the new group key. For the B-tree scheme [8], the best-case height difference between an order-3 B-tree and an order-3
rekeying cost is dðh
1Þ þ 2 since the size of the root is at NSBHO tree over each of the 10,000 random deletions on a
least two and the size of its other internal nodes is at least d. tree of the initial size 10,000. The maximum height
The improvement proposed by Canetti et al. [1] can also difference is one and this rarely actually occurs. In other
be applied here to reduce the number of multicast messages experiments, such as 10,000 insertions and random inser-
by h
1. The keys along the path from the root to the parent tions (50 percent)/deletions (50 percent) on the trees of
of the removed member have dependency as described in different orders, we also rarely found any height difference
Section 4.1. The same improvement can be applied to the (similar to Fig. 12 with jhBtree
hNSBHOtree j  1).
B-tree scheme [8], too. Fig. 13 shows the rekeying costs of an order-3 B-tree (i.e.,
4.3 Comparison with the B-Tree Scheme height-balanced 2-3 tree), an order-4 B-tree, an order-3
NSBHO tree, and an order-4 NSBHO tree. The initial tree
Table 1 lists the worst-case and the best-case rekeying costs
size is 10,000. There are 100,000 operations. The operation
of the B-tree [8] and the NSBHO tree. The NSBHO tree
involves either inserting a new member or deleting an
performs better in every aspect due to the novel tree-
existing member. The operations are randomly generated.
balancing strategy. One may argue that an NSBHO tree may
The probability of inserting a new member is 50 percent. In
be one level taller in the worst case than a B-tree of the same
Fig. 13a, each point represents the max cost over 2,000 op-
order, thus the worst-case rekeying cost of an NSBHO tree
erations. In Fig. 13b, each point represents the average cost
for member leaving is higher than that of a B-tree by
over 2,000 operations. Fig. 14 shows the rekeying costs for
m messages (m ¼ 3 for order-3 B-tree). However, Lemmas 1
each of the first 50 operations. In Fig. 14, the NSBHO tree
and 2 show that the height difference is at most one in the
always performs better than the B-tree of the same order. As
worst case and the experiments (Section 5) show that height
we expected, the NSBHO-tree has better average perfor-
differences are very rare and B-trees are taller about
mance than the B-tree (Fig. 13b). For the worst-case
50 percent of the time when there is a height difference.
rekeying cost, the NSBHO-tree is far superior than the B-
As discussed before, the rekeying costs in Table 1 can be
tree. In Fig. 13a, the worst-case rekeying cost of an order-3
further reduced by h
1 (except for the best-case member-
removing cost of an NSBHO tree) when the improvement 2. We would like to thank Goshi and Ladner for providing their source
proposed by Canetti et al. [1] is applied. This improvement code.

Authorized licensed use limited to: Arulmigu Kalasalingam College of Engineering. Downloaded on February 5, 2010 at 23:16 from IEEE Xplore. Restrictions apply.
LU: A NOVEL HIGH-ORDER TREE FOR SECURE MULTICAST KEY MANAGEMENT 223

Fig. 13. Rekeying message costs for 100,000 random insertions (50 percent)/deletions (50 percent). Initial tree size is 10,000. Each point represents
the (a) max/(b) average cost over 2,000 operations. Btree3 stands for order-3 B-tree.

Fig. 14. Rekeying message costs for the first 50 operations in Fig. 13. (a) Comparison between an order-3 B-tree and an order-3 NSBHO tree.
(b) Comparison between an order-4 B-tree and an order-4 NSBHO tree.

B-tree is about 52, while that of an order-3 NSBHO tree is
about 22. The worst-case rekeying cost of an order-4 B-tree
is 50, while that of an order-4 NSBHO tree is only 18.
6 CONCLUSION
The hierarchical key-tree approach is an efficient way to
achieve logarithmic rekeying costs for secure multicast key
management given that the underlying tree is balanced. We
have developed an NSBHO (Non-Split Balancing High-
Order) tree. Unlike the B-tree scheme [8], our NSBHO tree
does not use node splitting to balance the tree. As a result,
the worst-case rekeying cost of our NSBHO tree for a new
member joining is 2h, while that of the B-tree scheme is
ðm þ 2Þh, where h is the corresponding tree height and m is
the order of the tree (an order-3 B-tree is a height-balanced
2-3 tree, as discussed in [8]). For member leaving, the B-tree
scheme and our NSBHO-tree scheme have the same worst-
case rekeying cost (dm=2e
1 þ mh). Our experiments
confirm that the NSBHO-tree is superior to the B-tree in
terms of the worst-case rekeying performance. In addition,
it has better average-case rekeying performance. Goshi and
Ladner [8] show that the height-balanced 2-3 tree has the
performance advantage over other balancing strategies.
REFERENCES
[1] R. Canetti, J. Garay, G. Itkis, D. Micciancio, M. Naor, and B.
Pinkas, “Multicast Security: A Taxonomy and Efficient Authenti-
cation,” Proc. IEEE Infocom, 1999.
[2] R. Canetti, T. Malkin, and K. Nissim, “Efficient Communication-
Storage Tradeoffs for Multicast Encryption,” Proc. Advances in
Cryptology—EUROCRYPT 1999, 1999

Authorized licensed use limited to: Arulmigu Kalasalingam College of Engineering. Downloaded on February 5, 2010 at 23:16 from IEEE Xplore. Restrictions apply.
224 IEEE TRANSACTIONS ON COMPUTERS, VOL. 54, NO. 2, FEBRUARY 2005

[3] G. Caronni, M. Waldvogel, D. Sun, and B. Plattner, “Efficient Haibin Lu received the BE and ME degrees in
Security for Large and Dynamic Multicast Groups,” Proc. IEEE electronic engineering from Tsinghua University,
Seventh Workshop Enabling Technologies: Infrastructure for Collabora- Beijing, China, in 1997 and 1999, respectively,
tive Enterprises, 1998. and the PhD degree in computer engineering
[4] I. Chang, R. Engel, D. Kandlur, D. Pendarakis, and D. Saha, “Key from the University of Florida in 2003. He joined
Management for Secure Internet Multicast Using Boolean Func- the faculty of the Department of Computer
tion Minimization Techniques,” Proc. IEEE Infocomm, 1999. Science, University of Missouri-Columbia, as
[5] W. Chen and L.R. Dondeti, “Performance Comparison of Stateful an assistant professor in 2003. His primary
and Stateless Group Rekeying Algorithms,” Proc. Fourth Int’l research focus lies in algorithmic aspects of
Workshop Networked Group Comm. (NGC ’02), 2002. computer network and multimedia communica-
[6] A.M. Eskicioglu, “Multimedia Security in Group Communica- tion. He is a member of the IEEE.
tions: Recent Progress in Key Management, Authentication, and
Watermarking,” ACM Multimedia Systems J., special issue on
multimedia security, pp. 239-248, Sept. 2003.
[7] A. Fiat and M. Naor, “Broadcast Encryption,” Proc. Advances in
Cryptology—CRYPTO ’92, pp. 257-270, 1994.
[8] J. Goshi and R.E. Ladner, “Algorithms for Dynamic Multicast Key . For more information on this or any other computing topic,
Distribution Trees,” Proc. ACM Symp. Principles of Distributed please visit our Digital Library at www.computer.org/publications/dlib.
Computing (PODC 2003), 2003.
[9] H. Harney and C. Muckenhirn, “Group Key Management
Protocol (GKMP) Specification,” RFC 2093, July 1997.
[10] H. Harney and C. Muckenhirn, “Group Key Management
Protocol (GKMP) Architecture,” RFC 2094, July 1997.
[11] X. Li, Y. Yang, M.G. Gouda, and S.S. Lam, “Batch Rekeying For
Secure Group Communications,” Proc. 10th Int’l World Wide Web
Conf., 2001.
[12] S. Mittra, “Iolus: A Framework for Scalable Secure Multicasting,”
Proc. ACM SIGCOMM, 1997.
[13] M. Moyer, J. Rao, and P. Rohatgi, “Maintaining Balanced Key
Trees for Secure Multicast,” Internet draft, draft-irtf-smug-key-
tree-balance-00.txt, June 1999,
[14] M. Moyer, J. Rao, and P. Rohatgi, “A Survey of Security Issues in
Multicast Communications,” IEEE Network, Nov./Dec. 1999.
[15] S. Paul, Multicast on the Internet and Its Applications. Kluwer
Academic, 1998.
[16] O. Rodeh, K.P. Birman, and D. Dolev, “Using AVL Trees for Fault
Tolerant Group Key Management,” Int’l J. Information Security,
pp. 84-99, Nov. 2001.
[17] S. Sahni, Data Structures, Algorithms, and Applications in Java.
McGraw-Hill, 2000.
[18] S. Setia, S. Koussih, S. Jajodia, and E. Harder, “Kronos: A Scalable
Group Re-Keying Approach for Secure Multicast,” Proc. IEEE
Symp. Security and Privacy, 2000.
[19] A.T. Sherman and D.A. McGrew, “Key Establishment in Large
Dynamic Groups Using One-Way Function Trees,” IEEE Trans.
Software Eng., vol. 29, no. 5, pp. 444-458, May 2003.
[20] C. Shields and J.J. Garcia-Luna-Aceves fclay, “KHIP—A Scalable
Protocol for Secure Multicast Routing,” Proc. ACM SIGCOMM,
1999.
[21] J. Snoeyink, S. Suri, and G. Varghese, “A Lower Bound for
Multicast Key Distribution,” Proc. IEEE Infocom, 2001.
[22] M. Steiner, G. Tsudik, and M. Waidner, “Diffie-Hellman Key
Distribution Extended to Group Communication,” Proc. Third
ACM Conf. Computer and Comm. Security, 1996.
[23] D. Wallner, E. Harder, and R. Agee, “Key Management for
Multicast: Issues and Architectures,” IETF, RFC 2627, June 1999.
[24] C.K. Wong, M. Gouda, and S.S. Lam, “Secure Group Commu-
nication Using Key Graphs,” IEEE/ACM Trans. Networking, vol. 8,
no. 1, pp. 16-30, Feb. 2000.
[25] Y.R. Yang, X.S. Li, X.R. Zhang, and S.S. Lam, “Reliable Group
Rekeying: A Performance Analysis,” Proc. ACM SIGCOMM, 2001.

Authorized licensed use limited to: Arulmigu Kalasalingam College of Engineering. Downloaded on February 5, 2010 at 23:16 from IEEE Xplore. Restrictions apply.