This document proposes an efficient key management scheme (KTR) for wireless broadcast services that supports secure access control. KTR has three main advantages: 1) It supports all subscription activities like joining, leaving and changing programs. 2) A user only needs one set of keys for all subscribed programs instead of separate keys for each program. 3) KTR identifies the minimum set of keys that need to be changed when a user's subscription changes to minimize rekey costs. Simulations show KTR can save about 45% of communication overhead and 50% of decryption costs compared to logical key hierarchy approaches.

1. 1
KTR: an Efficient Key Management Scheme
for Secure Data Access Control
in Wireless Broadcast Services
Qijun Gu, Peng Liu, Wang-Chien Lee, and Chao-Hsien Chu
Abstract—Wireless broadcast is an effective approach to dis-
seminate data to a number of users. To provide secure access
to data in wireless broadcast services, symmetric key-based
encryption is used to ensure that only users who own the valid
keys can decrypt the data. Regarding various subscriptions, an
efficient key management to distribute and change keys is in great
demand for access control in broadcast services. In this paper, we
propose an efficient key management scheme (namely KTR) to
handle key distribution with regarding to complex subscription
Fig. 1. A wireless data broadcast system
options and user activities. KTR has the following advantages.
First, it supports all subscription activities in wireless broadcast
services. Second, in KTR, a user only needs to hold one set of
keys for all subscribed programs, instead of separate sets of keys dissemination. Data is broadcast periodically so that users can
for each program. Third, KTR identifies the minimum set of keys recover lost or missed data items. The uplink channels, which
that must be changed to ensure broadcast security and minimize have limited bandwidth, are reserved for occasional uses to
the rekey cost. Our simulations show that KTR can save about
45% of communication overhead in the broadcast channel and dynamically change subscriptions.
about 50% of decryption cost for each user, compared with logical In broadcast services, the basic data unit is data item, such
key hierarchy based approaches. as a piece of news or a stock price. Data items are grouped
Index Terms—Wireless broadcast, key management, access into programs and a user specifies which programs he would
control, key hierarchy, secure group communication, key dis- like to access. Typical programs could be weather, news, stock
tribution quotes, etc. For simplicity, we assume that each program
covers a set of data items, and programs are exclusively
complete. A user may subscribe to one or more programs. The
I. I NTRODUCTION
set of subscribed programs is called the user’s subscription.
With the ever growing popularity of smart mobile devices Users can subscribe via Internet or uplink channels to specify
along with the rapid advent of wireless technology, there has the programs that they are interested in receiving.
been an increasing interest in wireless data services among Previous studies on wireless data broadcast services have
both industrial and academic communities in recent years. mainly focused on performance issues such as reducing data
Among various approaches, broadcast allows a very efficient access latency and conserving battery power of mobile devices.
usage of the scarce wireless bandwidth, because it allows Unfortunately, the critical security requirements of this type of
simultaneous access by an arbitrary number of mobile clients broadcast service have not yet been addressed, i.e. broadcast
[1]. Wireless data broadcast services have been available service providers need to ensure backward and forward secrecy
as commercial products for many years. In particular, the [2], [3] with respect to membership dynamics. In the wireless
announcement of the MSN Direct Service (direct.msn.com) broadcast environment, any user can monitor the broadcast
has further highlighted the industrial interest in and feasibility channel and record the broadcast data. If the data is not
of utilizing broadcast for wireless data services. encrypted, the content is open to the public and anyone can
A wireless data broadcast system consists of three compo- access the data. In addition, a user may only subscribe to a
nents as depicted in Figure 1: (1) the broadcast server; (2) the few programs. If data in other programs are not encrypted,
mobile devices; and (3) the communication mechanism. The the user can obtain data beyond his subscription privilege.
server broadcasts data on air. A user’s mobile device receives Hence, access control should be enforced via encrypting data
the broadcast information, and filters the subscribed data in a proper way so that only subscribing users can access the
according to user’s queries and privileges. The specialty of the broadcast data, and subscribing users can only access the data
broadcast system is that (a) the server determines the schedule to which they subscribe.
to broadcast all data on air, and (b) users’ mobile devices Symmetric-key-based encryption is a natural choice for
listen to the broadcast channel but only retrieve data (filter data ensuring secure data dissemination and access. The broadcast
out) based on users’ queries. The communication mechanism data can be encrypted so that only those users who own
includes wireless broadcast channels and (optional) uplink valid keys can decrypt them. Thus, the decryption keys can
channels. Broadcast channel is the main mechanism for data be used as an effective means for access control in wireless

2. 2
data broadcast services. For example, each program has one security can be ensured. In this way, rekey cost can be reduced
unique key to encrypt the data items. The key is issued to and fewer users will be affected. Therefore, we propose a
the user who is authorized to receive and decrypt the data new key management scheme, namely key tree reuse (KTR),
items. If a user subscribes to multiple programs, it needs an based on two important observations: (1) users who subscribe
encryption key for each program. Since a user only has keys to multiple programs can be captured by a shared key tree,
for his subscription, he cannot decrypt broadcast data and and (2) old keys can be reused to save rekey cost without
rekey messages designated to other users. At the same time, compromising security. KTR has two components: shared
a data item can be decrypted by an arbitrary number of users key tree and shared key management, and its contribution
who subscribe to it. This allows many users to receive the includes the following aspects.
data at the same time and addresses the scalability problem, Contributions. First, the proposed scheme takes advantage
or request lost or missed keys. of a fact in broadcast services: many users subscribe to
Nevertheless, when a user subscribes/unsubscribes to a multiple programs simultaneously. In other words, programs
program, the encryption key needs to be changed to ensure overlap with each other in terms of users. Because existing
that the user can only access the data in his subscription approaches manage keys by separating programs, they turn to
period. Consequently, a critical issue remains, i.e. how can be demanding for the users who subscribe to many programs.
we efficiently manage keys when a user joins/leaves/changes Hence, this study contributes to the literature a new scheme
the service without compromising security and interrupting (namely KTR) to better support subscriptions of multiple
the operations of other users? Regarding unique features of programs by exploiting the overlapping among programs. KTR
broadcast services, we are interested in new key management let multiple programs share the same set of keys for the users
schemes that can simultaneously provide security, efficiency who subscribe to these programs. KTR thus inherently enables
and flexibility. A broadcast service generally provides many users to handle fewer keys and reduces the demands of storage
programs; at the same time, users may like to subscribe to and processing power on resource-limited mobile devices.
an arbitrary set of programs. We envision that a user should Second, since multiple programs are allowed to share the
be able to flexibly subscribe/unsubscribe to any program same set of keys, a critical issue is how to manage shared keys
of interests and make changes to his subscription at any efficiently and securely. We find that when keys need to be
time. Hence, in addition to security and efficiency, flexibility distributed to a user, it is unnecessary to change all of them. In
that a user can customize his subscription at anytime is an many circumstances, when a user subscribes to new programs
indispensable feature of key management in broadcast services or unsubscribes to some programs, a large portion of keys
to support user subscriptions. that the user will hold in his new subscription can be reused
Two categories of key management schemes in the literature without compromising security. KTR is a novel approach for
may be applied in broadcast services: (1) logic key hierarchy determining which keys need to be changed and for finding the
(LKH) based techniques [2]–[9] proposed for multicast ser- minimum number of keys that must be changed. Hence, KTR
vices ; and (2) broadcast encryption techniques [10]–[16] in efficiently handles the rekey of the shared keys and minimizes
current broadcast services (such as satellite TV). We notice the rekey costs associated with possible subscriptions. Our
that current broadcast encryption techniques, including BISS simulations show that critical keys can be employed in logical
[17], Digicipher [18], Irdeto [19], Nagravision [20], Viaccess key hierarchy schemes [2], [5] to improve their performance.
[21], and VideoGuard [22], cannot in fact support flexibility. The rest of the paper is organized as follows. In Section
They normally require users to possess decryption boxes to II, we present related works on group key management. In
receive the subscribed programs, and the broadcast services Section III, the first component of KTR is described that fully
can only provide to users a few packages, each of which utilizes the service structure to reduce the number of keys.
includes a fixed set of programs (TV channels). Users cannot In Section IV, the second component of KTR is presented to
select individual programs within a package. If a user wants reduce rekey cost when updating and distributing shared keys.
to change his subscription, the user needs to request another In Section V, we present the results of simulations to illustrate
decryption box that can decrypt the subscribed programs. the performance improvements in KTR. Finally, we conclude
Hence, in this paper, we will focus on adapting more flexible in Section VI.
LKH-based techniques.
Nevertheless, directly applying LKH in broadcast services II. R ELATED W ORKS ON K EY M ANAGEMENT
is not the most efficient approach. In broadcast services, a
program is equivalent to a multicast group, and users who A. Logical Key Hierarchy
subscribe to one program form a group. Intuitively, we could Secure key management for wireless broadcast is closely
manage a separate set of keys for each program, and ask a user related to secure group key management in networking [4].
to hold m sets of keys for his subscribed m programs. This Logical key hierarchy (LKH) is proposed in [2], [5] that uses
straightforward approach is inefficient for users subscribing a key tree (depicted in Figure 2) for each group of users who
to many programs. If users could use the same set of keys subscribe the same program. The root (top node) of the tree
for multiple programs, there would be fewer requirements is the data encryption key (DEK) of the program. Each leaf
for users to handle keys. Furthermore, when a user changes (bottom node) in the tree represents an individual key (IDK)
subscription, we argue that it is unnecessary to change keys for of a user that is only shared between the system and the user.
the programs to which the user is still subscribing, as long as Other keys in the tree, namely key distribution keys (KDKs),

