WO2011063557A1 - Multicast key management method and system in a wireless metropolitan area network - Google Patents

Abstract

A multicast key management method and system in a wireless metropolitan area network are provided, the method includes the following steps: 1) multicast private key distribution: 1.1) an applicant entity transmits a multicast private key application packet to a responder entity; 1.2) the responder entity transmits a multicast private key response packet to the applicant entity; and 1.3) the application entity transmits a multicast private key confirmation packet to the responder entity; 2) multicast key encryption key distribution or update: 2.1) the responder entity broadcasts a multicast key encryption key broadcast packet to all applicant entities; 2.2) the applicant entity decrypts the multicast key encryption key from the multicast key encryption key broadcast packet. Therefore, the problems of low security of multicast key management basic keys and low efficiency of multicast key update in the wireless metropolitan area network are solved.

Description

 Wireless metropolitan area network multicast key management method and system

Field of invention

 The present invention relates to the field of wireless communication technologies, and in particular, to a wireless metropolitan area network multicast key management method and system.

Background technique

 The security of wireless networks is far more serious than wired Ethernet. The IEEE Institute of Electrical and Electronics Engineers has introduced security mechanisms in the 802.11 and 802.16 series of standards to enhance the security of wireless LANs and wireless metropolitan area networks, and to provide secure access from mobile terminals MT to base station BS. China also in May 2003. The national standard for wireless local area networks, GB15629.il, has been enacted, commonly referred to as the WAPI (Wireless Local Area Network Authentication and Privacy Infrastructure) protocol. Broadband Wireless Multimedia The BWM network combines data communication and broadcast communication. It is a new wireless network architecture that also needs to address security access and secure communication.

 Whether it is a wireless network or a wired network, there are two modes of communication: point-to-point communication and multicast (or broadcast). Secure multicast needs to ensure the legality and confidentiality of multicast entities and messages. At the same time, it also needs certain restrictions on the terminals that receive multicasts, ensuring that only authorized terminals can correctly read the multicast messages. It is required that the multicast key security distribution problem must be effectively solved first. How to effectively manage multicast keys is one of the key issues to solve secure multicast.

 The IEEE 802.il standard uses the Wired Equivalent Privacy Protocol (WEP) to implement WLAN security. Its key management is very simple, that is, manually setting a shared key between the mobile terminal and the access point. At this time, IEEE802.11 has not yet dealt with multicast key management issues.

There is a serious security hole in the WEP encryption protocol. The IEEE proposed the 802.lli standard to try to solve the security problem of WEP. China has also proposed the WLAN China National Standard GB15629.il, the WAPI protocol, which overcomes some of the shortcomings of WEP. Although 802.lli and WAPI have different authentication mechanisms, they are very similar in terms of multicast key management: the distribution of the multicast session key GSK is encrypted and distributed by the previously established unicast session key USK. That is to say, the base station selects a multicast session key, and then encrypts it with the unicast session key shared by each terminal and sends it to the phase one by one. The terminal should be. After receiving the encrypted multicast session key message, each terminal can decrypt the multicast session key by using the unicast session key shared by the terminal with the base station. When each terminal receives the same multicast session key, the base station can perform secure multicast. If you want to update the multicast session key, you need to repeat the above process.

 The disadvantage of this method is that the efficiency is relatively low, especially when the multicast session key is updated, the base station needs to repeat the above multicast session key distribution process: The base station selects a multicast session key and shares it with each terminal by itself. The unicast session keys are encrypted and sent to the corresponding terminals one by one.

 In the wireless metropolitan area network standard proposed by the IEEE in the United States, namely the 802.16 standard, its multicast key management borrows from 802.11i. However, in the 802.16e standard proposed by IEEE, a new design concept is proposed for the security multicast key management problem. The multicast key encryption key GKEK is introduced, and the multicast key encryption key GKEK and group are established. Two-level management method for broadcasting session key GSK. The idea is as follows: First, the base station encrypts the GKEK one by one by using the unicast session key established with each terminal and sends it to the corresponding terminal; after receiving the message, the terminal decrypts the GKEK by using the unicast session key; then, the base station utilizes GKEK The GSK is encrypted as a key and broadcast to all terminals; each terminal with GKEK can get the same GSK. At this point, the multicast session key process is complete. The same procedure is used when performing multicast session key update: The base station uses GKEK as the key to encrypt the GSK and broadcasts to all terminals.

 The disadvantages of the multicast key management method in 802.116e are: Time synchronization is adopted, and state management is complicated; the activation and deactivation of new keys are time-dependent, and maintaining a synchronous clock in a distributed system is complicated.

 In response to this situation, China has proposed a multicast session key management method with similar ideas in the field of wireless metropolitan area network and broadband wireless multimedia.

 But this method has the following disadvantages:

 1. Although the GKEK and GSK management methods are adopted, their GKEK and GSK are the same for all terminals, and they do not have the advantages and features of key hierarchical management;

 2. Because GKEK is the same for all terminals, it will make it easier for the terminal to leak GKEK to other terminals, and the security is not high;

