Distributed group key management for multicast security

Details Distributed group key management for multicast security Distributed group key management for multicast security

1999-06-11

2003-06-24

Barron, Gilberto (Department: 2132)

Electrical computers and digital processing systems: support

Multiple computer communication using cryptography

Having particular address related cryptography

C713S162000, C380S277000, C380S278000, C380S279000, C380S282000

Reexamination Certificate

active

06584566

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The invention relates to the field of networks. More specifically, the invention relates to secure multicast communications.
2. Background Information
Many network applications are based upon the client-server paradigm and make use of unicast (point-to-point) packet and/or cell delivery. Many emerging applications (e.g., teleconference, real-time information services, pay per view, distributed interactive simulation, collaborative work, etc.), on the other hand, are based upon a group communications model. That is, they require packet and/or cell delivery from one or more authorized sender(s) to a large number of authorized receivers. Thus, multicast is an Internetwork service that provides efficient delivery of data from one or more sources to multiple recipients. It reduces sender transmission overhead, network bandwidth requirements, and the latency observed by receivers. This makes multicast an ideal technology for communication among a large group of principals.
Although multicast has been very successful at providing an efficient data delivery service to large groups, it has proven much more difficult to extend other features to multicast in a scalable manner. In particular, the need to secure electronic information has become increasingly apparent. Multicast, however, does not fit the point-to-point model of most network security protocols which were designed with unicast communications in mind.
The fundamental task of any network security protocol is to allow authorized principals to communicate securely over an insecure network where an attacker is assumed to be able to read, modify, or delete the raw communications. Typically, this is achieved by creating a security association between the authorized principals through authentication and key exchange. The security association defines a set of keying material shared only by the authorized principals that can then be used for a variety of security objectives such as authentication, confidentiality and integrity. While the concept of security associations is well understood in the context of unicast, the multipoint-to-multipoint model of multicast inherently changes the meaning and management of security associations.
Consider what happens under unicast. Two principals decide to communicate and employ a (unicast) network security protocol to setup a security association between them. This association then allows the pair to communicate securely. The security association is negotiated between the two principals, after which they employ the security methods (e.g. cryptographic algorithms) described in the negotiated security association.
In the case of multicast, there are multiple principles that are involved in the group communications, and thus the negotiations among them to achieve a common security association is a more complex problem.
A multicast security protocol must ensure that a principal is only allowed to participate during those periods when it is authorized to do so. The security association and thus the common group keying material (CGK in short) it defines must be changed on each join and leave. This change is to ensure that a joining entity is not able to access previously multicast data and a leaving entity is not able to continue to access data multicast after it leaves the group. The process of changing the common group key is commonly referred to as re-keying.
Note that we are not implying that the common keying material must be changed on each and every join or leave; that is a policy decision. However, a multicast security protocol must be prepared to change the common keying material on each and every join or leave to protect the integrity of the current group.
Specifically, when a member joins the group, the common group keying material (CGK) must be replaced and a new set of common group keying material (CGK′) must be generated and distributed to the current group members as well as the joining member. There are a number of ways to do this. One simple method that works is to multicast CGK′ to the current members using CGK to secure the transmission. Separately, the joining member can be apprised of the new key by unicasting CGK′ to it using some unicast secure channel (e.g., the one used to request the join).
A member leaving the group creates a much more difficult problem. As with joins, a new set of common keying material must be generated, but in this case it must be distributed to the remaining members in the group and there is no efficient means to communicate CGK′ to them alone because there is no secret which is shared with them alone (and not also including the leaving member). Indeed, CGK′ is exactly this secret.
Given the chicken and egg situation, the keying material associated with each remaining member individually (i.e., unicast keys) must somehow be utilized to securely communicate CGK′. For example, using these unicast keys, a separate copy of CGK′ could be sent to each one of the remaining members. The basic problem is that each of the members must be considered individually on each leave and this is extremely inefficient if the group is large or has a highly dynamic membership.
Therefore, changes in group membership involve “heavy-duty” tasks not only from the standpoint of authentication and approval of the join/leave request (which in and of itself may be time consuming requiring database accesses and cryptographic operations), but also form the distribution of new group keying material (especially on leaves).
These scalability problems are especially troublesome because many proposed applications of multicast have an ongoing need to maintain the integrity of the group for economic and other reasons. Of course, they also tend to have large group sizes and can often have highly dynamic group memberships. For example, a large class of multicast applications are information dissemination services (e.g., data, audio, and videocasts). These applications can have large and dynamic groups especially when combined with the idea of micro-commerce and a “buy-on-the-fly” model for gaining access to content. Multi-player games and other interactive simulations also may have a need to ensure fairness among participants as they join and leave. Finally, consider group key management for services normally accessed using unicast. For example, one existing company has a service that provides continuously updated airline flight information. This company charges for this service on a per-minute basis and so its group is large and constantly changing. Many other news and information retrieval services have a similar business model and thus exhibit similar usage patterns.
Various proposals have been made regarding techniques for re-keying, S. Mittra, “The Iolus Framework for Scalable Secure Multicasting,” in Proceedings of ACM SIGCOMM'97, pp. 277-288, ACM 1997. However, such proposals have various drawbacks.
BRIEF SUMMARY OF THE INVENTION
A method and apparatus for distributed group key management for multicast security is described. According to one aspect of the invention, an initiator key server distributes to a plurality of key servers a first key set including an initial common group key and a replacement common group key. The initial common group key, but not the replacement common group key, is initially distributed to clients of the plurality of key servers that are currently members of a multicast group as a current common group key for multicast messages. Responsive to a need to re-key the current common group key of the multicast group, each of the key servers subsequently distributes to their clients that are currently members of the multicast group the previously distributed replacement common group key as the current common group key.


REFERENCES:
patent: 4972472 (1990-11-01), Brown et al.
patent: 5748736 (1998-05-01), Mittra
patent: 6049878 (2000-04-01), Caronni et al.
Wong, et al.,Secure Group Communications Using Key Graphs, Department of Computer Sciences, Univ. of Texas, 1998,

Affiliated with

Also associated with

Rating

Distributed group key management for multicast security does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Distributed group key management for multicast security, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Distributed group key management for multicast security will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3117163