3. 3
Program g1
DEK k1
keys need be changed in stead of how keys are generated.
[6] proposes a combination of key tree and Diffie-Hellman
k2 k3
key exchange to provide a simple and fault-tolerant key
KDKs
agreement for collaborative groups. [23] reduces the number
k4 k5 k6 k7
of rekey messages, while [9], [25] improve the reliability of
rekey management. Balanced and unbalanced key trees are
ku1 ku2 ku3 ku4 ku5 ku6 ku7 ku8 discussed in [5] and [26]. Periodic group re-keying is studied
Users u1 u2 u3 u4 u5 u6 u7 u8 in [7], [8] to reduce the rekey cost for groups with frequent
joins and leaves. Issues on how to maintain a key tree and how
Fig. 2. Logical key hierarchy to efficiently place encrypted keys in multicast rekey packets
are studied in [8], [26]. Moreover, the performance of LKH is
thoroughly studied [3], [8].
are used to encrypt new DEKs and KDKs. A user only knows
the keys along the path from the leaf of the user to the root
of the key tree. B. Broadcast Encryption
When a user joins or leaves the group, the server needs to There are some other key management schemes in the
change and broadcast the corresponding new keys, and this literature for multicast and broadcast services. [10] used
operation is called rekey, and the broadcast message of new arbitrarily revealed key sequences to do scalable multicast
keys is called rekey message. In our system, data and rekey key management without any overhead on joins/leaves. [11]
messages are broadcast in the same broadcast channel to the proposed two schemes that insert an index head into packets
users. Assume user u1 leaves the group (in Figure 2). The for decryption. However, both of them require pre-planned
server needs to change k4 , k2 and k1 so that u1 will no longer subscription, which contradicts the fact that in pervasive com-
decrypt any data for this group, which is encrypted by k1. The puting and air data access a user may change subscriptions at
rekey message is any moment. In addition, [11] only supports a limited combi-
′ ′ ′ ′ ′
{k4 }ku2 , {k2 }k4 , {k2 }k5 , {k1 }k2 , {k1 }k3
′ ′ nation of programs. [13] proposed a scheme to yield maximal
resilience against arbitrary coalitions of non-privileged users.
′ ′ ′
where ki is the new key of ki and {ki }kj means ki is encrypted However, the size (entropy) of its broadcast key message is
by kj . When u2 receives this message, u2 first decrypts large, at least O(n) [12]. Zero-message scheme [14], [15] does
′ ′
{k4 }ku2 based on his individual key ku2 to obtain k4 , then not require the broadcast server to disseminate any message in
′ ′ ′ ′
uses k4 to decrypt {k2 }k4 and so on to obtain k2 and k1 .
′
order to generate a common key. But it is only resilient against
Similarly, other users can obtain the new keys in their own coalitions of k non-privileged users, and requires every user
paths. It is obvious u1 cannot obtain any new keys from this to store O(klog2 (k)log2 (n)) keys. Naor et al. [16] proposed
message, and thus the broadcast data in the future will not be a stateless scheme to facilitate group members to obtain up-
decrypted by u1 . to-date session keys even if they miss some previous key
Now assume u1 joins the group, and the server needs to distribution messages. Although this scheme is more efficient
change k4 , k2 and k1 so that u1 cannot use the old keys to than LKH in rekey operations, it mainly handles revocation
decrypt old broadcast data. Note that u1 may have already when a user stops subscription. It does not efficiently support
eavesdropped on some broadcast data before he joined the joins, which are crucial in our system. Finally, [24], [27] pro-
group. If the server gives u1 the old keys, u1 can decrypt the posed self-healing approaches for group members to recover
eavesdropped broadcast data. The rekey message is the session keys by combining information from previous key
′ ′ ′ ′ ′ ′
{k4 }ku1 , {k2 }ku1 , {k1 }ku1 , {k4 }k4 , {k2 }k2 , {k1 }k1 distribution information.
Compared with LKH-based approaches, key management
The first three components are for u1 to use his individual key schemes in broadcast encryption are less flexible regarding
to decrypt the new keys, and the last three are for all existing possible subscriptions. Conforming to the current practice
users to use their old keys to decrypt the new keys. In this described in RFC2627 [2], we select binary trees to present
way, u1 will not obtain any old key. our scheme. Note that our scheme does not require binary trees
LKH is an efficient and secure key management for multi- and can be applied in trees of other degrees.
cast services in that each user only needs to hold O(log2 (n))
keys for the user’s group, and the size of a rekey message
III. S HARED K EY S TRUCTURE
is also O(log2 (n)), where n is the number of group users.
It is also a flexible key management approach that allows a Directly applying LKH is not efficient in broadcast services.
user to join and leave the multicast group at any time. Many We use a shared key structure to address the key management.
variations of LKH have been proposed. Because LKH simply In the following, we describe how a shared key structure is
uses independent keys, researchers developed several other applied and then raise the security and efficiency problems of
approaches [23], [24] that generate new keys by exploiting this scheme. We then present a novel shared key management
the relation between child and parent keys or the relation in Section IV that ensures security and minimizes rekey
between old and new keys. Our scheme is complementary to cost, and also address major issues when applying KTR in
these schemes, since our scheme mainly examines whether a broadcast server.

