CN101286838A - Design of a Large-Scale Dynamic Multicast Security Architecture - Google Patents

Abstract

The present invention relates to a dynamic security multicast system framework under a large-scale network environment, and is characterized in that a set of new dynamic security multicast system framework is designed, and the overall multicast is divided into different areas, so that each group After the member changes, only the group key is updated, which avoids the system overhead caused by the overall group key update caused by frequent group member changes, and realizes flexibility in key management and data distribution in each sub-domain The expansion mechanism of Kerberos is implemented, and a secure authentication mechanism is implemented on the basis of Kerberos, and then the multicast group is managed from the perspective of control security and data security. According to the characteristics and requirements of the IPv6 protocol, a relatively complete set of group key management mechanism is implemented, which is suitable for the security and practicality of most multicast applications in the second generation China Education Research Network (CERNET2) and similar network environments. sexual demands.

Description

Design of a Large-Scale Dynamic Multicast Security Architecture

technical field

The invention relates to a large-scale dynamic security multicast system framework under a large-scale network environment. According to the characteristics and requirements of the IPv6 protocol, a relatively complete set of group key management mechanism is implemented, which is suitable for the security and practicality of most multicast applications in the second generation China Education Research Network (CERNET2) and similar network environments. sexual demands.

Background technique

The rapid development and popularization of the Internet has provided a strong market force for the development of multicast services, and multicast is becoming increasingly popular.

Multicast is a multi-receiver-oriented communication method based on UDP/IP protocol. Compared with unicast, it can effectively save server resources and network bandwidth. The Internet Group Management Protocol (IGMP) is used to manage multicast. IGMP does not provide member access control. Users can send IGMP member reports to routers as long as they know the multicast address used by specific services, join the group without review and obtain a copy of UDP data. Therefore, the existing multicast communication does not guarantee data security. Protecting the confidentiality of multicast data and establishing a secure communication system are the main goals of secure multicast research.

IP multicast has the following characteristics:

(1) All members can receive data packets sent to the multicast address;

(2) Multicast provides an open group mode, so that group members are not sure which member the data comes from;

(3) Any host can send data packets to this multicast address.

These three characteristics reflect that multicast technology lacks access control at the network layer in essence, which can be summarized as lack of control over joining a group, lack of control over data sent and received by group members, and lack of verification of the authenticity of data sources.

Since there are inherent insecurity problems in multicast, as a secure multicast architecture, it is necessary to provide corresponding security services for these problems. Group security policy, group key management, data source authentication, group member management and access control, and the confidentiality of multicast data are important contents of the architecture to ensure security.

In terms of the design of the multicast architecture, the existing work mainly includes:

Patent CN03153932.7 discloses a method for realizing group security association sharing. In this patent, the multicast source node only creates a security association with the first node in the group that initiates an SA creation request, and generates a shared CHILD_SA. When other nodes in the group initiate an SA creation request to the multicast source node, the multicast source node notifies The node that initiates the SA creation request obtains the shared CHILD_SA from the node that has generated the shared CHILD_SA. The method can support the adoption of a shared security association in the multicast communication under the IPsec framework. For member nodes in a multicast group, before each communication, a shared CHILD_SA or a connection IKE_SA with other nodes must first be created. When the number of nodes is large, performance and efficiency will be greatly affected, so it is not suitable for large-scale groups. broadcast application.

An IETF multicast security architecture is introduced in RFC3740. This architecture has the function of providing many aspects of security guarantee for large-scale multicast group communication, and takes into account the impact of scalability on large-scale multicast groups. However, the cost of security processing due to the change of group members in the IETF structure is relatively high. Although the impact can be reduced by adding distributed multicast groups, the cost of multicast group deployment is correspondingly increased; when managing multiple multicast groups When , there is additional communication overhead for peer entities to communicate to ensure security services between multicast groups.