3. There is no update method related to GKEK. Because GKEK is the base key for all terminals It is the same, the security is not high, therefore, it is necessary to change the GKEK frequently;

 4, does not provide a valid GKEK update method, can only be the same as the multicast key encryption key distribution method, the base station encrypts one by one, and sends them to the terminal one by one;

 5. In the above case 4, such an update may take a long time, and the length of time is determined by the number of terminals. This may result in a multicast outage when the key is updated.

Summary of the invention

 The invention solves the problem that the base key of the wireless metropolitan area network multicast key management is not high and the multicast key update is low in the background art, and provides a wireless metropolitan area network multicast key management method and system.

 The technical solution of the present invention is: The present invention is a wireless metropolitan area network multicast key management method, which is special in that: the method comprises the following steps:

 1) Multicast private key distribution:

 1.1) The requester entity sends a multicast private key request packet to the responder entity;

 1.2) The responder entity sends a multicast private key response packet to the requester entity;

 1.3) The requester entity sends a multicast private key confirmation packet to the responder entity;

 2) Multicast key encryption key distribution (or update):

 2.1) The responder entity broadcasts the multicast key encryption key broadcast packet to all requester entities; 2.2) The requester entity decrypts the multicast key encryption key from the multicast key encryption key broadcast packet.

 The above step 1) also includes the step of establishing system parameters by the responder entity.

 The above system parameters include: Set and ((3⁄4,·) are cyclic groups with two orders of p, which are prime numbers, and satisfy the Diffie-Hellman calculation problem as a difficult problem; let (^ the generator element; let e be the sum (The bilinear transformation on 3⁄4, ie ^ ^ (^→(3⁄4; is a one-way hash function).

 Before the above step 1), the requester entity and the responder entity perform authentication and unicast key negotiation; establish a shared unicast session key.

 The multicast private key request packet in the above step 1.1) includes the following contents:

AE RE N1 MIC among them:

 AE field: identity information of the requester entity;

 RE field: identity information of the responder entity;

 N1 field: a random number generated by the requester entity;

 MIC field: Indicates that the MIC value is obtained for all fields before the field, where the integrity check key is USKL

 In the above step 1.2), after the responder entity receives the multicast private key request packet, the MIC is recalculated and compared with the received MIC, if not equal, the packet is discarded; if equal, the multicast private is constructed. The key response packet is sent to the requester entity.

The multicast private key response packet in step 1.2) above includes the following:

 among them:

 RE field: identity information of the responder entity;

 AE field: identity information of the requester entity;

 N1 field: a random number generated by the requester entity;

 N2 field: a random number generated by the responder entity;

 C field: ciphertext information of the multicast private key GKx distributed by the responder entity to the requester entity, the encryption key is USKE;

 MIC field: Indicates that the MIC value is obtained for all fields before the field, where the integrity check key is USKL

 The calculation process of the above C field is as follows:

1.2.1) The responder entity randomly selects wl greater than or equal to 2) different elements v ₀ , Vj,..., ^^? ; and the element ^^^^, at the same time, randomly construct the W-1 secret polynomial / (Jt) eZ _f W. Next, calculate the following information: 2 =/(0)/ ⁾ £(7 ₁ and =/( ) ³ ( = 0,1,.

= f(AE)(Q_{1 +}Q₂) ; 1.2.2) For the requester entity,

= f(AE)(Q _{1 +} Q ₂ ) ;

1.2.3) C = (Q _K , Q ₁ , Q ₂ , v ₀ ,..., v _n _ ₂ , V ₀ ,...,V _n _ ₂ )\\E(USKE;GK _x ) ₀

In step 1.3) above, when the requester entity receives the multicast private key response packet, the MIC is recalculated. And comparing with the received MIC, if not equal, discarding the packet; if equal, determining whether N1 is a random number selected by the requester entity; if not, discarding the packet, and if so, decrypting with the key USKE (fA3⁄43⁄4 GQ obtains the multicast private key GKx, and finally, constructs a multicast private key confirmation packet to send to the responder entity.

The multicast private key confirmation packet in step 1.3) above includes the following contents:

 among them:

 AE field: identity information of the requester entity;

 RE field: identity information of the responder entity;

 N2 field: a random number generated by the responder entity;

 MIC field: indicates the MIC value of all the fields before the field and the decrypted multicast private key GKx, where the integrity check key is USKI;

 In step 1.3) above, when the responder entity receives the multicast private key confirmation packet, it recalculates the MIC and compares it with the received MIC; if not, discards the packet; if equal, determines whether N2 responds The random number selected by the entity; if not, the packet is discarded, and if so, the multicast private key is successfully distributed.

The multicast key encryption key broadcast packet in the above step 2.1) includes the following contents:

 among them:

 RE field: identity information of the responder entity;

 Flag field: indicates the broadcast category;

 Time field: Current system time, used to distinguish whether it is duplicate information;

 C1 field: ciphertext information of the multicast key encryption key broadcast by the responder entity;