4. 4
Programs g1 g2 g1 g2 programs g1 g2 g3
DEK kg1 kg2 kg1 kg2 kg1 kg2 kg3 DEKs
root graph
kr1 kr4 kr2 kr6 kr5 kr3
KDK
KDKs
knL knJ
ku1 ku1 ku2 ku1 ku2 trees
u1 u1 u2 kc
Users u1 u2
kus
(a) No Share (b) Share tr1 tr4 tr2 tr6 tr5 tr3
users us us
leave shift join
Fig. 3. Shared key tree
Fig. 4. Key forest
A. Key Forest programs g1 g2 g3 g1 g2 g3
To address scalability and flexibility in key management, kr1 kr2 kr3 kr1 kr2 kr3 DEKs
LKH is used as the basis of our scheme. An intuitive solution root graph
is to use a key tree for each program as shown in Figure
3(a). However, when user u1 subscribes to two programs k1 k2 k3 k4 k5 k1 k2 k3 k4 k5 KDKs
simultaneously, he needs to manage two sets of keys in both trees
trees which is not very efficient (see Figure 3(a)). Hence,
shared key tree (SKT) is proposed to reduce this cost in
Fig. 5. Multi-layer root graph
key management. As shown in Figure 3(b), we let the two
programs share the same sub key tree as represented by the
gray triangle. We regroup users so that users subscribing to
Property 3.3: Each user belongs only to one tree in the key
both programs only need to manage keys in the gray triangle.
forest, and his individual key is the leaf node of the tree.
The advantage of shared key tree is clear: any user subscribing
to both g1 and g2 only needs to manage one set of keys for both
programs. Moreover, when a user joins or leaves a tree shared B. Root Graph
by multiple programs, the encryption and communication cost The root graph in Figure 4 depicts how programs share
for rekey operations can be significantly less than conventional keys. Since m programs could generate 2m − 1 different
LKH approaches. subscriptions, such a two-layer structure in fact brings two
In this study, shared keys are modeled as a key forest (see major problems in terms of rekey overheads when the number
Figure 4), in which all keys form a directed and acyclic graph. of programs is large.
The top keys in the forest are the DEKs of the programs. First, a program may be included in many subscriptions,
All other keys (KDKs) form trees. Users are placed in trees which means the DEK of the program is connected with many
according to their subscriptions. A tree represents not only trees. Assume the DEK is connected with n trees. When a user
a unique subscription, but also a group of users having this stops subscribing the program, the DEK needs to be updated
subscription. Since a subscription is a set of programs, the and distributed to users in n trees. Because the new DEK is
root of the subscription’s tree is connected to the DEKs of encrypted with the roots of the n trees in rekey, O(n) rekey
the programs belonging to the subscription. As keys in a tree items are generated. Obviously, if n is large, a leave event
are shared by the programs, a user only needs to handle the results in a huge rekey message. For example, in Figure 5(a),
keys in the tree and the DEKs of the connected programs. For 3 programs are included in 5 different subscriptions. Program
example, in Figure 4, since tr4 represents a subscription of g1 g1 ’s DEK kg1 is connected with 4 roots kr1 , kr2 kr3 and kr5 .
and g2 , its root kr4 is connected to both kg1 and kg2 . The keys Hence, when kg1 is updated due to a leave event, 4 rekey items
in tr4 is shared by both g1 and g2 . A user us in tr4 subscribes are needed.
g1 and g2 and needs to handle keys in the path from his leaf To solve this problem, we use a multi-layer structure to
node to the DEKs of the subscribed programs: kus , knL , kr4 , connect the DEK with the roots of the shared trees. As in
kg1 and kg2 . Finally, kg1 , kg2 and kg3 are DEKs to encrypt Figure 5(b), kg1 is connected (bold lines) with kr1 , kr2 kr3
broadcast data, and all other keys are KDKs. and kr5 via two intermediate key nodes (gray circles). Such
In order to ensure that a user will not pay for subscribed a multi-layer structure inherently exploits the advantages of
programs multiple times, the key forest obviously should have LKH. For a leave event, the number of rekey items in the
the following properties, which are guaranteed in any directed root graph is reduced to O(log2 (n)). Note that, for different
and acyclic graph. programs, the number of intermediate nodes and the number
Property 3.1: Only one path exists by following the upward of layers may be different, which is obviously determined by
links from the root of a tree trs to the DEKs of the programs the number of trees to which the program is connected. In
that share trs ; Figure 5, program 2 is connected with 3 trees, and thus 1
Property 3.2: Only one path exists by following the upward node is needed. No node is needed for program 3, because it
links from any leaf node in a tree to the root; is only connected with 2 trees.

5. 5
TABLE I
Second, a subscription is not a conventional plan that a R EKEY OPERATIONS
broadcast service provides, because the subscribed programs
of a plan normally cannot be changed by a user. In this paper, Tree Program oriented events
users are able to customize the selection of programs in their Join Assume a user has not subscribed to any program.
subscriptions. Thereby, a broadcast service could easily have a tree • He subscribes to one or multiple programs.
a large number of different subscriptions. For example, even Leave Assume a user has subscribed to several programs.
if a service provides only 30 programs that is a small number a tree • He unsubscribes to all current programs.
in many broadcast services, there could be 230 = 1 billion Shift Assume a user has subscribed to several programs.
different subscriptions, which is much larger than the number among • He subscribes to one or a few more programs.
of users. Hence, managing keys for all possible subscriptions trees • He unsubscribes to a part of the current programs.
would overload the server. Now, assume the service has n • He changes a part of the current programs.
users and 2m ≫ n. Although 2m − 1 different subscriptions
exist, at most n subscriptions are valid, since the number of
valid subscriptions cannot be more than the number of users. ′ ′
approach to encrypt a new key ki in a rekey item {ki }kj . If
Hence, this problem can be easily solved by letting the server ′ ′ ′
ki is in an enroll path, kj is the old ki , i.e. {ki }kj ≡ {ki }ki .
only manage the valid subscriptions that have at least one user. ′ ′
If ki is in a leave path, kj is a child key of ki . Readers can
Assuming n users are distributed to e trees (e ≤ n), and refer to [2], [5] for examples of rekey packets.
each tree is shared by d programs on average (d ≥ 1), then Although LKH changes all keys in leave and enroll paths,
each tree would have n users, and each program would have
e KTR takes different rekey operations for leave path and enroll
ed
m trees. As discussed in Section V-A, KTR requires that paths: keys in a leave path are changed as in LKH, while only
the broadcast server manage O((2 n − 1)e + ( ed − 1)m) =
e m a few keys in an enroll path are changed as long as security
O(2n − e + ed − m) keys. In the worst case where e = n, is ensured. In addition, KTR identifies an enroll path with the
the server needs to manage only O(n(1 + d) − m) keys. In minimum number of must-be-changed keys to reduce rekey
contrast, LKH requires the server to manage O(2nd−m) keys. cost without compromising security. The detailed approach is
Obviously, KTR allows the server to manage much fewer keys presented in Section IV.
than conventional LKH-based approaches.
D. Challenges in Shared Key Management
C. Rekey Operations If keys are shared by multiple programs, it is not always
In this study, we consider user activities of cost saving, especially when a user shifts to a new tree where
joining/leaving/shifting among trees, instead of some previously subscribed programs are still subscribed to
joining/quitting/changing among programs. Table I lists by the user. Consider the example in Figure 4 where us shifts
the mapping between tree-oriented operations and the from tr4 to tr6 . Apparently, g1 and g2 are still subscribed to
corresponding program-oriented user events. Consider the after the shift. In general, two sets of keys need to be changed
example in Figure 4, where a user us shifts from tr4 to tr6 . to ensure security: knL and kr4 in the leave path, and knJ ,
When us was in tr4 , us subscribed g1 and g2 . After he shifts kr6 , kg1 , kg2 and kg3 in the enroll path.
to tr6 , he subscribes g1 , g2 and g3 . Hence, the shift in fact When keys are not shared (i.e. each program has one
means the user adds g3 into his current subscription. Note individual key tree), fewer keys are involved in the example
that the discussion of rekey operations in this study only shift event. As in Figure 4, tr4 is shared by g1 and g2 , while
considers individual user events. tr6 is shared by g1 , g2 and g3 . The shift from tr4 to tr6
To issue new keys upon a user event, the main task is to in fact indicates that us adds the program g3 to his current
identify the keys that need to be changed. We use two types subscription of g1 and g2 . Hence, if keys are not shared and
of paths in the key forest to represent the to-be-changed keys. each program has one individual key tree, only keys in g3 ’s
When a user leaves a tree, we say, a leave path is formed, tree need to be changed. Thus, the shared key scheme has
which consists of keys that the user will no longer use. When more rekey cost than conventional LKH in this example.
a user joins a tree, we say, an enroll path is formed, which Nevertheless, because us in tr6 is still subscribing to
consists of keys that the user will use in the future. Similarly, programs g1 and g2 as he was in tr4 , we find that keys in
when a user shifts from one tree to another, a leave path and the enroll path (e.g. knJ , kr6 , kg1 and kg2 ) might be reused
an enroll path are formed. In KTR, a complete path starts from by us without compromising security. For example, no matter
the leaf node and ends at the multiple DEKs of the subscribed whether us was in tr4 or shifts to tr6 , us always knows kg1 or
programs that share the tree. For example, in Figure 4, when kg2 . Hence, these two keys can be reused in this shift event.
us shifts from tr4 to tr6 , the leave path consists of knL and With an in-depth analysis, we find that under certain conditions
kr4 , and the enroll path consists of knJ , kr6 , kg1 , kg2 and kg3 . kr6 and knJ can be reused as well.
Note that in this example, kg1 and kg2 are the keys that us Deciding whether or not a key in an enroll path can be
already has and still needs in the future. Hence, kg1 and kg2 reused depends on whether or not the key can reveal the
are not in the leave path, although us leaves tr4 . programs’ DEKs that us is not supposed to know. Assume that
To broadcast new keys, the server should first compose in the example shift event, kr6 has never been changed since
rekey packets. In this study, we take the standard LKH t0 , us joins tr4 at t1 and shifts to tr6 at t2 , and t0 < t1 < t2 .