Based on the IETF structure, this patent improves and designs a new dynamic security multicast system architecture, which divides the overall multicast into different areas, so that only the group key is updated after the members in each group change. It avoids the system overhead brought by the overall group key update caused by frequent group member changes, realizes a flexible expansion mechanism for key management and data distribution in each sub-domain, and realizes on the basis of Kerberos Secure authentication mechanism, and then manage the multicast group from the viewpoint of control security and data security. According to the characteristics and requirements of the IPv6 protocol, this patent implements a relatively complete group key management mechanism, which is suitable for the security and practical requirements of most multicast applications in CERNET2 and similar networks.

Contents of the invention

The purpose of the present invention is to define different areas, and various mutually independent areas can use different group key management schemes. When the members in a certain leaf domain in the system change, only the key in this domain needs to be updated. Yes, greatly reducing the overhead associated with rekeying the system as a whole.

The large-scale dynamic multicast security system framework design of the present invention includes: a system framework design method;

The large-scale dynamic multicast security system architecture design of the present invention includes: a key management scheme structure;

The design of the large-scale dynamic multicast security system framework of the present invention includes: a temporary cross-connection domain server strategy.

This system framework divides the overall multicast domain into two parts: "trunk" and "leaf":

A. Backbone domain: composed of key generator, key manager, node group controller, policy and authentication server, router, etc. The backbone domain constitutes a key management platform, and in a multicast network, it includes protocols related to security (eg, Kerberos authentication protocol, etc.). The backbone domain is bounded by node group controllers and key servers and does not contain any member hosts.

B. Leaf domain: network infrastructure platform, including entities used to build the network, composed of multicast members, subgroup controllers, and various protocols and implementation components for IPv6-based multicast networks. Each leaf domain is associated with a border node group controller and key server, and different leaf nodes may have different group key management schemes.

According to the design of the system framework, the group key management scheme includes a strategy and six protocols for multicast key security: multicast group security policy, multicast group creation protocol, group member registration protocol, group member logout protocol, group member Eviction protocol, group key update protocol, group revocation protocol.

When the present invention processes non-audio and video data, the system can fully meet performance requirements. For video multicast applications based on one-to-many, the data sending terminal (assumed to be A) can be directly connected to the backbone network across the node group controller, thereby reducing the process of data encryption and decryption once, which can basically meet application requirements without compromising security.

This patent can only update the group key in the leaf domain when the members in the system framework change, which reduces the overall system overhead, improves efficiency, and realizes a flexible expansion mechanism, which can well meet large-scale or even super-large-scale Network multicast security application requirements.

Description of drawings

Figure 1 is a large-scale dynamic secure multicast group key management structure diagram;

Fig. 2 Group key management scheme structure diagram;

Figure 3 is a schematic diagram of a temporary crossover domain server strategy;

Fig. 4 is a schematic diagram of dynamic multicast operation under this framework.

Detailed ways

The technical scheme of the present invention will be described in detail below in conjunction with the accompanying drawings.

Figure 4 shows a schematic diagram of dynamic multicast operation under this architecture:

After the group owner or creator (GO) interacts with the policy server (PS) (through steps 1 and 2) to obtain the policy token (PT), it applies to a certain group of controllers and key servers (GCKS) on the backbone domain for creation A multicast group instance (step 3). The GCKS is called an initial GCKS (I-GCKS), and the I-GCKS publishes secure multicast content with the group key in the backbone domain in the backbone domain.

The group member (GM) who needs to join the multicast group sends a join request (RTJ) message to the GCKS that manages the leaf domain (steps 7 and 8), or submits a join application to the GCKS through the S-GCKS that manages the subgroup (steps 5 and 8). 6, 9, 10).

The GM that exits the multicast group sends an exit request (RTD) message to the GCKS that manages the leaf domain, or submits a logout application to the GCKS through the subgroup controller and key server (S-GCKS) that manages the subgroup.

GO generates a new PT according to the eviction GM ID, and GCKS sends a refusal to join (R_J) message to the eviction member according to the PT.

On the basis of the change of group members, GCKS performs the group key update operation, but the group key update operation caused by the group member change in each leaf domain will be limited to the leaf domain, and will not cause other leaf domains and backbone domains. Performance drops.

Each GCKS in the backbone domain performs membership update and timing update operations under the control of the I-GCKS (step 4). Group key updates in the backbone domain are restricted to the backbone domain.

