Ktr an efficient key management scheme for secure data access control in wireless broadcast services


Published on

Published in: Education, Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Ktr an efficient key management scheme for secure data access control in wireless broadcast services

  1. 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 accessto data in wireless broadcast services, symmetric key-basedencryption is used to ensure that only users who own the validkeys can decrypt the data. Regarding various subscriptions, anefficient key management to distribute and change keys is in greatdemand for access control in broadcast services. In this paper, wepropose an efficient key management scheme (namely KTR) tohandle key distribution with regarding to complex subscription Fig. 1. A wireless data broadcast systemoptions and user activities. KTR has the following advantages.First, it supports all subscription activities in wireless broadcastservices. Second, in KTR, a user only needs to hold one set ofkeys for all subscribed programs, instead of separate sets of keys dissemination. Data is broadcast periodically so that users canfor each program. Third, KTR identifies the minimum set of keys recover lost or missed data items. The uplink channels, whichthat must be changed to ensure broadcast security and minimize have limited bandwidth, are reserved for occasional uses tothe rekey cost. Our simulations show that KTR can save about45% 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, suchkey 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 wouldcontrol, key hierarchy, secure group communication, key dis- like to access. Typical programs could be weather, news, stocktribution 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 specifyalong 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 haveboth industrial and academic communities in recent years. mainly focused on performance issues such as reducing dataAmong 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 ofsimultaneous 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 secrecyas commercial products for many years. In particular, the [2], [3] with respect to membership dynamics. In the wirelessannouncement of the MSN Direct Service (direct.msn.com) broadcast environment, any user can monitor the broadcasthas further highlighted the industrial interest in and feasibility channel and record the broadcast data. If the data is notof 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 anents 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 datathe broadcast information, and filters the subscribed data in a proper way so that only subscribing users can access theaccording to user’s queries and privileges. The specialty of the broadcast data, and subscribing users can only access the databroadcast 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 forlisten to the broadcast channel but only retrieve data (filter data ensuring secure data dissemination and access. The broadcastout) based on users’ queries. The communication mechanism data can be encrypted so that only those users who ownincludes wireless broadcast channels and (optional) uplink valid keys can decrypt them. Thus, the decryption keys canchannels. Broadcast channel is the main mechanism for data be used as an effective means for access control in wireless
  2. 2. 2data broadcast services. For example, each program has one security can be ensured. In this way, rekey cost can be reducedunique key to encrypt the data items. The key is issued to and fewer users will be affected. Therefore, we propose athe 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 subscribeencryption 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 withoutrekey messages designated to other users. At the same time, compromising security. KTR has two components: shareda data item can be decrypted by an arbitrary number of users key tree and shared key management, and its contributionwho 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 advantageor 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, programsprogram, the encryption key needs to be changed to ensure overlap with each other in terms of users. Because existingthat the user can only access the data in his subscription approaches manage keys by separating programs, they turn toperiod. 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 schemethe service without compromising security and interrupting (namely KTR) to better support subscriptions of multiplethe operations of other users? Regarding unique features of programs by exploiting the overlapping among programs. KTRbroadcast services, we are interested in new key management let multiple programs share the same set of keys for the usersschemes that can simultaneously provide security, efficiency who subscribe to these programs. KTR thus inherently enablesand flexibility. A broadcast service generally provides many users to handle fewer keys and reduces the demands of storageprograms; 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 thebe able to flexibly subscribe/unsubscribe to any program same set of keys, a critical issue is how to manage shared keysof interests and make changes to his subscription at any efficiently and securely. We find that when keys need to betime. Hence, in addition to security and efficiency, flexibility distributed to a user, it is unnecessary to change all of them. Inthat a user can customize his subscription at anytime is an many circumstances, when a user subscribes to new programsindispensable feature of key management in broadcast services or unsubscribes to some programs, a large portion of keysto 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 formay 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, KTRvices ; and (2) broadcast encryption techniques [10]–[16] in efficiently handles the rekey of the shared keys and minimizescurrent broadcast services (such as satellite TV). We notice the rekey costs associated with possible subscriptions. Ourthat 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 SectionThey normally require users to possess decryption boxes to II, we present related works on group key management. Inreceive the subscribed programs, and the broadcast services Section III, the first component of KTR is described that fullycan 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 toselect 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 illustratedecryption box that can decrypt the subscribed programs. the performance improvements in KTR. Finally, we concludeHence, 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 ANAGEMENTis not the most efficient approach. In broadcast services, aprogram is equivalent to a multicast group, and users who A. Logical Key Hierarchysubscribe to one program form a group. Intuitively, we could Secure key management for wireless broadcast is closelymanage 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 usesstraightforward approach is inefficient for users subscribing a key tree (depicted in Figure 2) for each group of users whoto many programs. If users could use the same set of keys subscribe the same program. The root (top node) of the treefor multiple programs, there would be fewer requirements is the data encryption key (DEK) of the program. Each leaffor 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. 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 howFig. 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 knowsthe keys along the path from the leaf of the user to the rootof 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 thechange and broadcast the corresponding new keys, and this literature for multicast and broadcast services. [10] usedoperation is called rekey, and the broadcast message of new arbitrarily revealed key sequences to do scalable multicastkeys 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 packetsusers. Assume user u1 leaves the group (in Figure 2). The for decryption. However, both of them require pre-plannedserver 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 atrekey 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 isby 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 againstSimilarly, other users can obtain the new keys in their own coalitions of k non-privileged users, and requires every userpaths. It is obvious u1 cannot obtain any new keys from this to store O(klog2 (k)log2 (n)) keys. Naor et al. [16] proposedmessage, 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 efficientchange k4 , k2 and k1 so that u1 cannot use the old keys to than LKH in rekey operations, it mainly handles revocationdecrypt old broadcast data. Note that u1 may have already when a user stops subscription. It does not efficiently supporteavesdropped 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 recovereavesdropped 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 managementThe first three components are for u1 to use his individual key schemes in broadcast encryption are less flexible regardingto decrypt the new keys, and the last three are for all existing possible subscriptions. Conforming to the current practiceusers to use their old keys to decrypt the new keys. In this described in RFC2627 [2], we select binary trees to presentway, 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 TRUCTUREis 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 isuses independent keys, researchers developed several other applied and then raise the security and efficiency problems ofapproaches [23], [24] that generate new keys by exploiting this scheme. We then present a novel shared key managementthe relation between child and parent keys or the relation in Section IV that ensures security and minimizes rekeybetween old and new keys. Our scheme is complementary to cost, and also address major issues when applying KTR inthese schemes, since our scheme mainly examines whether a broadcast server.
  4. 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 joinFig. 3. Shared key tree Fig. 4. Key forestA. Key Forest programs g1 g2 g3 g1 g2 g3 To address scalability and flexibility in key management, kr1 kr2 kr3 kr1 kr2 kr3 DEKsLKH is used as the basis of our scheme. An intuitive solution root graphis to use a key tree for each program as shown in Figure3(a). However, when user u1 subscribes to two programs k1 k2 k3 k4 k5 k1 k2 k3 k4 k5 KDKssimultaneously, he needs to manage two sets of keys in both treestrees 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 graphkey management. As shown in Figure 3(b), we let the twoprograms share the same sub key tree as represented by thegray triangle. We regroup users so that users subscribing to Property 3.3: Each user belongs only to one tree in the keyboth 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 subscribingto both g1 and g2 only needs to manage one set of keys for bothprograms. Moreover, when a user joins or leaves a tree shared B. Root Graphby multiple programs, the encryption and communication cost The root graph in Figure 4 depicts how programs sharefor rekey operations can be significantly less than conventional keys. Since m programs could generate 2m − 1 differentLKH 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 numberFigure 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 manyaccording to their subscriptions. A tree represents not only trees. Assume the DEK is connected with n trees. When a usera unique subscription, but also a group of users having this stops subscribing the program, the DEK needs to be updatedsubscription. Since a subscription is a set of programs, the and distributed to users in n trees. Because the new DEK isroot of the subscription’s tree is connected to the DEKs of encrypted with the roots of the n trees in rekey, O(n) rekeythe programs belonging to the subscription. As keys in a tree items are generated. Obviously, if n is large, a leave eventare 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. Programexample, 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 itemsin 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 tonode to the DEKs of the subscribed programs: kus , knL , kr4 , connect the DEK with the roots of the shared trees. As inkg1 and kg2 . Finally, kg1 , kg2 and kg3 are DEKs to encrypt Figure 5(b), kg1 is connected (bold lines) with kr1 , kr2 kr3broadcast 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 ofprograms multiple times, the key forest obviously should have LKH. For a leave event, the number of rekey items in thethe following properties, which are guaranteed in any directed root graph is reduced to O(log2 (n)). Note that, for differentand 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 bylinks from the root of a tree trs to the DEKs of the programs the number of trees to which the program is connected. Inthat 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 itlinks from any leaf node in a tree to the root; is only connected with 2 trees.
  5. 5. 5 TABLE I Second, a subscription is not a conventional plan that a R EKEY OPERATIONSbroadcast service provides, because the subscribed programsof a plan normally cannot be changed by a user. In this paper, Tree Program oriented eventsusers 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 subscriptionsexist, at most n subscriptions are valid, since the number ofvalid subscriptions cannot be more than the number of users. ′ ′ approach to encrypt a new key ki in a rekey item {ki }kj . IfHence, 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 enrolled m trees. As discussed in Section V-A, KTR requires that paths: keys in a leave path are changed as in LKH, while onlythe 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 securityO(2n − e + ed − m) keys. In the worst case where e = n, is ensured. In addition, KTR identifies an enroll path with thethe server needs to manage only O(n(1 + d) − m) keys. In minimum number of must-be-changed keys to reduce rekeycontrast, LKH requires the server to manage O(2nd−m) keys. cost without compromising security. The detailed approach isObviously, KTR allows the server to manage much fewer keys presented in Section IV.than conventional LKH-based approaches. D. Challenges in Shared Key ManagementC. 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 wherejoining/leaving/shifting among trees, instead of some previously subscribed programs are still subscribed tojoining/quitting/changing among programs. Table I lists by the user. Consider the example in Figure 4 where us shiftsthe mapping between tree-oriented operations and the from tr4 to tr6 . Apparently, g1 and g2 are still subscribed tocorresponding program-oriented user events. Consider the after the shift. In general, two sets of keys need to be changedexample 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 onemeans the user adds g3 into his current subscription. Note individual key tree), fewer keys are involved in the examplethat the discussion of rekey operations in this study only shift event. As in Figure 4, tr4 is shared by g1 and g2 , whileconsiders 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 currentidentify the keys that need to be changed. We use two types subscription of g1 and g2 . Hence, if keys are not shared andof paths in the key forest to represent the to-be-changed keys. each program has one individual key tree, only keys in g3 ’sWhen a user leaves a tree, we say, a leave path is formed, tree need to be changed. Thus, the shared key scheme haswhich 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 toconsists of keys that the user will use in the future. Similarly, programs g1 and g2 as he was in tr4 , we find that keys inwhen a user shifts from one tree to another, a leave path and the enroll path (e.g. knJ , kr6 , kg1 and kg2 ) might be reusedan enroll path are formed. In KTR, a complete path starts from by us without compromising security. For example, no matterthe leaf node and ends at the multiple DEKs of the subscribed whether us was in tr4 or shifts to tr6 , us always knows kg1 orprograms 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 conditionskr4 , 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 bealready has and still needs in the future. Hence, kg1 and kg2 reused depends on whether or not the key can reveal theare 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 sincerekey 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. 6There are at least two situations where kr6 must be changed Algorithm 1 Update of refresh and renew spotsat 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 thenor {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 iffrom {kg3 }kr6 , and then decrypt g3 ’s data that was broadcast 4: if ki is critical in an enroll path thenbefore 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 ifif 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 arebefore 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 ifchanged in both situations. If kr6 is reused without any change,it can reveal DEKs that us should not know. Except these twosituations, if kr6 has never been used in the encryptions as Definition 4.1: Renew spot of a key ki : the time point tdiscussed 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 tin an enroll path can reveal the previous DEK or another when ki is used to encrypt its parent key kj ’s new value in aprogram’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 usedto 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 tosituation, 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 isus can first decrypt kr6 and then kg3 . Thus, knJ must be changed. ki is renewed only when it is in a leave path orchanged. If no such sequence of rekey items exist, knJ can critical in an enroll path. Accordingly, the rekey message tobe reused. Hence, the challenge in reusing keys lies in how renew ki has two possible forms. If ki is critical in an enrollto 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, theKTR 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 tominimum number of must-be-changed keys when the user change certain keys according to the algorithm presented injoins 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 thatleave path and only the critical keys in an enroll path, while are used in the rekey messages. The sequence of refresh andleaving all the other keys unchanged. In this way, the rekey renew spots thus forms spot series in the time order. If a keycost 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 akeys . Then, we present the condition under which a key is new value. Hence, when a key is in a leave path or critical incritical in Section IV-C and IV-D and the corresponding key an enroll path, the key must be changed and renew spots mustmanagement 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 encryptA. 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 akey’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 inkey 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. 7 g1Algorithm 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 ... time10: add tv to ki ’s revive spot series associated Fig. 7. Spot series regarding program g2 with gv11: end if12: UPDATEREVIVE(ki , ti , tv , gv ); to check ki ’s child keys as they may have revive spots. If13: end if δ(k, t; ki , ti ) does exist and ti ) is ki ’s latest renew spot, a14: end for revive spot is logged to ki and the algorithm continues to15: 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 lineuser can decrypt k2 (t2 ) and then iteratively decrypt k3 (t3 ) to in Figure 6. In this example, at t1 , a user leaves tr6 . kr6km (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 refreshmentsduring 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 userkm (tm ) or has already legitimately obtained km (tm ) and the leaves tr5 . Because only kr2 and kr3 need to be changed, kr6 isdata 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 serieswe use a third type of spot to mark the key based on its renew associated with g2 and g3 . Readers can find that the otherand refresh spots. Similarly, the sequence of revive spots forms spots are for the events where a user joins tr6 at t3 , andrevive spot series in the time order. If a key is shared by another user shifts from tr4 to tr3 at t4 . In brief, renewmultiple programs, the key has multiple revive spot series, spots of a key are the same in all of its series, while refresheach of which is associated with one program (see examples and revive spots are different regarding their correspondingin 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 isupdates revive spots according to Algorithm 2. Assume kv (the not. Hence, the broadcast server composes the refreshmentsDEK of program gv ) is renewed at tv . Algorithm 2 updates δ(kr6 , t1 ; knJ , t0 ), δ(kr2 , t1 ; kr6 , t1 ) to change kr6 and kr2 . Atthe revive spots of corresponding keys iteratively, starting from t2 , a user leaves tr5 . The refreshment δ(kr2 , t2 ; kr6 , t2 ) iskv . 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 (forrefreshed at sometime later than t, it first selects a ki from instance, t1 of δ(kr6 , t1 ; knJ , t0 ), the symmetric key knJ isall 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 keysno 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 changeddoes 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 byneed 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. 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 atFig. 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 subscriptionknJ is given to the user without any change. However, at t4 , a age, there are some data items encrypted by k before the userrevive spot is only added to kr6 , because only δ(kr2 , t4 ; kr6 , t4 ) joins the program. Hence, k needs to be changed so that theis 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 thatC. 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 wasusage. We introduce the concepts of key age and subscription revived at t−kai . According to Definition 4.5, u can find suchage 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 torenew 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 thesebetween 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 , whichclosest to the latest renew spot. Note that a key may have means u is only allowed to decrypt data items of gi broadcastmultiple ages if it is shared by multiple programs, and each after t − uai . Because kai > uai , t − kai < t − uai . If k isage 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 isif 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 , kprograms, 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. Letage 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 thesubscription age with this program continues. Finally, a user necessary condition is that past confidentiality for program gican 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 isso 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 mustare 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 pointcan use the old symmetric key to decrypt the old refreshments, t′ before t − kai , i.e. t′ < t − kai . Hence, u must have foundthus 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. Ifcal 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 Definitionuser 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 anyages, denoted as (kai , uai )k,u . program gi will not be broken if the pair of (kai , uai )k,u
  9. 9. 9Algorithm 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 anothersatisfies 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 theensure past confidentiality. Hence, given a key forest, Algo- enroll path cannot not be older than the user. Hence, whenrithm 3 is applied to find the best enroll path and minimize the the user shifts to trβ , the overlapped keys, which were inrekey cost. When a join or shift event happens to a tree, the the enroll path when user enrolled in trα , do not need to bealgorithm 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 atkeys than previously visited paths, the algorithm records it as t1 . Assume user u is in tr4 since t0 , i.e. u can decrypt datathe 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 enrollpath is a critical key if and only if one of the key’s ages is E. Security Analysisgreater 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 confidentialityin 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, passiveu1 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 they4.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 theirdoes not need to change kr1 and kr2 , and only needs to send keys to derived unknown group keys. The sharing can bethe refreshments δ(knL , t1 ; kc , tkc ), δ(kr4 , t1 ; knL , t1 ), where represented by a subgraph of the paths belonging to thekc is a child key of knL and not known by u1 . According to colluding users. However, in KTR, a user does not know anyDefinition 4.5, no revive spot is added to knL and kr4 , and key not on this path. Hence, colluding users do not know anythese two keys are renewed after t1 . Consequently, according key outside the subgraph that represents the collusion. KTRto 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): aaccording to TCK, since u2 cannot derive kr1 and kr2 before leaving user should not have access to any group key aftert2 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 thethey are in the enroll path at t2 . However, kr1 and kr2 are leave path, because the leaving user holds these keys. Hence,
  10. 10. 10 TABLE IIthe leaving user will not have the new keys after the user C OMPUTATION AT THE SEVER SIDEleaves 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 ± 16in the enroll path when a user joins. Theorem 4.1 basicallyproves that the joining user can only derive past group keysfrom critical keys. Hence, changing critical keys and reusing enroll path, and (3) update renew, refresh and revive spotsnon-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 pathof KTR at the server side and the client side respec- with the minimum number of critical keys. Hence, accordingtively. 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 DEKsthat affects the performance of the whole system. If the need to be changed. Because each tree is shared by d programsprocessing time for each event is large, this would delay user’s on average, one DEK is connected with de trees. Hence, in the mrequest. We measured the management cost of a server by two worst case, a changed DEK will require the server to updatemetrics: (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 mevent. 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 computerneeds 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 operationeach program that shares the tree and each tree is shared by d in the KTR scheme. Table II shows the simulation results forprograms on average, the server needs to keep O((2n − e)d) two services with 10000 users. The first row is a small servicespot series. In the multi-layer root graph, the server needs to that provides only 5 programs and 31 valid trees, and eachmanage DEKs and other non-root keys. Because one program tree is shared by 2.5 programs on average. The second rowis connected with O( ed ) trees, the server needs to manage m is a large service that provides 50 programs and 300 validO(( 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 tokeys is connected with only one program. Hence, each key be inspected in the worst case. Column “update” estimates therequires only one spot series, and thus the server needs to keep number of updates to be committed in the worst case. ColumnO(ed − m) spot series. In total, the server needs to manage “computation” measures the average computation time for oneO(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 mainlythat 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 torekey operation: (1) find the leave path and the best enroll the number of updates (via regression analysis). First, sincepath, (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. 11 2service has more trees, the average number of users in one tree a shift event, the number of decryptions is O(2(1 + ρ) nd ). mdecreases. Accordingly, the server takes less time to inspect Considering user activities, the average number of decryptions 2 1keys 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 1the server spends the most time on updating spots for affected average, each user decrypts O( Λ (2λl + 2ρλj + 2(1 + ρ)λs ) d )mkeys. 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 theupdates in the large service 240000 = 4.8 times as much 50000 number of keys a user needs to hold. Inside a tree, a useras in the small service. Overall, as measured, the server’s needs to hold keys along the path from its leave node to thecomputation 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 emuch 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 programsB. 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 mmetrics need to be measured: average rekey message size per O(dlog2 ( de )) keys in the root graph. In total, a user should mevent, average number of decryption per event per user, and hold O(log2 ( n ) + dlog2 ( de )) keys. Because a user stays in e mmaximum number of keys to be stored, that can well capture multiple trees in LKH, the user should hold O(dlog2 ( n ) + ethe overhead of KTR on resource limited mobile devices dlog2 ( de )) keys if keys are not shared. min 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 bringmetrics that are more directly related to the mobile devices. more insightful results. For example, users may not be evenlyFor example, if we decide a particular encryption algorithm, distributed in trees due to the fact that some programs may bewe know the length of a key, the time to compute a key, and the more popular than other programs. Also, users may be more orenergy consumption to execute the algorithm. Consequently, less likely to stay in current subscriptions than to frequentlywe can obtain metrics, such as the communication overhead change their subscriptions. Hence, in the following, we usein 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 Tablemessage, represents communication cost and power consump- III, to illustrate how shared key and critical key improvetion in a mobile device. In a leave event, the rekey message the performance of key management in wireless broadcastconsists of rekey items for keys in the leave path. Hence, the services. SKT is the approach in [28] where only shared keynumber 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 isevent, the rekey message consists of rekey items for critical applied to enhance LKH. Neither shared key tree nor criticalkeys in the enroll path. Hence, the number of encryptions is key is adopted in LKH. If shared key tree is adopted, keyO((1+ρ)(log2 ( n )+dlog2 ( de ))), where ρ is the ratio of critical e m management is based on the key forest as illustrated in Figurekeys 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 herekey message consists of rekey items for keys in the leave subscribes. If critical key is used, a key in an enroll path ispath and critical keys in the enroll path. Hence, the number of changed if and only if it is a critical key; otherwise, all keysencryptions is O((3 + ρ)(log2 ( n ) + dlog2 ( de ))). Considering e m in the enroll path need to be changed (as in the other olduser activities, the average rekey message size would be schemes). Table III lists four schemes representing different 1O( Λ (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 reuseper user, measures computation cost and power consumption is adopted, key management is based on the key forest asin a mobile device, since the device needs to decrypt new illustrated in Figure 4; otherwise, a key tree is created forkeys from rekey messages. Define the height of a key as its each program and a user is assigned to all trees correspondingdistance to the bottom of a tree. For example, if a tree has n to the programs he subscribes. If critical key is used, a keyusers, 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 (asin a rekey event. Hence, in a tree of n users, when a path in other schemes). Note that the well-known LKH is used asof keys need to be changed, the total number of decryptions n a base line (i.e. neither shared key nor critical key is adopted). log2is O( i=1 2i ) ≈ O(2n). In a leave event, because there are a) Settings: We assume that the server provides 50O( n de ) users under a to-be-changed DEK, the total number e m programs. In our experiments, the key forest consists of 300of encryptions for this DEK and its downward keys is O(2 nd ). m2 trees when shared key tree is adopted. Each tree represents aBecause d DEKs need to be changed in a leave event, O(2 nd ) m different option of subscriptions. We also assume that theredecryptions are committed by affected users. Similarly, in a are 10000 users (on average) subscribing to the services. The 2join event, the total number of decryptions is O(2ρ nd ). In m root graph in key forest was automatically generated according
  12. 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 Shiftto 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 managementthe program. In the worst case where a program is included in schemes by fixing λl = 1 and varying λs (x-axis) from 1 toall subscriptions, the depth for this program in root graph is 9. 9 as shown in Figure 9(c) and (d). Obviously, when the shiftMost programs had a depth of 8 or less, because the probability rate grows, the performance of SKT turns worse because ofthat a program is selected by more than 256 subscriptions is the extra overhead that is introduced in managing shared keyslow. At the same time, the tree depth is around 5, since 10000 when a user quits or adds some but not all of his subscribedusers 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 andfor 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 toof 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 isto their subscriptions in shared key schemes. Any user event higher in CASE III. Figure 9 also shows that KTR and STK arein shared key schemes was also mapped into the equivalent more sensitive to these types of major user events than eLKHevent 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/leaveas independent Poisson processes. We let λl = λj so the total rate increases. On the contrary, the average rekey message sizenumber 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 sharedis obtained by averaging the rekey cost over 3000 random user key tree, SKT reduces the rekey message size to around 60% toevents. Here, a user event is referred to an event in schemes 90% of LKH. By adopting critical keys alone, eLKH reducesthat adopt shared key tree. Such an event is mapped into the rekey message size to around 55% to 65% of LKH. Thisseveral user events in schemes that do not adopt shared key result also validates our claim that many keys in the enroll pathtree. 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 primarysubscriptions and major events (summarized in Table IV). In concerns for mobile users. We use the average number ofCase I and Case III, 80% of the users subscribe to multiple decryptions to measure these costs. Similar to the experimentsprograms and the other 20% only subscribe to one of the in the previous section, we vary the rates of major events toprograms. In Case II and Case IV, 20% of the users subscribe observe their impacts on decryption overhead. Figure 10 showsto 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 inare joins and leaves; while in Case III and Case IV, the major eLKH is around 80% of that in LKH, and KTR’s is aroundevents are shifts. In the simulations, we vary the rates for the 80% of SKT’s too. In all schemes, the number of decryptionsmajor 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 impactsof 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 eLKHKTR and SKT that adopt shared keys significantly outperforms in comparison with KTR. This can be explained as follows. InLKH, 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 theor unsubscribes to multiple programs. In contrast, LKH that leave and the enroll paths if they subscribe to the programs thatdoes not have shared keys requires a user needs to join or the user keeps subscribing to. As previously discussed, sharedleave multiple trees for multiple programs. Furthermore, KTR key schemes introduce extra rekey cost because they changeis better than SKT, because critical key in KTR allows the keys in two paths. On the contrary, in non-shared key schemes,