6. 6
There are at least two situations where kr6 must be changed Algorithm 1 Update of refresh and renew spots
at t2 . Either kr6 was used to encrypt kg3 as {kg3 }kr6 during Assume ki is used in the rekey messages upon a user event.
t0 and t2 ; or kr6 was used to encrypt kg1 or kg2 as {kg1 }kr6 1: if ki is in a leave path then
or {kg2 }kr6 during t0 and t1 . 2: renew spots must be added to all ki ’s spot series;
In the first situation, if kr6 is reused, us can decrypt kg3 3: end if
from {kg3 }kr6 , and then decrypt g3 ’s data that was broadcast 4: if ki is critical in an enroll path then
before us shifts to tr6 at t2 . Hence, the reused kr6 reveals kg3 5: renew spots must be added to all ki ’s spot series;
before us adds g3 into his subscription. In the second situation, 6: end if
if kr6 is reused, us can decrypt kg1 or kg2 from {kg1 }kr6 or 7: if ki ’s parent key kj is in a leave path then
{kg2 }kr6 , and then decrypt g1 ’s or g2 ’s data that was broadcast 8: refresh spots must be added to ki ’s spot series that are
before us joins tr4 at t1 . Hence, the reused kr6 reveals kg1 associated with the programs sharing kj ;
or kg2 before us joins the service. In summary, kr6 must be 9: end if
changed in both situations. If kr6 is reused without any change,
it can reveal DEKs that us should not know. Except these two
situations, if kr6 has never been used in the encryptions as Definition 4.1: Renew spot of a key ki : the time point t
discussed above, kr6 can be reused without any change. when ki ’s value is changed. ki ’s new value starting from t is
A similar but more complicated inspection is required on denoted as ki (t).
other keys in tr6 . The principle is to check whether a key Definition 4.2: Refresh spot of a key ki : the time point t
in an enroll path can reveal the previous DEK or another when ki is used to encrypt its parent key kj ’s new value in a
program’s DEK. The difficulty is that a key may indirectly refreshment δ(kj , t; ki , t′ ).
reveal DEKs, because its parent key may not be a DEK. Definition 4.3: Refreshment, δ(kj , t; ki , t′ ): a rekey mes-
For example, although knJ ’s parent key is kr6 , knJ can still sage broadcast at t in the form of {kj (t)}ki (t′ ) , and t′ ≤ t.
indirectly reveal the DEK kg3 . Assume that knJ was used
to encrypt kr6 and then kr6 was used to encrypt kg3 . In this At a refresh spot t, we say ki is refreshed when it is used to
situation, a sequence of rekey items {kr6 }knJ ,{kg3 }kr6 exist in encrypt its parent key ki ’s new value as in the δ(kj , t; ki , t′ ).
all broadcast messages. If knJ is reused without any change, At a renew spot t, we say ki is renewed when its valued is
us can first decrypt kr6 and then kg3 . Thus, knJ must be changed. ki is renewed only when it is in a leave path or
changed. If no such sequence of rekey items exist, knJ can critical in an enroll path. Accordingly, the rekey message to
be reused. Hence, the challenge in reusing keys lies in how renew ki has two possible forms. If ki is critical in an enroll
to find out which sequences of rekey items may compromise path, ki ’s new value is encrypted with its old value. Hence,
security and which keys in such sequences may reveal DEKs. the renew message is {ki (t)}ki (t′ ) . If ki is in a leave path,
In the following section, we propose a novel approach in ki ’s new value is encrypted with its child key kc . Hence, the
KTR to efficiently address the security issue in reusing keys. renew message of ki is also the refresh message of kc , i.e.
Since rekey cost is determined by the number of must-be- {ki (t)}kc (t′ ) .
changed keys, the cost can be minimized if we can find the When a user changes his subscription, the server needs to
minimum number of must-be-changed keys when the user change certain keys according to the algorithm presented in
joins or shifts to the tree. We name the must-be-changed keys Section IV-C and broadcast corresponding rekey messages.
in an enroll path as critical keys. KTR changes all keys in a Then, refresh and renew spots are logged to the keys that
leave path and only the critical keys in an enroll path, while are used in the rekey messages. The sequence of refresh and
leaving all the other keys unchanged. In this way, the rekey renew spots thus forms spot series in the time order. If a key
cost can be minimized. is shared by multiple programs, we let the key have multiple
spot series, each of which is associated with one program (see
examples in Section IV-B).
IV. S HARED K EY M ANAGEMENT
Algorithm 1 describes the procedure to log refresh and
In this section, we first present some important concepts in renew spots upon a user event. According to Definition 4.1,
Section IV-A and IV-B, which are used for identifying critical renew spots are logged to a key when the key is changed to a
keys . Then, we present the condition under which a key is new value. Hence, when a key is in a leave path or critical in
critical in Section IV-C and IV-D and the corresponding key an enroll path, the key must be changed and renew spots must
management algorithms. be logged to that key. Furthermore, according to Definition
4.2, refresh spots must be logged to a key when the key’s
parent is in a leave path, because the key is used to encrypt
A. Rekey Spots its parent in order to renew its parent.
KTR basically logs how a key was used in rekey messages. As previously discussed, refreshments may contain informa-
We can always find two operations in any rekey message: 1) a tion that threatens past confidentiality. For example, assume a
key’s value is changed or 2) a key is used to encrypt its parent user joins a tree shared by program gm at tc , and k1 is in
key when the parent key’s value is changed. Accordingly, we the enroll path. From all previous broadcast rekey messages,
define two types of spots to log the time points when either a dangerous rekey sequence for k1 is defined as,
operation is committed. Definition 4.4: A sequence of refreshments