MIC field: Indicates that the MIC value is obtained for all fields preceding the field, where the integrity check key is GKEKI (the integrity check key derived by the multicast key encryption key). The above C1 field is calculated as follows: Assuming that the responder entity selects the multicast key encryption key GKEKe G ₂ , the responder entity randomly selects the integer reZ: and computes as follows:

= (rP,rQ_l,e(Q_K,Q₂yGKEK,rV₀,...,rV_n_₂) 上述步骤 2.2) 中当请求者实体接收到该分组后， 按如下方法解密出组播 密钥加密密钥： Cl =

= (rP,rQ _l ,e(Q _K ,Q ₂ yGKEK,rV ₀ ,...,rV _n _ ₂ ) In step 2.2) above, when the requester entity receives the packet, it decrypts the multicast as follows: Key encryption key:

2.2.1) First, the requester entity constructs a collection using public information and its own device identification information:

T = {e ₀ , e ₁ ,...e _n _ ₁ } = {v ₀ ,...,v _n _ ₂ ,AE]

2.2.2) Then, and for each e Γ calculate σ^ _Γ = Π -;

2.2.3) Next, calculate the multicast key encryption key as follows:

e(Q ,Q _K )U .

 GKE =

{Q, + Q ₂ , ∑ a _{ei T} V;)e(G _e ^ _T GK _x , P') In the above step 2.2), after the requester entity calculates the multicast key encryption key, the integrity school is derived. The key is verified and the encryption key is used; then, the MIC is recalculated using the integrity check key to determine whether the packet is valid; and at the same time, it is determined according to the Time field whether the system repeats the message.

 Step 2) above also includes step 3) multicast session key distribution (or update):

 3.1) The Responder entity broadcasts a multicast session key broadcast packet to all requester entities;

 3.2) The requester entity decrypts the multicast session key from the multicast session key broadcast packet.

The multicast session key broadcast packet in the above step 3.1) includes the following contents:

 among them:

 RE field: identity information of the responder entity;

 Flag field: indicates the broadcast category;

 Time field: Current system time, used to distinguish whether it is duplicate information;

C2 field: ciphertext information of the multicast session key broadcast by the responder entity, the encryption key is GKEKE; MIC field: Indicates that the MIC value is obtained for all fields before the field, where the integrity check key is GKEKI.

 After receiving the multicast session key broadcast packet in the above step 3.2), the requester entity recalculates the MIC by using the integrity check key GKEKI to determine whether the packet is valid. Meanwhile, according to the Time field, it is determined whether the system repeats the message; Effectively, the encryption session key GKEKE is used to decrypt C2 to obtain the multicast session key GSK.

 The above responder entity and the requester entity can use the multicast session key GSK to derive the multicast session encryption key GSKE and the multicast session integrity check key GSKI, and the responder entity performs the multicast service.

 A wireless metropolitan area network multicast key management system includes a requester entity and a responder entity, wherein the requester entity is configured to send a multicast private key request packet to a responder entity, and receive the responder After the multicast private key returned by the entity responds to the packet, the multicast private key acknowledgement packet is sent to the responder entity; and after receiving the multicast key encryption key broadcast packet broadcast by the responder entity, the multicast key is encrypted. Decrypting the multicast key encryption key in the key broadcast packet; the responder entity, configured to: after receiving the multicast private key request packet sent by the requester entity, return a multicast private key response packet to the requester entity; And after receiving the multicast private key confirmation packet sent by the requester entity, the multicast key encryption key broadcast packet is broadcast to all requester entities.

 The above responder entity is also used to establish system parameters.

 The requester entity and the responder entity are also used to perform authentication and unicast key negotiation between the two to establish a shared unicast session key.

 The above responder entity is further configured to broadcast a multicast session key broadcast packet to all requester entities; the requester entity is further configured to decrypt the multicast session key from the multicast session key broadcast packet.

 The invention has the following advantages:

 1. The two-level or three-level multicast key management method is adopted. The basic key is different for different terminals, and the system security is higher.

 2. The security of the algorithm depends on the elliptic curve discrete logarithm problem, and the security is stronger.

3. The multicast key encryption key and multicast session key distribution or update only need one multicast. 4. Fully utilize the multicast channel to improve system communication efficiency.

DRAWINGS

 1 is a schematic diagram of multicast private key distribution according to the present invention;

 2 is a schematic diagram of multicast key encryption key distribution according to the present invention;

 FIG. 3 is a schematic diagram of multicast session key distribution according to the present invention.

