6.4 OFT11 6.5 Batch processing of membership changes in key trees15
6.6 Reliable transport of rekey messages15
6.7 Stateless key revocation algorithms17
hierarchical subgrouping for efficient rekeying. At the cost of additional infrastructure, those schemes limit rekeying due to membership changes to the respective subgroup(s), instead of the whole group. But unless the subgroups are very small in size, the naı¨ve rekeying scheme is inefficient for subgroup rekeying as well. Scalable rekeying algorithm design and analysis is the focus of this chapter. We discuss the various proposed group key management algorithms proposed in the literature, and their suitability to practical application scenarios.
First, we consider applications in which the GCKS rekeys the group at fixed instances in the lifetime of the group, and knows each member’s departure time when the member joins. MARKS is a mechanism for efficient key distribution to such groups. Members receive random seeds from which they can generate the group encryption keys used during the period(s) of their subscription. Commercial applications such as satellite TV distribution with metered charging (e.g., per hour or per boxing round), may use this rekeying algorithm.
Next, we consider applications in which members may join or leave any time. For military and other highly secretive communications, the GCKS must rekey after each membership change to maintain strict forward and backward access control. However, for commercial applications, periodic or batch processing of membership changes may be sufficient, with provisions for immediate rekeying, to evict a member, for example. Thus, we need a general purpose group key management algorithm that can rekey a group immediately or periodically, as necessary.
A common technique in several proposed group key management schemes is to divide the members into subgroups, each of which has an associated secret key, and distribute the group key encrypted with the subgroup keys. Some of the proposed mechanisms update (some of ) the subset keys during rekeying, while others do not. Rekeying is stateful in schemes that update subset keys. In other words, stateful rekeying schemes use keys sent in past rekeying messages to protect current rekeying messages. This property requires reliable transport of rekey messages, even if the application does not need reliable data transmission.
One of the earliest and most popular group key management algorithms known as LKH, assigns each member a leaf position in a logical key tree for key distribution. Each internal node of the tree represents a subgroup that contains all the descendant leaf nodes as members. Each member knows the keys of all the subgroups it belongs to, or all the nodes in its path to the root in the key tree. Each internal node’s key is protected by its children’s keys during rekeying. When a member joins or leaves, the GCKS needs to change and distribute onlyOðlognÞkeys, for a group of sizen. Recall that the naı¨ve
rekeying algorithm requires the GCKS to encrypt and transmit the group keyOðnÞtimes.
Several improvements to LKH have been proposed in the literature. The first one, known as LKH+, improves join rekeying efficiency, and a second approach introduces a key construction scheme using one-way function chains (OFCs), for efficient rekeying to handle member departures. Note that in LKH and its enhancements mentioned so far, the group manager generates and distributes all the keys.
In another key management scheme based on OFTs, members receive secret information from the GCKS and compute some internal node keys in the tree, including the group key. OFT reduces leave rekeying communica- tion overhead, at the expense of additional computations at the GCKS and the members. Unlike MARKS, LKH, LKH+, OFT, or OFC require no a priori knowledge of group joins or leaves.
Recall that stateful rekeying algorithms, while efficient, require reliable transport of rekey messages irrespective of application requirements. Stateless rekeying algorithms get around this requirement by sending the group key encrypted with predistributed KEKs, in rekeying messages. In these schemes, only the group key is rekeyed and, therefore, rekey messages are independent of past rekey messages. When group membership changes, the remaining members are divided into several disjoin subsets, such that each member belongs to exactly one of the subsets. The GCKS then sends the new group key encrypted with the subset keys, predistributed to each of the subset’s members individually. Notice that subset keys themselves are not updated during rekeying.
In the rest of this chapter, we first discuss batch and periodic rekeying. Next, we discuss MARKS and the stateful rekeying algorithms LKH, LKH+, OFC, and OFT. We then discussion stateless rekeying mechanisms based on subset trees and subset difference. Next, we discuss reliable transport of rekey messages. We conclude the chapter with a summary and a discussion on the applicability of group key management algorithms.
6.1
Batch and periodic rekeying
Group rekeying serves two major purposes. First, secret keys need to be refreshed after they have been used to encrypt a certain amount of data, or after they have been in use for a given amount of time, to thwart cryptanalysis. Second and specific to groups, rekeying is used to ensure that only current members can decrypt data. In other words, the GCKS may change keys to disallow new members from getting access to past data
(backward access control), and departed or evicted members from getting access to future data (forward access control). Rekeying to enforce forward and backward access control is more difficult, since it needs to deal with membership changes, and is more frequent in large or dynamic groups. Therefore, we limit the rest of our discussion to rekeying due to membership changes.
Some multicast applications, for example, military communications and conferencing, may require that the group key be changed immediately after each membership change, to enforce strict forward and backward access control. It may even be necessary to stop data flow while such groups are being rekeyed [1].
In large and highly dynamic groups, such an immediate rekeying policy may result in frequent rekeying, and might overwhelm the GCKS computationally [2]. Rekey communication overhead may also be seen as too costly for efficient operation of the group. In such cases, it is possible to relax forward and backward access control requirements slightly, to reduce rekeying overhead. A GCKS may choose to rekey a group periodically, or process group membership changes in batches [2–5]. Commercial applica- tions such as Internet or satellite TV distribution may use batch or periodic rekeying, employing immediate rekeying only in exceptional circumstances, for example, when evicting misbehaving members.
Figure 6.1 illustrates immediate, periodic, and batch rekeying. In immediate rekeying, the GCKS spawns a rekeying instance each time the group membership changes. In batch rekeying, the GCKS rekeys after a few group membership changes. The GCKS may choose to rekey, for example, afterrgroup membership changes or, alternatively, afterrjoins orrleaves. In Figure 6.1, the GCKS rekeys after four membership changes. Finally, the GCKS may rekey everyttime units, irrespective of membership dynamics. We refer to this final type of rekeying as periodic rekeying.
6.1.1 Trade-offs in batch rekeying
Batch or periodic rekeying comes at the expense of relaxing forward and backward access control requirements. More precisely, note that when a member departs, the GCKS does not rekey immediately. Instead, it waits until the next rekeying instance (refer to Figure 6.2). But this is against the forward access control rule. Due to batch rekeying, departing members continue to get access to group data for a brief period (until the next rekeying instance) after they leave.
Fortunately, joins in batch rekeying mode can be processed without affecting strict backward access control. The GCKS has two options. The first
Figure 6.1 Immediate, periodic, and batch rekeying.
Figure 6.2 Batch rekeying and forward access control.
approach is a variation of LKH+ [6] (see Section 6.3.4). The GCKS applies a one-way function to the group key, and sends the new group key to the new member. The existing members receive a notification about the application of the one-way function, and compute the new group key. New members become part of the key tree only at the next rekeying instance, as determined by the batch or periodic rekeying scheme. In the second approach, joining members are put on hold until the next rekeying instance. They cannot decrypt group data until then.
6.2
MARKS
MARKS is a mechanism for key distribution to a group of members who depart at prespecified time points [7]. Consider a secure group in which members may join the group any time during the group, but the departure time must be known at the time of join. Further assume that the GCKS knows how long the secure group communication lasts.
To manage such secure groups, the GCKS divides the group’s life into
ttime periods. Each time period has a corresponding group key. In all, there aret group keys,K1;K2,. . .;Kt. Each member joins the group and requests to be a member between time periods say,t1 andt2. The GCKS supplies the the group keys, Kt1;Kt1þ1, . . ., Kt21, Kt2, to that member. MARKS [7]
presents an efficient mechanism for such key distribution using a hierarchy of seeds.
First we describe the mechanism used to construct a binary hierarchy of seeds. The GCKS starts with a randomly generated seed as the root of the hierarchy. We compute two seeds corresponding to the root’s children by applying two different one-way functionsgL andgR. The GCKS continues this process until the number of leaves in the hierarchy of seeds ist, that is, the number of periods in the group. Figure 6.3 depicts the seed generation mechanism. The GCKS generates the root seed s0;0 and uses gL and gR to compute s1;0 and s1;1, corresponding to the left and right children,
respectively. In the figure, the seed name si;j represents the jth seed at depthi.
During registration, the GCKS sends the seeds necessary and sufficient for the member to compute the group keys that the member is authorized to receive. The seed hierarchy facilitates efficient distribution of group keys to members. For example, to allow a member to remain in the group for the entire duration, the GCKS needs to just send the root seed. In general, given a seed corresponding to a node in the hierarchy, one can compute the
seeds of all descendant nodes. In Figure 6.3, say member A is authorized to receive K2;K3;. . .;K6. Instead of sending the five group keys, GCKS sends
the three seeds,s2;1,s2;2ands3;6.
Notice that all key distribution in MARKS is done during the registration protocol. The advantage is that all the keys are transported over unicast; thus it is easy to ensure reliable delivery. The disadvantage, however, is that we cannot eliminate a member without rekeying the entire group, which is very inefficient in large groups.
We conclude this section with an analysis of MARKS key distribution. The minimum number of seeds that a GCKS could send a member is one seed. The single seed could correspond to a leaf node, which reveals one group key, or an internal node, which reveals 2hgroup keys, wherehis the height of the subtree. The maximum number of seeds are sent to a member who is authorized to receive all group keys except the first and the last one, that is,K2,K2,. . .,Kt1. The GCKS needs to send the required seeds without
revealing K1 and Kt. Thus it cannot reveal the ancestors ofsl;0 or of sl;2l1.
Instead, the GCKS sends the seeds of siblings of the ancestors ofsl;0sl;2l1. In
all, the GCKS sends 2 logðt=2Þ seeds. The worst-case one-way function computation overhead applies to a member who stays in the group for the entire duration. It receives the root seed and needs to compute all the seeds in the hierarchy, that is, 2t2.
Figure 6.3 Key distribution in MARKS.
6.2 MARKS