7. 7
g1
Algorithm 2 Update of revive spots refresh spot
g2
1: let k be kv ; renew spot
g3
2: let t be tv ;
t1 t2 t3 t4 ... time
3: UPDATEREVIVE(k, t, tv , gv );
4: function UPDATEREVIVE(k, t, tv , gv ) Fig. 6. Spot series of key kr6
5: let V be the set of all child keys of k;
for ki ∈ V do kr2
refresh spot
6:
find ti the renew spot of ki that satisfies ti ≤ t; kr6
renew spot
7:
8: if δ(k, t; ki , ti ) exists then knJ
9: if ti is the latest renew spot of ki then t0 t1 t2 t3 t4 ... time
10: add tv to ki ’s revive spot series associated
Fig. 7. Spot series regarding program g2
with gv
11: end if
12: UPDATEREVIVE(ki , ti , tv , gv ); to check ki ’s child keys as they may have revive spots. If
13: end if δ(k, t; ki , ti ) does exist and ti ) is ki ’s latest renew spot, a
14: end for revive spot is logged to ki and the algorithm continues to
15: end function
check ki ’s child keys.
B. Examples of Spots
δ(k2 , t2 ; k1 , t1 ), δ(k3 , t3 ; k2 , t2 ), · · · , δ(km , tm ; km−1 , tm−1 )
that satisfies In this part, we demonstrate the spot series from two
• ki is ki−1 ’s parent key, different dimensions. First, a key has multiple spot series
• t 1 ≤ t 2 ≤ · · · ≤ t m < tc , associated with its programs. Figure 6 depicts the spot
• k1 (t1 ) has never been changed since t1 , series of kr6 in the key forest of Figure 4. Because kr6
• km (tm ) is the value of gm ’s DEK. is shared by three programs (i.e. g1 , g2 and g3 ), it has
If the server sends k1 to the user without any change, the three spot series, and each series is represented by a line
user can decrypt k2 (t2 ) and then iteratively decrypt k3 (t3 ) to in Figure 6. In this example, at t1 , a user leaves tr6 . kr6
km (tm ). Past confidentiality at tm is thus compromised, if the is first renewed, and all its spot series get a renew spot.
user uses km (tm ) to decrypt the data items that are broadcast Right after it is renewed, kr6 is used in the refreshments
during tm and tc , which should otherwise be inaccessible to δ(kr1 , t1 ; kr6 , t1 ), δ(kr2 , t1 ; kr6 , t1 ), δ(kr3 , t1 ; kr6 , t1 ).
that user. Past confidentiality at tm is preserved if the user Because these refreshments are related to all the programs,
either cannot find such a sequence of refreshments to obtain refresh spots are added to all kr6 ’s spot series. At t2 , a user
km (tm ) or has already legitimately obtained km (tm ) and the leaves tr5 . Because only kr2 and kr3 need to be changed, kr6 is
data items during tm and tc . used in the refreshments δ(kr2 , t2 ; kr6 , t1 ), δ(kr3 , t2 ; kr6 , t1 ).
Therefore, to identify whether a key is critical in a program, Hence, only two refresh spots are added to the series
we use a third type of spot to mark the key based on its renew associated with g2 and g3 . Readers can find that the other
and refresh spots. Similarly, the sequence of revive spots forms spots are for the events where a user joins tr6 at t3 , and
revive spot series in the time order. If a key is shared by another user shifts from tr4 to tr3 at t4 . In brief, renew
multiple programs, the key has multiple revive spot series, spots of a key are the same in all of its series, while refresh
each of which is associated with one program (see examples and revive spots are different regarding their corresponding
in Section IV-B). programs.
Definition 4.5: Revive spot of a key: the time point t when The second dimension of spot series is illustrated in Fig-
(1) the DEK of this key’s associated program has changed or ure 7, where we draw spot series of knJ , kr6 and kr2
(2) a dangerous rekey sequence exists as in Definition 4.4. associated with only one program g2 . At t1 , a user leaves
After the update of refresh and renew spots, the server tr6 . Assume kr6 and kr2 are in the leave path, but knJ is
updates revive spots according to Algorithm 2. Assume kv (the not. Hence, the broadcast server composes the refreshments
DEK of program gv ) is renewed at tv . Algorithm 2 updates δ(kr6 , t1 ; knJ , t0 ), δ(kr2 , t1 ; kr6 , t1 ) to change kr6 and kr2 . At
the revive spots of corresponding keys iteratively, starting from t2 , a user leaves tr5 . The refreshment δ(kr2 , t2 ; kr6 , t2 ) is
kv . At the beginning, let k = kv and t = tv . The algorithm broadcast to change kr2 . At t3 , a user joins tr6 . Assume knJ ,
iteratively uses the function UPDATEREVIVE(k, t, tv , gv ) to kr6 and kr2 are in the enroll path, these keys are changed.
update revive spots of related keys. Assuming that the al- At t4 , a user shifts from tr4 to tr3 , and δ(kr2 , t4 ; kr6 , t4 )
gorithm checks a key k which was renewed at t and was is broadcast to change kr2 . Note that at a refresh spot (for
refreshed at sometime later than t, it first selects a ki from instance, t1 of δ(kr6 , t1 ; knJ , t0 ), the symmetric key knJ is
all k’s child keys. According to Definition 4.5, if δ(k, t; ki , ti ) refreshed simultaneously as its parent key kr6 is renewed.
does not exist, there is no need to log a revive spot to ki and In Figure 8, we draw the revive spot series of the three keys
no need to further check ki ’s child keys. Also, if δ(k, t; ki , ti ) associated with g2 based on Figure 7. At t2 , kr2 is changed
does exist but ti is not ki ’s latest renew spot, there is still no and δ(kr6 , t1 ; knJ , t0 ), δ(kr2 , t2 ; kr6 , t1 ) can be recorded by
need to log a revive spot to ki but the algorithm continues any user. Revive spots are added to both kr6 and knJ , since the

8. 8
kr2
renew spot Theorem 4.1: Theorem of Critical Key (TCK): k in the
kr6
revive spot enroll path is a critical key, i.e. k must be changed before
knJ
being distributed to u to ensure past confidentiality, if and
t0 t1 t2 t3 t4 ... time
only if at least one pair of (kai , uai )k,u satisfies kai > uai at
Fig. 8. Revive spots regarding program g2 current time t, i.e. the key is older than the user’s subscription
regarding program gi .
a) Proof of the sufficient condition: If k is the DEK of gi ,
refreshments can expose kr2 at t2 to a new user if either kr6 or the proof is obvious. If k’s age is older than u’s subscription
knJ is given to the user without any change. However, at t4 , a age, there are some data items encrypted by k before the user
revive spot is only added to kr6 , because only δ(kr2 , t4 ; kr6 , t4 ) joins the program. Hence, k needs to be changed so that the
is potentially insecure. No revive spot is added to knJ at t4 , user cannot decrypt those data items.
since it is not used in the rekey operation. If k is not a DEK, let ki be the DEK of program gi , and the
latest renew spot of k is tk . Assume a pair of (kai , uai )k,u that
C. Critical Keys satisfies kai > uai at current time t. According to Definition
By logging spots to keys, the server can inspect a key’s past 4.6, k’s value has never been changed since t − kai and was
usage. We introduce the concepts of key age and subscription revived at t−kai . According to Definition 4.5, u can find such
age to decide whether a key is a critical key. a sequence of refreshments from all previous broadcast rekey
Definition 4.6: Age of a key: (1) if the key is a DEK, its messages at t − kai : δ(kα , tα ; k, tk ), ..., δ(ki , t − kai ; kβ , tβ ),
age is the time interval between the current time to its latest where tk ≤ tα ≤ ... ≤ tβ ≤ t − kai . Hence, if k is sent to
renew spot; (2) if the key is a KDK, its age is the time interval u without any change, u can derive ki at t − kai from these
between the current time to the revive spot that is located refreshments.
between the current time and the latest renew spot and is According to Definition 4.7, u joined gi at t − uai , which
closest to the latest renew spot. Note that a key may have means u is only allowed to decrypt data items of gi broadcast
multiple ages if it is shared by multiple programs, and each after t − uai . Because kai > uai , t − kai < t − uai . If k is
age is associated with one program. not changed, u can decrypt data items of gi broadcast between
According to the above definition, the age of a KDK is 0 t − kai and t − uai , and thus past confidentiality at t − kai is
if and only if there is no revive spot between the current time compromised.
and the latest renew spot. Otherwise, the age of the key is Therefore, if at least one pair of (kai , uai )k,u satisfies kai >
greater than 0. uai at current time t, k in an enroll path needs to be changed
Definition 4.7: Age of a subscription: the time interval before being distributed to user u to ensure past confidentiality.
between the current time to the latest beginning time the user b) Proof of the necessary condition: The necessary con-
is in a program. Note that if a user subscribes to multiple dition is that if all pairs of (kai , uai )u,k satisfy kai ≤ uai , k
programs, he has one subscription age for each program. does not need to be changed. If k is the DEK of gi , the proof
According to the above definition, the subscription’s age is is obvious. If k’s age is younger than user’s subscription age,
0 if and only if the user is not in the program. Otherwise, the user has already known all data items encrypted by k.
the user is in the program, and his subscription age is greater Hence, k does not needs to be changed.
than 0. If a user stops subscribing a program, the subscription If k is not a DEK, select any program gi that shares k. Let
age associated with this program turns to 0. If a user shifts ki be the DEK of gi , and the latest renew spot of k is tk .
from a tree to another tree while staying in a program, his We use reduction to absurdity to prove. The opposite of the
subscription age with this program continues. Finally, a user necessary condition is that past confidentiality for program gi
can have different subscription ages for different programs. will be broken if all pairs of (kai , uai )k,u satisfy kai ≤ uai
The traditional LKH approach to protect past confidentiality at current time t, and k is sent to u without any changed.
is to always have the server change keys in the enroll path According to Definition 4.7, u joined gi at t − uai and is
so that no previous refreshment can be exploited. Although allowed to decrypt data items of gi broadcast after t − uai .
this ensures past confidentiality, this approach is costly. There If past confidentiality for program gi is compromised, u must
are some situations where the old refreshments only contain have derived ki ’s value before t − uai . Because kai ≤ uai ,
secrets that the user already knows. In these situations, the user t−kai ≥ t−uai . u must have derived ki ’s value at a time point
can use the old symmetric key to decrypt the old refreshments, t′ before t − kai , i.e. t′ < t − kai . Hence, u must have found
thus keeping past confidentiality intact. That being the case, the refreshments from all previous broadcast rekey messages:
the server can directly distribute the old symmetric key without δ(kα , tα ; k, tk ), ..., δ(ki , t′ ; kβ , tβ ).
compromising the past confidentiality. According to Definition 4.5, t′ is a revive spot of k. If kai =
In the following, we give a generic method to identify criti- 0, no revive spot exists after tk , and thus t′ cannot exists. If
cal keys in the enroll path and reduce the rekey cost. Assuming kai > 0, t′ is a revive spot after k’s latest renew spot tk ,
key k is shared by m programs and will be distributed to and thus tk < t′ < t − kai . However, according to Definition
user u, we can get all k’s ages and all u’s subscription ages 4.6, there cannot be any revive spot of k between tk and t −
associated with these programs, denoted as [ka1 , ..., kam ]k and kai . Hence, t′ cannot exist, and the opposite of the necessary
[ua1 , ..., uam ]u . Program gi is thus associated with a pair of condition is false. Consequently, past confidentiality for any
ages, denoted as (kai , uai )k,u . program gi will not be broken if the pair of (kai , uai )k,u