detailed description

 Glossary:

 RE: Responder entity, such as base station, access point, router;

 AE: requester entity, such as a terminal;

 Nonce: once 4 random numbers;

 GKx: the multicast private key of the requester entity X, that is, the base key;

 GKE: multicast key encryption key;

 GKEKI and GKEKE: integrity check keys and encryption keys derived by GKEK;

 GSK: multicast session key;

 GSKI and GSKE: The integrity check key and encryption key derived by GSK.

 Referring to Figures 1, 2, and 3, the specific steps of a wireless metropolitan area network multicast key management method of the present invention are as follows:

 1) The system parameters are established by the responder entity. The system parameters include: Let (+) and (<3⁄4,·) be a cyclic group with two orders of p, p is prime, and satisfy the t Diffie-Hellman calculation problem. Difficult problem; let (the generator of ^; let e be (^ and (3⁄4 on the bilinear transformation, ie ^ (7 (^→(3⁄4;) is a one-way hash function.

 This step is only to establish the system parameters when the first application is applied. After the establishment, the step is not needed in the subsequent repeated application;

2) The requester entity and the responder entity perform authentication and unicast key negotiation; establish a shared unicast session key USK, from which the unicast session encryption key USKE and the unicast session integrity school can be derived The authentication key and the unicast key negotiation method may be any method such as W API or 802.1 li, or may be implemented by manually setting a pre-shared key method; This step is required when the responder entity in the system does not perform security authentication and unicast session key USK negotiation with each requester entity row. If the responder entity and each requester entity in the system have already performed security authentication and single The negotiation of the broadcast session key USK does not require this step;

 3) Multicast private key distribution:

 3.1) The requester entity sends a multicast private key request packet to the responder entity;

The multicast private key request packet includes the following:

 among them:

 AE field: identity information of the requester entity;

 RE field: identity information of the responder entity;

 N1 field: a random number generated by the requester entity;

 MIC field: Indicates that the MIC value is obtained for all fields before the field, where the integrity check key is USKL

 After receiving the multicast private key request packet, the responder entity recalculates the MIC and compares it with the received MIC. If not, discards the packet; if equal, constructs a multicast private key response packet and sends the request to the request. Entity.

 3.2) The responder entity sends a multicast private key response packet to the requester entity;

The multicast private key response packet includes the following:

 among them:

 RE field: identity information of the responder entity;

 AE field: identity information of the requester entity;

 N1 field: a random number generated by the requester entity;

 N2 field: a random number generated by the responder entity;

 C field: ciphertext information of the multicast private key GKx distributed by the responder entity to the requester entity, the encryption key is USKE;

MIC field: Indicates the MIC value for all fields before the field, here the integrity check key It is USKI.

 The calculation process of the c field is as follows:

= /(v_i)_JP( = 0，l，...，w-2); 这一步响应者 实体对所有请求者实体只做一次，对下一个请求者实体来说， 就不需要重复处 理； 3.2.1) The responder entity randomly selects wl greater than or equal to 2 in the Z _? ') different elements v ₀ , j,...,! ^^^ and the element ^^^^, at the same time, randomly construct the sub-secret polynomial / ( (;) _e z. [ C]. Next, calculate the following information:

= /(v _i ) _J P( = 0,l,...,w-2); In this step the responder entity does only once for all requester entities, and does not need to repeat for the next requester entity. deal with;

3.2.2) For the requester entity AE, calculate <3⁄4Γ = /(Α£)(β _{1 +} β ₂ );

3.2.3) C = (Q _K , Q ₁ , Q ₂ , v ₀ ,..., v _n _ ₂ , V ₀ ,...,V _n _ ₂ )\\E(USKE;GK _x ) ₀

 When the requester entity receives the multicast private key response packet, it recalculates the MIC and receives the received

The MIC compares, if not equal, discards the packet; equal, determines whether N1 randomly selects the random number; if not, discards the packet, and if so, decrypts Z with the key USKE (f/; GQ obtains the group The private key GKx is broadcast, and finally, the multicast private key confirmation packet is constructed and sent to the responder entity.

 3.3) The requester entity sends a multicast private key confirmation packet to the responder entity;

The multicast private key confirmation packet includes the following:

 among them:

 AE field: identity information of the requester entity;

 RE field: identity information of the responder entity;

 N2 field: a random number generated by the responder entity;

 MIC field: indicates the MIC value of all the fields before the field and the decrypted multicast private key GKx, where the integrity check key is USKI;

 After receiving the multicast private key confirmation packet, the responder entity recalculates the MIC and compares it with the received MIC; if not, discards the packet; equal, determines whether N2 selects the random number by itself; if not The packet is discarded, and if so, the multicast private key is successfully distributed.

 The above steps 1), 2), 3), please refer to Figure 1.

4) Multicast key encryption key distribution (or update) process (Figure 2) 4.1) The Responder entity broadcasts the multicast key encryption key broadcast packet to all requester entities; when the Responder entity needs to distribute (or update) the multicast key encryption key GKEK, it broadcasts the multicast secret to all requester entities. The key encryption key broadcast packet, the multicast key encryption key broadcast packet includes the following:

 among them:

 RE field: identity information of the responder entity;

 Flag field: indicates the broadcast category;

 Time field: Current system time, used to distinguish whether it is duplicate information;

 C1 field: ciphertext information of the multicast key encryption key broadcast by the responder entity;

