6.7 Stateless key revocation algorithms
6.7.2 SDR for membership revocation
STR may result in too many subsets being formed due to member revocation, and thus result in large communication overhead. SDR aims to lower the overhead by defining more subsets. Furthermore, each member belongs to more subsets, that is,OðNÞin this scheme, compared to STRðOðlog2NÞÞ[18]. Each subset in SDR is defined as the difference of two subsets in STR. Thus in SDR, a subsetSi;j¼SiSj, where SiÉSj. Further,Si andSj correspond to full binary subtrees of the group’s key tree. Figure 6.15 illustrates the concept of subset difference in key trees.
Membership revocation in SDR works as follows [18]. To revoke the membership of hosts in R, the GCKS computes a subset cover of the remaining members. First, it computes the directed Steiner tree STðRÞ of
Figure 6.13 Key distribution in STR.
the revoked members. It then identifies the maximal chains½Si1;Si2;. . .;Sik such that:
w S
i1;Si2;. . .;Sik1have exactly one child.
w S
ik is a leaf node or has two children.
w The parent ofS
i1is either the root or has two children.
For each such chain withk$2, the GCKS sends the group key encrypted with the subset keyKi1;ik.
Figure 6.16 illustrates membership revocation of C, D, and F in SDR. Following the key distribution algorithm described earlier, we identify two maximal chains in the figure, namely, ½S2;S5 and ½S3;S6;S13. Thus the
GCKS sends the group key encrypted with K2;5 andK3;13. By definition of
SDR key assignment, only the remaining members that is, A, B, E, G, and H, can decrypt the group key.
Revocation ofRmembers following SDR requires transmission of at most 2R1 encrypted keys. Each member belongs to OðNÞ subsets, and hence needs to search that space for the subset key required to decrypt the group
Figure 6.14 STR-based revocation.
key. This can be optimized to Oðlog2NÞ. Naor et al. [18] provide a detailed description and analysis of STR and SDR. Note that although SDR and STR appear to use batch processing, they can maintain strict forward and backward access control in immediate rekeying. However, immediate rekeying using SDR or STR is typically more expensive, compared to LKH and other similar stateful rekeying algorithms [19].
6.8
Summary
Group key management is one of the three building blocks of a multicast security solution. This chapter surveys key management algorithms that facilitate efficient distribution of a group key to very large and dynamic groups. We summarize the schemes proposed in the literature for varying application requirements.
The MARKS key distribution scheme is applicable to groups where member departure times are known a priori. The GCKS distributes seeds that
Figure 6.15 Subset difference illustrated.
members use to compute group keys. Seed distribution is done during member registration using a reliable one-to-one secure channel. No rekeying is necessary or possible in this scheme. Thus there is no need for a reliable multicast channel, but there is also no scope of recovery when seeds or keys are compromised. There is no limitation on members joining, departing, and rejoining the group, as long as the departure information is known at the time of join.
Some key management algorithms use a hierarchy of KEKs to achieve scalability. Updates to KEKs are protected by an older version of the KEK or other KEKs in the key tree. LKH, LKH+, OFT, and OFC are in this category. In LKH, the GCKS is responsible for key generation and distribution; thus it has the largest communication overhead in its class. LKH+ and OFC introduce key computation techniques to reduce communication overhead due to rekeying. Instead of sending all the new keys, the GCKS sends a message or some secret information to the members, and they are responsible for computing the new keys. OFT introduces a member
Figure 6.16 Membership revocation in SDR.
contributory key determination scheme. Members’ keys are used to compute the group key. Thus, OFT reduces communication overhead compared to LKH, but introduces additional computation overhead.
Hierarchical KEK-based schemes are dependent on reliable transmission of rekey messages. If a member fails to receive messages from a rekeying instance, it may not be able to decipher future rekey messages. On the positive side, these schemes enforce strict forward and backward access control. Further, they require no a priori knowledge of membership dynamics.
STR and SDR provide stateless rekeying; thus obviating the need for reliable transport of rekey messages. The GCKS partitions current group membership into several disjoint subsets; each of which is associated with a key. It then sends the group key encrypted with each subset key. Each member belongs to exactly one of those subsets during a rekeying instance, and can decrypt the group key. A major disadvantage of these schemes is that they operate on session membership, which can be quite large compared to group membership. Specifically, STR and SDR may be too expensive if immediate rekeying is the norm in rekeying a group.
In highly dynamic groups, it is possible to sacrifice strict forward and backward access control to reduce rekeying overhead, by batch processing of membership changes. For commercial applications, batch rekeying may be appropriate, with immediate rekeying only to remove compromised or misbehaving members. All the schemes described in this chapter support both batch rekeying and immediate rekeying.
References
[1] DeCleene, B., et al., ‘‘Secure Group Communications for Wireless Networks,’’ inProc. of the IEEE MILCOM, Vienna, VA, October 2001, pp. 113–117. [2] Setia, S., et al., ‘‘Kronos: A Scalable Rekeying Approach for Secure Multicast,’’
inProc. of IEEE Symposium on Security and Privacy, Oakland, CA, May 2000. [3] Yang, Y. R., et al., ‘‘Reliable Group Rekeying: Design and Performance
Analysis,’’ inProc. of ACM SIGCOMM, San Diego, CA, August 2001.
[4] Chang, I., et al., ‘‘Key Management for Secure Internet Multicast Using Boolean Function Minimization Techniques,’’ inProc. of IEEE INFOCOM, New York, March 1999.
[5] Zhang, X. B., et al., ‘‘Protocol Design for Scalable and Reliable Group Rekeying,’’ in Proc. of SPIE Conference on Scalability and Traffic Control in IP Networks, Denver, CO, August 2001.
[6] Valdvogel, M., et al., ‘‘The VersaKey Framework: Versatile Group Key Management,’’ IEEE JSAC Special Issue on Service Enabling Platforms For Networked Multimedia Systems, Vol. 17, No. 9, September 1999.
[7] Briscoe, B., ‘‘MARKS: Zero Side Effect Multicast Key Management Using Arbitrarily Revealed Key Sequences,’’ inProc. of First International Workshop on Networked Group Communication (NGC), Pisa, Italy, November 1999.
[8] Wong, C. K., M. Gouda, and S. S. Lam, ‘‘Secure Group Communications Using Key Graphs,’’IEEE/ACM Trans. on Networking, Vol. 8, No. 1, February 2000, pp. 16 – 30.
[9] Wallner, D., E. Harder, and R. Agee, ‘‘Key Management for Multicast: Issues and Architectures,’’ RFC 2627(informational), IETF, June 1999.
[10] Mittra, S., ‘‘Iolus: A Framework for Scalable Secure Multicasting,’’ inProc. of ACM SIGCOMM, Cannes, France, September 1997, pp. 217–288.
[11] Balenson, D., D. McGrew, and A. Sherman, ‘‘Key Management for Large Dynamic Groups: One-Way Function Trees and Amortized Initialization,’’ draft-irtf-smug-groupkeymgmt-oft-00.txt, IRTF, August 2000, work in progress.
[12] Canetti, R., et al., ‘‘Multicast Security: A Taxonomy and Efficient Construc- tions,’’ inProc. of IEEE INFOCOM, New York, March 1999.
[13] Blum, M., and S. Micali, ‘‘How to Generate Cryptographically Strong Sequences of Pseudo-Random Bits,’’ SIAM Journal of Computing, Vol. 13, No. 4, November 1984.
[14] Baugher, M., et al., ‘‘Group Domain of Interpretation for ISAKMP,’’ draft-ietf- msec-gdoi-04.txt, IETF, March 2002, work in progress.
[15] Wicker, Stephen B., and Vijay K. Bhargava (eds.),Reed-Solomon Codes and Their Applications, John Wiley & Sons, September 1999.
[16] Luby, M. G., et al., ‘‘Efficient Erasure Correcting Codes,’’ IEEE Trans. on Information Theory, Vol. 47, No. 2, February 2001, pp. 569–584.
[17] Setia, S., S. Zhu, and S. Jajodia, ‘‘A Comparative Performance Analysis of Reliable Group Rekey Transport Protocols for Secure Multicast,’’ in Proc. of Performance 2002, Rome, Italy, September 2002.
[18] Naor, D., M. Naor, and J. Lotspiech, ‘‘Revocation and Tracing Schemes for Stateless Receivers,’’ in Advances in Cryptology—CRYPTO, Santa Barbara, CA: Springer-Verlag Inc., LNCS 2139, August 2001.
[19] Chen, W., and L. R. Dondeti, ‘‘Performance Comparison of Stateful and Stateless Group Rekeying Algorithms,’’ inProc. of Fourth International Workshop on Networked Group Communication (NGC), Boston, MA, October 2002.
TEAM
FLY
Group security policy
T
he Merriam-Webster Dictionary [1] defines policy as ‘‘a definite course or method of actions selected among alternatives and in light of given conditions to guide and determine present and future conditions.’’ This definition serves the topic of group security policy very well, for there is a wide range of application requirements and an equally vast number of group security mechanisms.Applications require multicast security for privacy, data origin authentication, controlled access to group membership, and other similar requirements. The communication could be over the public Internet or intranets, with varying security threats. On the other hand, from the previous chapters, we know that there are several alternative mechanisms for enforcing privacy, key distribution, data origin authentication, etc. In this chapter, we discuss how application security requirements, business models, and service level agreements
(SLAs) can be translated into group security policy, and distributed and enforced using the group management entities introduced in earlier chapters.
Application requirements are generally specified at a very highlevel to begin with. For example, an application may specify the use of ‘‘strong symmetric key encryption for secure one-way transmission to an average of 10,000 members to enforce periodic billing.’’ Such service agreements (between say, content owners and service providers) must be translated into protocols and algorithms, and enforced using a secure multicast communications architecture.
159
C H A P T E R
7
Contents
7.1 Group security policy