9. 9
Algorithm 3 Algorithm of KTR in Broadcast Server critical keys at t2 because their ages are greater than 0. The
1: if a join or shift event happens then server needs to change kr1 and kr2 before distributing them to
2: according to TCK, find all critical keys in the tree the u2 . This shows that it is not necessary to change all keys in the
user wants to join or shift to; enroll path when a user subscribes the broadcast data services
3: select the best enroll path that has the minimum as would be required in the traditional LKH approach.
number of critical keys; Corollary 4.2: After a user enrolls in a tree, all keys in the
4: change all critical keys in the best enroll path, and enroll path are not older than the user.
broadcast corresponding rekey messages; According to Theorem 4.1, if a key is older than the user’s
5: end if subscription regarding a program, the key needs to be changed.
6: if a leave or shift event happens then Hence, at the time when the user enrolls in a tree, the keys,
7: change all keys in the leave path, and broadcast whose ages are older than the user, are renewed and their
corresponding rekey messages; ages turns to be 0. If the key is not older than the user’s
8: end if subscription regarding any program, the key does not need to
9: update renew, refresh and revive spots according to the be changed. Hence, the key continues to be not older than the
latest rekey messages; user. Therefore, after a user enrolls in a tree, all keys in the
enroll path are not older than the user.
Corollary 4.3: When a user shifts from a tree to another
satisfies kai ≤ uai at current time t, and k is sent to u without tree, the keys overlap both trees do not need to be changed.
any changed. Assume the user shifts from tree trα to tree trβ . According
Theorem 4.1 indicates that changing only critical keys can to Corollary 4.2, after the user enrolls in trα , all keys in the
ensure past confidentiality. Hence, given a key forest, Algo- enroll path cannot not be older than the user. Hence, when
rithm 3 is applied to find the best enroll path and minimize the the user shifts to trβ , the overlapped keys, which were in
rekey cost. When a join or shift event happens to a tree, the the enroll path when user enrolled in trα , do not need to be
algorithm uses the depth-first tree traversal approach to find all changed according to Theorem 4.1.
critical keys in the tree. If a path is found to have fewer critical Example: in Figure 4, user u shifts from tree tr4 to tr6 at
keys than previously visited paths, the algorithm records it as t1 . Assume user u is in tr4 since t0 , i.e. u can decrypt data
the best enroll path. items of g1 and g2 since t0 . kr1 and kr2 are the overlapped
keys with tr4 and tr6 . Because u is still in g1 and g2 after he
shifts to tr6 , kr1 and kr2 do not need to be changed.
D. Examples of Critical Keys
Corollary 4.1: When a user joins a tree, a key in the enroll
path is a critical key if and only if one of the key’s ages is E. Security Analysis
greater than 0. To ensure multicast or broadcast security, group key man-
Before a user joins the tree, his subscription ages for all of agement should satisfy four security properties [2], [3]: non-
the programs sharing this tree are 0. Hence, if the age of a key group confidentiality, collusion freedom, future confidentiality
in the enroll path for this program is greater than 0, the key is (forward secrecy), and past confidentiality (backward secrecy).
older than the user’s subscription. According to Theorem 4.1, In the following, we discuss how KTR satisfies these proper-
the key needs to be changed before being distributed to the ties.
user. Property 4.1: Non-group confidentiality: passive adver-
Example: consider a user event where a user u2 joins tree saries should not have access to any group key.
tr4 at time t2 in Figure 4. Assume that before t2 , another user Because keys are encrypted when being broadcast, passive
u1 shifts from tree tr4 to tr6 at t1 , and no other event happens adversaries can not decrypt any key without knowing decryp-
between t1 and t2 . At t1 , assume knL and kr4 are in the leave tion key. Hence, KTR obviously satisfies Property 4.1.
path. At t2 , assume knL and kr4 are in the enroll path. Now, we Property 4.2: Collusion freedom: by sharing group keys,
determine which keys are critical at t2 according to Corollary multiple present users can not derive any group key that they
4.1. are not holding.
At t1 , because u1 is still in g1 and g2 , the broadcast server When multiple users collude, they may try to share their
does not need to change kr1 and kr2 , and only needs to send keys to derived unknown group keys. The sharing can be
the refreshments δ(knL , t1 ; kc , tkc ), δ(kr4 , t1 ; knL , t1 ), where represented by a subgraph of the paths belonging to the
kc is a child key of knL and not known by u1 . According to colluding users. However, in KTR, a user does not know any
Definition 4.5, no revive spot is added to knL and kr4 , and key not on this path. Hence, colluding users do not know any
these two keys are renewed after t1 . Consequently, according key outside the subgraph that represents the collusion. KTR
to Definition 4.6, at t2 , the ages of both knL and kr4 are 0. thus satisfies Property 4.2.
The server can give knL and kr4 to u2 without any change Property 4.3: Future confidentiality (forward secrecy): a
according to TCK, since u2 cannot derive kr1 and kr2 before leaving user should not have access to any group key after
t2 from the previous refreshments. leaving his present group.
In this example, knL and kr4 are not critical keys, although According to Algorithm 3, KTR changes all keys in the
they are in the enroll path at t2 . However, kr1 and kr2 are leave path, because the leaving user holds these keys. Hence,