= (rP,rQ_l,e(Q_K,Q₂yGKEK,_rV₀,...,rV_n_₂) MIC field: Indicates that the MIC value is obtained for all fields preceding the field, where the integrity check key is GKEKI (the integrity check key derived by the multicast key encryption key). The calculation method of the C1 field is as follows: Assume that the responder entity selects the multicast key encryption key GKEK eG ₂ , and the responder entity randomly selects the integer reZ^ and calculates as follows: Cl =

= (rP,rQ _l ,e(Q _K ,Q ₂ yGKEK, _r V ₀ ,...,rV _n _ ₂ )

4.2) The requester entity decrypts the multicast key encryption key from the multicast key encryption key broadcast packet.

 When any requester entity AE receives the packet, the following method decrypts GKEK:

4.2.1) First, the requester entity constructs a set using the public information and its own device identification information: r = {e ₀ , i' ₁ ,...i' _B _ ₁ } = {v ₀ ,...,v _B _ ₂ , AE}

2.2.2) Then, and for each

2.2.3) Next, calculate the multicast key encryption key as follows: GKEK = iQ QW.

β] + Q ₂ , ∑ σ _{Βί Τ} ν;)β(σ _{Βη ί ΐ} ΟΚ _χ ,Ρ') After the requester entity calculates the multicast key encryption key GKEK, it derives the integrity check key GKEKI and The encryption key GKEKE is used; then, the MIC is recalculated by using the integrity check key GKEKI to determine whether the packet is valid; meanwhile, it is determined according to the Time field whether the system repeats the message.

 5) Multicast session key distribution (or update) process (Figure 3)

5.1) The Responder entity broadcasts a multicast session key broadcast packet to all requester entities; broadcasts a multicast session key broadcast packet to all requester entities when the responder entity needs to distribute (or update) the multicast session key GSK The multicast session key broadcast packet includes the following:

 among them:

 RE field: identity information of the responder entity;

 Flag field: indicates the broadcast category;

 Time field: Current system time, used to distinguish whether it is duplicate information;

 C2 field: ciphertext information of the multicast session key broadcast by the responder entity, the encryption key is GKEKE;

 MIC field: Indicates that the MIC value is obtained for all fields before the field, where the integrity check key is GKEKI.

 5.2) The requester entity decrypts the multicast session key from the multicast session key broadcast packet.

 After receiving the multicast session key broadcast packet, the arbitrary requester entity recalculates the MIC by using the integrity check key GKEKI to determine whether the packet is valid. Meanwhile, it is determined according to the Time field whether the system repeats the message; if all are valid, the encryption is used. The key GKEKE decrypts C2 to get the multicast session key GSK.

 The responder entity and each requester entity can use the multicast session key GSK to derive the multicast session encryption key GSKE and the multicast session integrity check key GSKI, and then the responder entity can start the multicast service.

It is worth noting that: Step 5) above is optional. This includes two methods: (a) When step 5) is selected, the key management is GKx-GKE-GSK level 3 key management, mainly for Existing WMAN and BWM multicast key management mechanisms. However, this method is more effective when updating GKEK, only one broadcast is required; (b) When step 5) is not selected, the key management is GKx - GKEK, then we can treat GKEK as GSK, directly For multicast session services, this has the advantage of improving multicast key distribution efficiency, but it is not compatible with existing WMAN and BWM multicast key management mechanisms.

 The present invention is applied to a wireless metropolitan area network as an example. The responder entity is the base station BS, and the requester entity is the terminal MTx. The present invention is further described in detail:

 1) Multicast private key distribution process

 1.1) Multicast private key request packet: sent by the MTx to the BS.

The multicast private key request packet includes the following:

 among them:

 MTx field: identity information of the terminal;

 BS field: identity information of the base station;

 N1 field: a random number generated by the terminal;

 MIC field: Indicates that the MIC value is obtained for all fields before the field, where the integrity check key is USKL

 When the BS receives the multicast private key request packet, it recalculates the MIC and compares it with the received MIC. If not equal, the packet is discarded; otherwise, the multicast private key response packet is constructed and sent to MTx.

 1.2) Multicast private key response packet: sent by the BS to MTx.

The multicast private key response packet includes the following:

 among them:

 BS field: identity information of the base station;

 MTx field: identity information of the terminal;

 N1 field: a random number generated by the terminal;

N2 field: a random number generated by the base station; C field: ciphertext information of the multicast private key GKx distributed by the base station to the terminal, and the encryption key is USKE;

MIC field: Indicates that the MIC value is obtained for all fields before the field, where the integrity check key is USKL

 The calculation process of the C field is as follows:

= /(V_;)P( = 0， .,M- 2)。 这一步基站对所有终 端只做一次， 对下一个终端来说， 就不需要重复处理。 1.2.1) The base station randomly selects /2-1 greater than or equal to 2) different elements v ₀ , vj, ..., 2 € 2; and elements 3⁄4, 2 ₂ (7 ₁ , at the same time, random construction "- 1 secret polynomial / WeZ^W. Next, calculate the following information:

= /(V _; )P( = 0, ., M- 2). In this step, the base station does only once for all terminals, and for the next terminal, there is no need to repeat processing.

= /(Mrx)(¾ +β₂)。 1.2.2) For the terminal MTx,