After the secure multicast content in the leaf domain is sent to the GCKS that manages the leaf domain, GCKS decrypts the content with the group key in the leaf domain, encrypts it with the group key of the backbone domain, and publishes it in the backbone domain. After each GCKS in the backbone domain receives the multicast data, it decrypts it with the group key in the backbone domain, encrypts it with the group key in the leaf domain, and publishes it in the leaf domain (step 11).

Claims (5)

1 A large-scale dynamic multicast security architecture design, characterized in that, in a large-scale network system, according to the characteristics and requirements of the IPv6 protocol, the overall multicast domain is divided into two parts, "trunk" and "leaf", so that When the multicast members in the system framework change, only the group key in the leaf domain is updated, which reduces the overall system overhead, improves efficiency, and implements a flexible expansion mechanism, which can well meet the needs of large-scale or even ultra-large-scale network groups. broadcast security application requirements. 2 A kind of large-scale dynamic multicast security architecture design as claimed in claim 1, characterized in that, the method of dividing the whole multicast domain into two parts of "backbone" and "leaf" is as follows: A. Backbone domain: composed of key generator, key manager, node group controller, policy and authentication server, router, etc. The backbone domain constitutes a key management platform, and in a multicast network, it includes protocols related to security (eg, Kerberos authentication protocol, etc.). The backbone domain is bounded by node group controllers and key servers and does not contain any member hosts. B. Leaf domain: network infrastructure platform, including entities used to build the network, composed of multicast members, subgroup controllers, and various protocols and implementation components for IPv6-based multicast networks. Each leaf domain is associated with a border node group controller and key server, and different leaf nodes may have different group key management schemes. 3 A large-scale dynamic multicast security architecture design as claimed in claim 2, characterized in that the group key management scheme includes a strategy and six protocols for multicast key security: multicast group security policy, Multicast group creation protocol, group member registration protocol, group member cancellation protocol, group member expulsion protocol, group key update protocol, group revocation protocol. 4. A large-scale dynamic multicast security architecture design as claimed in claim 1, characterized in that, for video multicast applications based on one-to-many, the data sending terminal (assumed to be A) can be crossed The node group controller is directly connected to the backbone network, thereby reducing the process of data encryption and decryption once, which can basically meet the application requirements without affecting the security. 5 A large-scale dynamic multicast security architecture design as claimed in claims 1 to 4, characterized in that the dynamic multicast operation process under this framework is as follows: After the GO interacts with the PS (through steps 1 and 2) to obtain the PT, it applies to a certain GCKS on the backbone domain to create a multicast group instance (step 3). The GCKS is called an initial GCKS (I-GCKS), and the I-GCKS publishes secure multicast content with the group key in the backbone domain in the backbone domain. The GM that needs to join the multicast group sends an RTJ message to the GCKS that manages the leaf domain (steps 7 and 8), or submits a joining application to the GCKS through the S-GCKS that manages the subgroup (steps 5, 6, 9, and 10). The GM that exits the multicast group sends an RTD message to the GCKS that manages the leaf domain, or submits a logout application to the GCKS through the S-GCKS that manages the subgroup. GO generates a new PT according to the eviction GM ID, and GCKS sends an R_J message to the eviction member according to the PT. On the basis of the change of group members, GCKS performs the group key update operation, but the group key update operation caused by the group member change in each leaf domain will be limited to the leaf domain, and will not cause other leaf domains and backbone domains. Performance drops. Each GCKS in the backbone domain performs membership update and timing update operations under the control of the I-GCKS (step 4). Group key updates in the backbone domain are restricted to the backbone domain. After the secure multicast content in the leaf domain is sent to the GCKS that manages the leaf domain, GCKS decrypts the content with the group key in the leaf domain, encrypts it with the group key of the backbone domain, and publishes it in the backbone domain. After each GCKS in the backbone domain receives the multicast data, it decrypts it with the group key in the backbone domain, encrypts it with the group key in the leaf domain, and publishes it in the leaf domain (step 11).

Images