10. 10
TABLE II
the leaving user will not have the new keys after the user C OMPUTATION AT THE SEVER SIDE
leaves his group. KTR thus satisfies Property 4.3.
Property 4.4: Past confidentiality (backward secrecy): a service parameters inspe- upd- computa-
joining user added at time t should not have access to any size n m e d ction ate tion (ms)
keys used to encrypt data before t. small 10K 5 31 2.5 655 50K 16 ± 2
According to Algorithm 3, KTR changes all critical keys large 10K 50 300 12 141 240K 68 ± 16
in the enroll path when a user joins. Theorem 4.1 basically
proves that the joining user can only derive past group keys
from critical keys. Hence, changing critical keys and reusing enroll path, and (3) update renew, refresh and revive spots
non-critical keys prevent the joining user from obtaining past for affected keys. Compared with LKH, steps (1) and (3)
group keys. KTR thus satisfies Property 4.4. in KTR incur extra cost that includes only comparison and
assignment operations. The leave path simply consists of keys
V. P ERFORMANCE E VALUATION that the user will no longer hold, and thus the server can
easily find out the leave path. Nevertheless, the server needs
In this section, we analyze and evaluate the performance
to inspect the to-be-joined tree and find out the enroll path
of KTR at the server side and the client side respec-
with the minimum number of critical keys. Hence, according
tively. We define the following parameters for the analysis.
to Algorithm 3, the computation complexity on the server side
• The service provides m programs;
is mainly determined by the number of keys to be inspected
• n users subscribes the service;
and the number of updates to be committed.
• n users are distributed to e trees;
The number of keys to be inspected is determined by the
• Each tree is shared by d programs on average;
number of users in the to-be-joined tree and the number
• The leave rate is λl : the number of users unsubscribing
of programs that share that tree. Inside the tree, there are
to the service per unit time;
O(2 n ) keys. The root of the tree is connected to DEKs of
• The join rate is λj : the number of users subscribing to e
the programs that share the tree. As in Figure 5, the path
he service per unit time;
between the root and one DEK has O(log2 ( ed )) keys on
• The shift rate is λs : the number of users changing m
subscriptions per unit time; average. Hence, there are O(dlog2 ( ed )) keys between the root
m
• The total event rate Λ = λl + λj + λs and the connected DEKs. In total, the server needs to inspect
O(2 n + dlog2 ( ed )) keys in order to find the best enroll path
e m
and the critical keys.
A. Server Side The number of updates to be committed is determined by
1) Analysis: Since a server is generally abundant in energy the number of DEKs that must be changed. In the worst case,
and memory, its computation capacity becomes the main factor all DEKs need to be changed and all keys under the DEKs
that affects the performance of the whole system. If the need to be changed. Because each tree is shared by d programs
processing time for each event is large, this would delay user’s on average, one DEK is connected with de trees. Hence, in the
m
request. We measured the management cost of a server by two worst case, a changed DEK will require the server to update
metrics: (a) the total number of keys to be managed, and (b) all keys in the trees that are connected with the DEK. Hence,
the number of keys to be inspected and updated per rekey for each DEK, O(2 de n ) = O(2 dn ) keys need to be updated.
m e m
event. In the worst case (i.e. m DEKs need to be changed), the server
Since a tree has n users in average, there are O(2 n − 1)
e e needs to commit O(2dn) updates.
keys to be handled, including the root. For e trees, the server 2) Simulation: We did simulations on a server (a computer
needs to manage O(e(2 n − 1)) = O(2n − e) keys. Because
e with a 2GHz CPU and 2GB RAM running Linux). On average,
a key in any tree needs to keep a separate spot series for the server uses tens of milliseconds for one rekey operation
each program that shares the tree and each tree is shared by d in the KTR scheme. Table II shows the simulation results for
programs on average, the server needs to keep O((2n − e)d) two services with 10000 users. The first row is a small service
spot series. In the multi-layer root graph, the server needs to that provides only 5 programs and 31 valid trees, and each
manage DEKs and other non-root keys. Because one program tree is shared by 2.5 programs on average. The second row
is connected with O( ed ) trees, the server needs to manage
m is a large service that provides 50 programs and 300 valid
O(( ed − 1)m) = O(ed − m) keys (including DEKs and non-
m trees, and each tree is shared by 12 programs on average.
root keys) for m programs. We notice that any one of these Column “inspection” is the estimate of the number of keys to
keys is connected with only one program. Hence, each key be inspected in the worst case. Column “update” estimates the
requires only one spot series, and thus the server needs to keep number of updates to be committed in the worst case. Column
O(ed − m) spot series. In total, the server needs to manage “computation” measures the average computation time for one
O(2n−e+ed−m) keys with a storage requirement of O((2n− rekey operation in simulation.
e)d + ed − m) = O(2nd − m). In comparison, LKH requires Obviously, the computation time on the server side is mainly
that the server manages O((2 ed n −1)m) = O(2nd−m) keys.
m e determined by the number of updates to be committed in the
According to Algorithm 3, KTR needs three steps for each simulations, as the computation time is almost proportional to
rekey operation: (1) find the leave path and the best enroll the number of updates (via regression analysis). First, since
path, (2) change keys in the leave path and critical keys in the the number of users is fixed in these simulations, when the

11. 11
2
service has more trees, the average number of users in one tree a shift event, the number of decryptions is O(2(1 + ρ) nd ). m
decreases. Accordingly, the server takes less time to inspect Considering user activities, the average number of decryptions
2
1
keys in the large service than in the small service. Hence, would be O( Λ (2λl + 2ρλj + 2(1 + ρ)λs ) nd ). Hence, on
m 2
1
the server spends the most time on updating spots for affected average, each user decrypts O( Λ (2λl + 2ρλj + 2(1 + ρ)λs ) d )m
keys. Since a program is connected with more trees in the large rekey items upon receiving a rekey message.
service, a changed DEK will affect more keys. According to The third metric, maximum number of keys to be stored,
the estimation, in the worst case, the server needs to commit represents the storage demand which is proportional to the
updates in the large service 240000 = 4.8 times as much
50000 number of keys a user needs to hold. Inside a tree, a user
as in the small service. Overall, as measured, the server’s needs to hold keys along the path from its leave node to the
computation time in the large service is 68 = 4.3 times as
16 root of the tree. Because a tree has O( n ) users, a user holds
e
much as in the small service. O(log2 ( n )) keys inside a tree. In the root graph, a user hold
e
keys from the root of the tree to all DEKs of the programs
B. Client Side that share the tree. Because a root is connected with d DEKs
1) Analysis: At the client side, three main performance and each DEK is connected with O( ed ) trees, a user holds
m
metrics need to be measured: average rekey message size per O(dlog2 ( de )) keys in the root graph. In total, a user should
m
event, average number of decryption per event per user, and hold O(log2 ( n ) + dlog2 ( de )) keys. Because a user stays in
e m
maximum number of keys to be stored, that can well capture multiple trees in LKH, the user should hold O(dlog2 ( n ) + e
the overhead of KTR on resource limited mobile devices dlog2 ( de )) keys if keys are not shared.
m
in terms of communication, storage, power consumption and 2) Simulation: The analysis gives estimates on major per-
computation. Based on these three metrics, we can infer other formance metrics. We notice that some factors could bring
metrics that are more directly related to the mobile devices. more insightful results. For example, users may not be evenly
For example, if we decide a particular encryption algorithm, distributed in trees due to the fact that some programs may be
we know the length of a key, the time to compute a key, and the more popular than other programs. Also, users may be more or
energy consumption to execute the algorithm. Consequently, less likely to stay in current subscriptions than to frequently
we can obtain metrics, such as the communication overhead change their subscriptions. Hence, in the following, we use
in the rekey messages, etc. simulation to examine the impacts of these user behaviors.
The first metric, average rekey message size per event, is In the simulation, we compare KTR with three other rep-
measured as the number of encryptions {∗}k in the rekey resentative schemes: SKT, eLKH, LKH, as listed in Table
message, represents communication cost and power consump- III, to illustrate how shared key and critical key improve
tion in a mobile device. In a leave event, the rekey message the performance of key management in wireless broadcast
consists of rekey items for keys in the leave path. Hence, the services. SKT is the approach in [28] where only shared key
number of encryptions is O(2(log2 ( n )+dlog2 ( de ))). In a join
e m tree is applied. eLKH is an approach where only critical key is
event, the rekey message consists of rekey items for critical applied to enhance LKH. Neither shared key tree nor critical
keys in the enroll path. Hence, the number of encryptions is key is adopted in LKH. If shared key tree is adopted, key
O((1+ρ)(log2 ( n )+dlog2 ( de ))), where ρ is the ratio of critical
e m management is based on the key forest as illustrated in Figure
keys over all keys in the enroll path. Our simulation shows that 4; otherwise, a key tree is created for each program and a
ρ is around 22.9 ± 1.8% in an enroll path. In a shift event, the user is assigned to all trees corresponding to the programs he
rekey message consists of rekey items for keys in the leave subscribes. If critical key is used, a key in an enroll path is
path and critical keys in the enroll path. Hence, the number of changed if and only if it is a critical key; otherwise, all keys
encryptions is O((3 + ρ)(log2 ( n ) + dlog2 ( de ))). Considering
e m in the enroll path need to be changed (as in the other old
user activities, the average rekey message size would be schemes). Table III lists four schemes representing different
1
O( Λ (2λl + (1 + ρ)λj + (3 + ρ)λs )(log2 ( n ) + dlog2 ( de ))).
e m solutions which may or may not adopt these two ideas. The
The second metric, average number of decryption per event names of the schemes are self-explanatory. If key tree reuse
per user, measures computation cost and power consumption is adopted, key management is based on the key forest as
in a mobile device, since the device needs to decrypt new illustrated in Figure 4; otherwise, a key tree is created for
keys from rekey messages. Define the height of a key as its each program and a user is assigned to all trees corresponding
distance to the bottom of a tree. For example, if a tree has n to the programs he subscribes. If critical key is used, a key
users, the height of its root key is log2 n. Obviously, if a key’s in an enroll path is changed if and only if it is a critical key;
height is h, 2h users need to decrypt it when it is updated otherwise, all keys in the enroll path need to be changed (as
in a rekey event. Hence, in a tree of n users, when a path in other schemes). Note that the well-known LKH is used as
of keys need to be changed, the total number of decryptions
n
a base line (i.e. neither shared key nor critical key is adopted).
log2
is O( i=1 2i ) ≈ O(2n). In a leave event, because there are a) Settings: We assume that the server provides 50
O( n de ) users under a to-be-changed DEK, the total number
e m programs. In our experiments, the key forest consists of 300
of encryptions for this DEK and its downward keys is O(2 nd ). m2 trees when shared key tree is adopted. Each tree represents a
Because d DEKs need to be changed in a leave event, O(2 nd ) m different option of subscriptions. We also assume that there
decryptions are committed by affected users. Similarly, in a are 10000 users (on average) subscribing to the services. The
2
join event, the total number of decryptions is O(2ρ nd ). In
m root graph in key forest was automatically generated according