= /(Mrx)(3⁄4 +β ₂ ).

1.2.3) C = (Q _K , Q ₁ , Q ₂ , v ₀ ,..., v _n _ ₂ , V ₀ ,...,V _n _ ₂ )\\E(USKE;GK ₀

 When the MTx receives the multicast private key response packet, it recalculates the MIC and compares it with the received MIC. If they are not equal, the packet is discarded; otherwise, it is determined whether N1 is a random number selected by itself. If not, the packet is discarded, and if so, the key USKE is used to decrypt (tA1⁄23⁄4G7Q obtains the multicast private key GKx. Finally, the multicast private key is constructed to acknowledge the packet is sent to the BS.

 1.3) Multicast private key acknowledgement packet: sent by the MTx to the BS.

The multicast private key confirmation packet includes the following:

 among them:

 MTx field: identity information of the terminal;

 BS field: identity information of the base station;

 N2 field: a random number generated by the BS;

 MIC field: Indicates the MIC value of all the fields before the field and the decrypted multicast private key GKx, where the integrity check key is USKL

 When the BS receives the multicast private key acknowledgment packet, it recalculates the MIC and compares it with the received MIC. If they are not equal, the packet is discarded; otherwise, it is determined whether N2 is a random number selected by itself. If not, the packet is discarded. If yes, the multicast private key is successfully distributed.

2) Multicast key encryption key distribution (or update) process 2.1) When the BS needs to distribute (or update) the multicast key encryption key GKEK, the multicast key encryption key broadcast packet is broadcast to all terminals, and the multicast key encryption key broadcast packet includes the following contents.

 among them:

 BS field: identity information of the base station;

 Flag field: indicates the broadcast category;

 Time field: Current system time, used to distinguish whether it is duplicate information;

 C1 field: ciphertext information of the GKEK broadcast by the base station;

MIC field: Indicates the MIC value for all fields preceding this field, where the integrity check key is GKEKI (the integrity check key derived by GKEK). The calculation method of the C1 field: Assume that the base station selects GKEK _e G ₂ . The base station randomly selects the integer W _p and calculates as follows:

 2.2) When any terminal MTx receives the packet, decrypt the GKEK as follows:

2.2.1) First, the terminal MTx constructs a collection using public information and its own device identification information:

Γ = {ί- ₀ , ί> ₁ ,...έ' _ΐί _ ₁ } = {ν ₀ ,...,ν _Β _ ₂ ,ΜΤχ}

2.2.2) Then, calculate Π ^- for each ^

2.2.3) Next, calculate the multicast key encryption key as follows:

GKEK = (QQ _K u. After calculating GKEK, I will export GKEKI and GKEKE. Then, use GKEKI to recalculate the MIC and judge whether the packet is valid. At the same time, judge whether the system repeats the message according to the Time field.

3) Multicast session key distribution (or update) process 3.1) When the BS needs to distribute (or update) the multicast session key GSK, the multicast session key broadcast packet is broadcast to all terminals, and the multicast session key broadcast packet includes the following contents:

 among them:

 BS field: identity information of the base station;

 Flag field: indicates the broadcast category;

 Time field: Current system time, used to distinguish whether it is duplicate information;

 C2 field: ciphertext information of the GSK broadcast by the base station, and the encryption key is GKEKE;

 MIC field: Indicates that the MIC value is obtained for all fields before the field, where the integrity check key is GKEKI.

 3.2) When any terminal MTx receives the packet, it uses GKEKI to recalculate the MIC to determine whether the packet is valid. At the same time, it is determined according to the Time field whether the system repeats the message. If both are valid, use the key GKEKE to decrypt C2 to get the multicast session key GSK.

 The base station and each terminal can use the GSK to derive the multicast session encryption key GSKE and the multicast session integrity check key GSKI, and then the base station can start the multicast service.

 Corresponding to the above method, the present invention further provides a wireless metropolitan area network multicast key management system, the system comprising a requester entity and a responder entity, wherein:

 The requester entity is configured to send a multicast private key request packet to the responder entity, and after receiving the multicast private key response packet returned by the responder entity, send the multicast private key confirmation packet to the responder entity; and receive After the multicast key encryption key broadcast packet broadcast by the responder entity, the multicast key encryption key is decrypted from the multicast key encryption key broadcast packet;

 The responder entity is configured to: after receiving the multicast private key request packet sent by the requester entity, return a multicast private key response packet to the requester entity; and after receiving the multicast private key confirmation packet sent by the requester entity, The multicast key encryption key broadcast packet is broadcast to all requester entities.