12. 12
TABLE III TABLE IV
K EY MANAGEMENT SCHEMES C ASES IN KEY MANAGEMENT
Schemes shared key critical key Case Major subscriptions Major events
KTR Y Y Case I Multiple Join and leave
SKT Y N Case II Single Join and leave
eLKH N Y Case III Multiple Shift
LKH N N Case IV Single Shift
to subscriptions. Each program had a different depth in root server to change fewer keys.
graph depending on the number of subscriptions that include Then, we evaluate performance of the key management
the program. In the worst case where a program is included in schemes by fixing λl = 1 and varying λs (x-axis) from 1 to
all subscriptions, the depth for this program in root graph is 9. 9 as shown in Figure 9(c) and (d). Obviously, when the shift
Most programs had a depth of 8 or less, because the probability rate grows, the performance of SKT turns worse because of
that a program is selected by more than 256 subscriptions is the extra overhead that is introduced in managing shared keys
low. At the same time, the tree depth is around 5, since 10000 when a user quits or adds some but not all of his subscribed
users are randomly distributed to 300 trees. programs. Obviously, the adoption of critical keys incurs the
In each experiment, we compare two equivalent key graphs major improvement in terms of rekey message size. KTR and
for shared key schemes and non-shared key schemes. We first eLKH are the best solutions.
generate a random key forest and assign users to leaf nodes By comparing CASE III and CASE IV (corresponding to
of the key forest. Then, for non-shared key schemes (LKH the subscriptions of multiple programs and single program,
and eLKH), we assign users to different key trees according respectively), we found that the extra overhead of shift is
to their subscriptions in shared key schemes. Any user event higher in CASE III. Figure 9 also shows that KTR and STK are
in shared key schemes was also mapped into the equivalent more sensitive to these types of major user events than eLKH
event in non-shared key schemes. and LKH. The average rekey message size in KTR and STK
All three user events (i.e. join, shift and leave) are modeled grows as the shift rate increases and shrinks as the join/leave
as independent Poisson processes. We let λl = λj so the total rate increases. On the contrary, the average rekey message size
number of users remains constant (i.e. around 10000). We vary in eLKH and LKH remains almost flat regardless of the rate
λl and λs separately in order to observe their impacts on the of user events.
rekey performance. The result of our performance comparison Based on our experimental results, by adopting only shared
is obtained by averaging the rekey cost over 3000 random user key tree, SKT reduces the rekey message size to around 60% to
events. Here, a user event is referred to an event in schemes 90% of LKH. By adopting critical keys alone, eLKH reduces
that adopt shared key tree. Such an event is mapped into the rekey message size to around 55% to 65% of LKH. This
several user events in schemes that do not adopt shared key result also validates our claim that many keys in the enroll path
tree. For example, a user joins a tree of multiple programs do not need to be changed. In fact, over all the experiments,
in KTR is mapped as a sequence of events in LKH (each is only around 23% keys in the enroll path need to be changed.
corresponding to the user joining a tree of these programs). c) Average Number of Decryption Per Event Per User:
Four test cases are generated for evaluation based on major Power consumption and computation cost are two primary
subscriptions and major events (summarized in Table IV). In concerns for mobile users. We use the average number of
Case I and Case III, 80% of the users subscribe to multiple decryptions to measure these costs. Similar to the experiments
programs and the other 20% only subscribe to one of the in the previous section, we vary the rates of major events to
programs. In Case II and Case IV, 20% of the users subscribe observe their impacts on decryption overhead. Figure 10 shows
to multiple programs and the other 80% subscribe to only one that the schemes adopting critical keys (i.e. KTR and eLKH)
program. Furthermore, in Case I and Case II, the major events are better than SKT and LKH. The number of decryption in
are joins and leaves; while in Case III and Case IV, the major eLKH is around 80% of that in LKH, and KTR’s is around
events are shifts. In the simulations, we vary the rates for the 80% of SKT’s too. In all schemes, the number of decryptions
major events while keeping the other rates at 1. drops as the join/leave rate increases and rises as the shift rate
b) Average Rekey Message Size Per Event: We first increases.
evaluate performance of the key management schemes in terms However, the adoption of shared key has negative impacts
of average rekey message size, by fixing λs = 1 and varying on reducing user’s decryption cost. In Figure 10, LKH is better
λl (x-axis) from 1 to 9 as shown in Figure 9(a) and (b). than SKT, especially when the shift rate is high. So does eLKH
KTR and SKT that adopt shared keys significantly outperforms in comparison with KTR. This can be explained as follows. In
LKH, Because the major user events are join and leave, a shared key schemes, when a user shifts from a tree to another,
user only needs to join or leave one tree when he subscribes some users will be affected by the changed keys in both the
or unsubscribes to multiple programs. In contrast, LKH that leave and the enroll paths if they subscribe to the programs that
does not have shared keys requires a user needs to join or the user keeps subscribing to. As previously discussed, shared
leave multiple trees for multiple programs. Furthermore, KTR key schemes introduce extra rekey cost because they change
is better than SKT, because critical key in KTR allows the keys in two paths. On the contrary, in non-shared key schemes,