Preferably, the responder entity is further configured to establish system parameters; and, the requester entity and the responder entity are further configured to perform authentication and unicast key negotiation between the two to establish a shared unicast session key. And, the responder entity is further configured to broadcast the multicast session key broadcast packet to all requester entities; The requester entity is also used to decrypt the multicast session key from the multicast session key broadcast packet.

 For details of the specific implementation of the wireless metropolitan area network multicast key management system provided by the present invention, refer to the specific method in the foregoing method, and details are not described herein again.

 It can be seen that, in the present invention, by adopting a two-level or three-level multicast key management manner, the basic key is different for different terminals, and the system security is higher; and the security of the algorithm depends on the ellipse. The curve discrete logarithm problem is more secure; the multicast key encryption key and the multicast session key can only be distributed once or only once; the full use of the multicast channel improves the communication efficiency of the system.

Claims

Rights request 1. A wireless metropolitan area network multicast key management method, characterized in that: the method includes the following steps: 1) Multicast private key distribution: 1.1) The requester entity sends a multicast private key request packet to the responder entity; 1.2) The responder entity sends a multicast private key response packet to the requester entity; 1.3) The requester entity sends a multicast private key confirmation packet to the responder entity; 2) Multicast key encryption key distribution or update: 2.1) The responder entity broadcasts the multicast key encryption key broadcast group to all requester entities; 2.2) The requester entity decrypts the multicast key encryption key from the multicast key encryption key broadcast group. 2. The wireless metropolitan area network multicast key management method according to claim 1, characterized in that: the step 1) further includes the step of establishing system parameters by the responder entity. 3. The wireless metropolitan area network multicast key management method according to claim 2, characterized in that: the system parameters include: assuming ((^,+) and (G ₂ ,.) are two orders of The cyclic group of p, p is a prime number, and satisfies The Diffie-Hellman calculation problem in G is a difficult problem; let f be the generator of ; let e be the bilinear transformation on (^ and (¾, that is, ^ (?^ (¾→(^ ₂ ; let /ζ( ·) is a one-way hash function. 4. The wireless metropolitan area network multicast key management method according to claim 1 or 2 or 3, characterized in that: before step 1), the requester entity and the responder entity perform authentication and unicast encryption. Key negotiation to establish a shared unicast session key. 5. The wireless metropolitan area network multicast key management method according to claim 1, characterized in that: the multicast private key request group in step 1.1) includes the following content:

in: AE field: Identity information of the requester entity; RE field: Identity information of the responder entity; N1 field: Random number generated by the requester entity; MIC field: means to calculate the MIC value for all fields before this field, where the integrity check key is USKL 6. The wireless metropolitan area network multicast key management method according to claim 5, characterized in that: in step 1.2), when the responder entity receives the multicast private key request group, it recalculates the MIC and compares it with the The received MICs are compared, and if they are not equal, the packet is discarded; if they are equal, a multicast private key response packet is constructed and sent to the requester entity. 7. The wireless metropolitan area network multicast key management method according to claim 5 or 6, characterized in that: the multicast private key response packet in step 1.2) includes the following content:

in: RE field: Identity information of the responder entity; AE field: Identity information of the requester entity; N1 field: Random number generated by the requester entity; N2 field: Random number generated by the responder entity; C field: The ciphertext information of the multicast private key GKx distributed by the responder entity to the requester entity, and the encryption key is USKE; MIC field: means to find the MIC value for all fields before this field, where the integrity check key is USKL 8. The wireless metropolitan area network multicast key management method according to claim 7, characterized in that: the calculation process of the C field is as follows: 1.2.1) The responder entity randomly selects <-1 greater than or equal to 2) different elements v ₀ in Z _g ', Vj,…,^^^ and elements^^^^, at the same time, randomly construct "-1 degree secret polynomial/WeZ W; then, calculate the following information: β

= /(v _; )P( = 0,l,...,"- 2); 1.2.2) For the requester entity, i- -GK _x = f(AE)(Q _{1 +} Q ₂ ); 1.2.3 ) C = (Q _K ,Q ₁ ,Q ₂ ,v ₀ ,...,v _n _ ₂ ,V ₀ ,...,V _n _ ₂ )\\E(USKE;GK _x ) ₀ 9. The wireless metropolitan area network multicast key management method according to claim 8, characterized in that: in step 1.3), when the requester entity receives the multicast private key response packet, it recalculates the MIC and compares it with the multicast private key response packet. Compare the received MICs, and if they are not equal, discard the packet; if equal, determine whether N1 is a random number selected by the requester entity; if not, discard the packet, and if so, use the key USKE to decrypt E(JUSKE GK Obtain the multicast private key GKx. Finally, construct the multicast private key confirmation packet and send it to the responder entity. 10. The wireless metropolitan area network multicast key management method according to claim 9, characterized in that: the multicast private key confirmation group in step 1.3) includes the following content:

in: AE field: Identity information of the requester entity; RE field: Identity information of the responder entity; N2 field: Random number generated by the responder entity; MIC field: Indicates the MIC value obtained by all fields before this field and the decrypted multicast private key GKx, where the integrity check key is USKI. 11. The wireless metropolitan area network multicast key management method according to claim 10, characterized in that: in step 1.3), when the responder entity receives the multicast private key confirmation group, it recalculates the MIC and compares it with the Compare the received MICs; if not equal, discard the packet; if equal, determine whether N2 is a random number selected by the responder entity; if not, discard the packet, and if so, the multicast private key is distributed successfully. 12. The wireless metropolitan area network multicast key management method according to claim 11, characterized in that: the multicast key encryption key broadcast group in step 2.1) includes the following content:

in: RE field: Identity information of the responder entity; Flag field: indicates the broadcast category; Time field: Current system time, used to distinguish whether it is duplicate information; C1 field: Ciphertext information of the multicast key encryption key broadcast by the responder entity; MIC field: means to calculate the MIC value of all fields before this field, here the integrity check key Is GKEKI (integrity check key derived from multicast key encryption key). 13. The wireless metropolitan area network multicast key management method according to claim 12, characterized in that: the calculation method of the C1 field is as follows: Assuming that the responder entity selects the multicast key encryption key GKEK eG ₂ , the responder entity randomly selects the integer reZ^ and performs the following calculation: CI = CP*, β, K,…' K*— ₂ ) = (^, , , 2 ₂ :, rV.,…, „— ₂ ). 14. The wireless metropolitan area network multicast key management method according to claim 13, characterized in that: in step 2.2), when the requester entity receives the group, it decrypts the encrypted multicast key as follows: Key: 2.2.1) First, the requestor entity constructs a set using public information and its own device identification information: r = {e ₀ ,e ₁ ,... _en _ ₁ } = {v ₀ ,..., v _n _ ₂ ,A^} 2.2.2) Then, calculate ,^ Π for each ^ ≠ _i e _j -e _i 2.2.3) Next, calculate the multicast key encryption key as follows: GKEK = _n — "' ^QU . e(Q, + Q ₂ ,∑ a^ _r V;)e(a _e ^ _r GK _x ,P') 15. The wireless metropolitan area network multicast key management method according to claim 14, characterized in that : In step 2.2), after the requester entity calculates the multicast key encryption key, it derives the integrity check key and encryption key; then, uses the integrity check key to recalculate the MIC and determine the grouping Whether it is valid; At the same time, it is judged whether the system is repeating the message based on the Time field. 16. The wireless metropolitan area network multicast key management method according to claim 1, characterized in that: after step 2), it also includes: step 3) multicast session key distribution or update; step 3) includes: 3.1) The responder entity broadcasts the multicast session key broadcast packet to all requester entities; 3.2) The requestor entity decrypts the multicast session key from the multicast session key broadcast packet. 17. The wireless metropolitan area network multicast key management method according to claim 1, characterized in that: The multicast session key broadcast packet in step 3.1) includes the following content:

in: RE field: Identity information of the responder entity; Flag field: indicates the broadcast category; Time field: Current system time, used to distinguish whether it is duplicate information; C2 field: The ciphertext information of the multicast session key broadcast by the responder entity, the encryption key is GKEKE; MIC field: means to find the MIC value for all fields before this field, where the integrity check key is GKEKI. 18. The wireless metropolitan area network multicast key management method according to claim 16 or 17, characterized in that: in step 3.2), after the requester entity receives the multicast session key broadcast packet, the integrity is used The verification key GKEKI recalculates the MIC to determine whether the group is valid; at the same time, it determines whether the system is repeating messages based on the Time field; if both are valid, use the encryption key GKEKE to decrypt C2 to obtain the multicast session key GSK. 19. The wireless metropolitan area network multicast key management method according to claim 18, characterized in that: the responder entity and the requester entity use the multicast session key GSK to derive the multicast session encryption key GSKE and the group Broadcast session integrity check key GSKI, the responder entity performs multicast services. 20. A wireless metropolitan area network multicast key management system, including a requester entity and a responder entity, characterized by: The requester entity is configured to send a multicast private key request packet to the responder entity, and after receiving the multicast private key response packet returned by the responder entity, send a multicast private key confirmation packet to the responder entity; and After receiving the multicast key encryption key broadcast group broadcast by the responder entity, decrypt the multicast key encryption key from the multicast key encryption key broadcast group; The responder entity is configured to return a multicast private key response packet to the requester entity after receiving the multicast private key request packet sent by the requester entity; and after receiving the multicast private key confirmation sent by the requester entity After grouping, the multicast key encryption key broadcast group is broadcast to all requester entities. 21. The system according to claim 20, characterized in that the responder entity is also used to establish system parameters. 22. The system according to claim 20 or 21, characterized in that, the requester entity and the responder entity are also used to perform authentication and unicast key negotiation between them to establish a shared unicast session. key. 23. The system according to claim 20 or 21, characterized in that, The responder entity is further configured to broadcast the multicast session key broadcast packet to all requester entities; the requester entity is further configured to decrypt the multicast session key from the multicast session key broadcast packet.