WO2005078992A1

WO2005078992A1 - A Method for Implementing Multimedia Broadcast Multicast Service Key Distribution

Info

Publication number: WO2005078992A1
Application number: PCT/CN2005/000096
Authority: WO
Inventors: Wenlin Zhang; Yingxin Huang; Hai Zhang; De Chen
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2004-02-09
Filing date: 2005-01-21
Publication date: 2005-08-25
Also published as: CN1655497A; CN1300974C

Abstract

A Method for Implementing Multimedia Broadcast Multicast Service Key Distribution. The method comprises: the network side locates a time interval T for each group users, and informs to the corresponding user terminal; the network side distributes the new key valid message after updating the shared key, and the user terminals which have received the new key valid message initiates a timer corresponding to the time interval T; the user terminals send a request key message to the broadcast/multicast server when the timer reaches the point; the broadcast/multicast server distributes the new shared key to the user terminals which have sent request after receiving the request key message. The present method ena~es the different user to send a request at different time point, which solves the network communication blocking problem brought by a large number of user terminals appling the new shared key to the network at the same time.

Description

Method for implementing multimedia broadcast / multicast service key distribution

The present invention relates to key processing technology, and particularly to a method for implementing key distribution of multimedia broadcast / multicast services. Background of the invention

With the development of the third-generation mobile communication technology, the third-generation mobile communication can provide higher data rate services than the second-generation mobile communication, thereby supporting a variety of business forms, such as: video calls, image downloads, high-speed Internet browsing And other services. Among them, one type of service is characterized in that it can send to all users who have customized the service in the wireless network at the same time, such as sending weather forecasts, news clips, sports competition highlights, and so on. Therefore, the third-generation mobile communication introduces the concept of broadcast / multicast. The so-called broadcast / multicast service refers to: one-to-multipoint unidirectional bearer service. Data is sent from one source entity to multiple receiving entities, and the service is transmitted. The principle is shown in Figure 1. Node 1 is the source entity. Node 1 sends the data to be sent to the receiving entity node 10. After receiving the data, node 10 can use the source entity to copy the data into two copies and distribute it to the receiving entity node. 11 and 12; after receiving the data, node 11 then copies the data into two copies as the source entity and distributes it to the receiving entity nodes 111 and 112, and so on.

FIG. 2 is a schematic diagram of a wireless network structure supporting broadcast / multicast services. As shown in FIG. 2, under the existing 3rd Generation Partnership Project (3GPP) framework, a wireless network structure supporting broadcast / multicast services is broadcast / group. Broadcast service server (BM-SC) 201, BM-SC 201 is connected to the gateway GPRS support node (GGSN, Gateway GPRS Support Node) 202 through the Gmb interface or Gi interface, and one BM-SC 201 can be connected to multiple GGSN 202; GGSN 202 is connected to a serving GPRS support node (SGSN, Serving GPRS Support Node) 203 through a Gn / Gp interface, and one GGSN 202 can be connected to multiple SGSN 203; SGSN 203 can be connected through an Iu interface It is connected to the Universal Mobile Telecommunications System (UMTS) Land Radio Access Network (UTRAN) 204, and then the UTRAN 204 is connected to the user terminal (UE) 206 through the Uu interface. ) The enhanced radio access network (GERAN) 205 is connected, and then the GERAN 205 is connected to the UE 207 through the Um interface. Herein, the broadcast / multicast service server is hereinafter referred to as a broadcast / multicast server, and the broadcast / multicast server may be a new functional entity in an existing wireless communication network, or may be an existing wireless communication network. A functional entity, or a combination of several functional entities.

In a certain area, users who have subscribed to broadcast / multicast services can enjoy the services of broadcast / multicast services. Then, in the broadcast / multicast service, in order to prevent users who have not subscribed to the broadcast / multicast service or have not paid to enjoy the service of the broadcast / multicast service, it is necessary to set only the broadcast / multicast service in the broadcast / multicast service. Keys known to users in the group and broadcast / multicast server. In this case, the broadcast / multicast server not only has the function of providing broadcast / multicast business services, but also has the function of key generation management.

The key shared by the broadcast / multicast server and all users in the group can be called the group shared key of the broadcast / multicast service. The broadcast / multicast server sends the shared key to the users in the group. The sending process is performed by the broadcast / multicast server one-to-one with the users in each group, and the shared key is usually encrypted when sending. The users in the group and the broadcast / multicast server perform mutual authentication through authentication and key agreement protocol (AKA). During the mutual authentication process, the users in the group and the broadcast / multicast server generate and possess encryption at the same time. Key (KEK), which is used to encrypt the shared key. The encryption key of each user in the group is unique, that is, the encryption keys owned by the users in the group are different. The broadcast / multicast server uses the encryption key corresponding to the users in each group to encrypt the shared key, and then sends the encrypted shared key to the corresponding users in the group. The corresponding encryption key decrypts the shared key, and finally realizes the key sharing between the broadcast / multicast server and the users in the group. After that, the broadcast / multicast server uses the shared key to encrypt the broadcast / multicast service information and sends it to each user in the group. The users in the group use Use the shared key to decrypt the broadcast / multicast service information, obtain the broadcast / multicast service information, and enjoy the service of the broadcast / multicast service.

To prevent users outside the group from enjoying the broadcast / multicast service, the shared key needs to be updated frequently. The update process of the shared key is also performed one-to-one between the broadcast / multicast server and the users in the group. Generally, the broadcast / multicast server initiates a shared key update process according to a trigger condition. After the update process is triggered, the broadcast / multicast server sends an updated shared key to each user in the group at the same time. The update process is shown in steps 301 to 303 in FIG. 3. After the broadcast / multicast server updates the shared key, it sends a new key valid message to the user terminal, which indicates that the new shared key is already valid. The user terminal After receiving the new key valid message, it can send a request key message to the broadcast / multicast server to request a new shared key; after receiving the request key message, the broadcast / multicast server sends the corresponding new shared key Send to the user terminal that initiated the request; after the user terminal successfully receives the new shared key, save the shared key and use it later.

In the process shown in FIG. 3, the step of the broadcast / multicast server sending a new key valid message, that is, step 301 is optional. The user terminal may send a request key message after receiving the new key valid message, or may actively initiate an update process at any time to send a request key message to the broadcast / multicast server. The premise of actively initiating the update process is: the current user terminal has joined the broadcast / multicast service but does not have a new shared key; or the current user terminal has received some protected content, and these contents are carried out using the new shared key protection. The process shown in Figure 3 is also applicable to a group user who has just joined the broadcast / multicast service. This user does not have a shared key. The shared key currently owned by the broadcast / multicast server is a new shared key for the user. However, this application is mainly directed to the case where step 301 exists.

It can be seen from the above process that the update process of the shared key has two points in time: one is the point in time when the new shared key becomes valid, after which the user terminal can apply for a new shared key to the network; The other is the time when the new shared key is enabled by the network. After this point in time, the network uses the new shared key to protect the data, and the user terminal receives the data using the new shared key. If there are a large number of users in the group who can enjoy the broadcast / multicast service, all user terminals will apply to the network for a shared key after receiving a message indicating that the new key is valid. Then, there will be a phenomenon that a large number of user terminals send information to the network at the same time. This will cause the amount of information in the wireless communication network to increase rapidly and block the communication of the wireless communication network. At the same time, the broadcast / multicast server will also A large number of users request new shared keys at the same time and cannot be processed in time. How to avoid all user terminals from requesting new shared keys at the same time and try to improve the processing speed of the broadcast / multicast server for user requests has not yet been proposed. Summary of the invention

In view of this, the main object of the present invention is to provide a method for implementing multimedia broadcast / multicast service key distribution, which can enable different users to initiate requests at different times as much as possible, thereby solving a large number of user terminals applying for a shared key from the network at the same time. The resulting network congestion problem.

To achieve the above object, the technical solution of the present invention is implemented as follows:

A method for implementing multimedia broadcast / multicast service key distribution. The method includes the following steps:

a. The network side allocates a time T to each group of users, and notifies the corresponding user terminal of the allocated time T;

b. After the network side updates the shared key, a new key validity message is sent to all users in the group described in step a. Each user terminal that receives the new key validity message starts the timing corresponding to its assigned time T. Device

'c When the timer in step b expires, the user terminal corresponding to the timer sends a request key message to the broadcast / multicast server; after receiving the request key message, the broadcast / multicast server sends the request key message to the user who initiated the request The terminal sends a new shared secret.

In the above solution, the message of updating the shared key and issuing a new key valid message on the network side in step b is specifically: the broadcast / multicast server updates the shared key; after that, the broadcast / multicast server proceeds to step a All users in the group issue a new key valid message.

In the above solution, between step a and step b further includes: each user terminal generates a random number as an additional delay time after receiving the time T allocated to itself; then in step b, the message of receiving a new key valid message The user terminal starts a timer with a length of time T plus an additional delay time. Alternatively, after the timer expires in step c, the method further includes: the user terminal corresponding to the timer generates a random number as an additional delay time, and continues to delay the length of the additional delay time to the broadcast / multicast monthly server. Send a request key message. Alternatively, when the user terminal starts the timer in step b, the method further includes: generating a random number as the additional delay time; after the timer expires in step c, after the timer continues to delay, the user terminal sends a broadcast / group to the broadcast / group. The broadcast server sends a message asking for the key. Alternatively, after the user terminal starts the timer in step b, the method further includes: generating a random number as an additional delay time; after the timer expires in step c, and continuing to delay the additional delay time, the user terminal sends a broadcast / multicast to the broadcast / multicast The server sends a request key message.

Among the foregoing parties, the network side allocates time T to the group user when the group user joins the multimedia broadcast / multicast service; or for the group after the group user joins the multimedia broadcast / multicast service The user allocates time T; or when a shared key is sent to a group user, the group user is allocated time T. Wherein, the network side allocating time T for users in each group is specifically: the broadcast / multicast server allocates time T for each group user.

Wherein, the value of the time T lies in the length of time from the time when the new shared key is valid to the time when the broadcast / multicast server expects the user group to complete the centralized request for the shared key to work, and from the time when the request is initiated to the time when the user finally gets a new share The difference between the lengths of time required by the keys is uniformly distributed in probability. The time T may be generated by a random function, and sample points of the random function obey a uniform distribution in probability; it may also be generated by a modulo method or a HASH function method.

In the above scheme, the additional delay time is generated within a time interval T _x between the current discrete point to which the user terminal currently initiates and the next discrete point, and obeys the average of [0, Τ _χ ) in probability. Evenly distributed.

The method for implementing multimedia broadcast / multicast service key distribution provided by the present invention is because a timer is assigned to each user in the group, and uniformly-distributed timer values are set according to certain rules. The arrival time of the router further determines the request initiation time of the corresponding user terminal. In this way, after receiving the new shared key valid message, many users in the same group can send the request key message to the network at a uniform and discrete time, thereby avoiding This improves network communication congestion, improves the processing speed of the broadcast / multicast server for user requests, reduces the processing capability requirements of each network node server for sudden services, and saves network costs. Brief description of the drawings

Figure 1 is a schematic diagram of the transmission principle of a multicast service;

Figure 2 is a schematic diagram of a wireless network structure supporting broadcast / multicast services;

Figure 3 is a schematic flowchart of a shared key update process between a broadcast / multicast server and a group user;

FIG. 4 is a flowchart of implementing the method of the present invention;

FIG. 5 is a schematic diagram of relationships between various time points involved in the present invention;

FIG. 6 is a schematic diagram of the relationship between the discrete time points generated in the method of the present invention; FIG. 7 is a schematic diagram of the relationship between the additional delay time and the discrete time point. Mode of Carrying Out the Invention

The core idea of the present invention is: allocate a time to each user in the same group uniformly, and the distribution time of all users is evenly and discretely distributed, and the request initiation time of each user in the group can be further determined according to the allocation time. After receiving the message that the new key is valid, the users in each group send a request key message to the broadcast / multicast server at the time of the request initiation. After receiving the request, the broadcast / multicast server sends the request to the corresponding user. Returns the new shared secret. Here, each group The user's assigned time can be counted by a timer or counted by a counter.

As shown in FIG. ⁴ , the method for implementing key distribution according to the present invention specifically includes the following steps: Step 401: The network allocates a time T to each group user through point-to-point interaction with the group users, and notifies the corresponding time User terminal.

Here, the network may be a mobile communication network or a wired communication network. Because the broadcast / multicast server is used to complete the overall control, the entity that allocates time to each group user in the network is generally the broadcast / multicast server. The broadcast / multicast server completes the time allocation through the point-to-point interaction process with each group user. The broadcast / multicast server can allocate time to the group users in three cases: ① When a When a group user joins the multimedia broadcast / multicast service; ② When a group user joins the multimedia broadcast / multicast service; ③ When a shared key is sent to a group user, a new allocation is given to the group user For a time. In the third case, if the group user already has an allocated time, it means that the broadcast / multicast server needs to allocate another time for the group user, in other words, the allocated time can be updated.

The selection range of time T allocated to each user in step 401 needs to follow the following guidelines: Assume that from the point in time when the new shared key is valid to the point in time when the broadcast / multicast server wants the user group to complete the centralized request for shared key work The length is TA; the length of time required for a user to initiate a request and finally obtain a new shared key is TB; then, the range of time T should be selected to ensure that T is less than TA minus TB, that is, to ensure that users in the group want to concentrate on the network Get the shared key within the time period for which the shared key was requested. Within this selection range, T should be selected to ensure that the user sends a new shared key request to the network evenly between the two time points, TA and TB.

To ensure that users in the group evenly initiate new shared key request messages to the network, the time T can be generated by the following method:

The broadcast / multicast server uses a uniformly distributed random function with a range of [0, TA-TB) to generate the time T, that is, the sample points of the random function are uniformly distributed with probability. The value of T can be continuous or discrete. If it is discrete, the interval between discrete points is fixed. Fixed T _x . Alternatively, the broadcast / multicast server generates a specific time τ through a fixed function method, and the time T satisfies a uniform distribution in probability, such as a well-known function such as a modulus method and a HASH function method. For example, the modulo method can be expressed as: T = (N mod a) * (TA-TB) / a, where N is the sequence number of the current user terminal to join the multimedia broadcast / multicast service, and a is the subtraction of TA TB difference 5 Total number of evenly divided time periods.

Steps 402 to 403: After the broadcast / multicast server updates the shared key, the network sends a new key valid message to all user terminals; after each user terminal receives the new key valid message sent by the network, it starts to act as its own key. A timer corresponding to the allocated time T; when the timer expires, the user terminal sends a request key message to the broadcast / multicast server; the broadcast / multicast server receives the request key cancellation

After the message is sent, send a new shared key to the user terminal that initiated the request. All user terminals mentioned here refer to: all users in the current group, that is, all legal users recorded in the broadcast / multicast server,

:. These users do not include illegal users such as users who have just left the network.

In order to better ensure the discreteness of the request initiation time of each group of users, a random number may also be randomly generated by the user terminal currently initiating the request as the additional delay time T _add , then,

15 The user terminal needs to continue to delay T _add before sending a request key message to the broadcast / multicast server.

In fact, T + T _{add is} used as the request initiation time of the user terminal. Of course, the starting point of the timing is still the time when the user terminal receives the new key valid message. The T _add is generated within a time interval T _x from the present discrete point to the next discrete point to which the user terminal belongs, as shown in FIG. 7, that is, the additional delay time T _add obeys [0, T _x ) in probability. Is uniformly distributed and is generated within the time period to which the user terminal o belongs. The generation time of the T _add can have two cases:

1) While the network uniformly allocates time T to each group of users, that is, the user terminal receives: After the time T allocated to itself, a fixed additional delay time T _add is generated, and T + is directly added each time thereafter. T _{add is} used as the request initiation time of the user terminal.

2) After the user terminal receives the new key valid message, this situation is further divided into three sub-5 cases: a) When the timer is started, the user terminal generates a random number as an additional delay Time T _add ; b) after the timer expires, the user terminal generates a random number as an additional delay time T _add ; c) at any time during the timer counting process, the user terminal generates a random number as an additional delay time T _add . For the three sub-cases a, b, and c, the user terminal uses T + T _add as the user terminal's request initiation time, but due to the additional delay time T _add , each time a new key valid message is received It is generated randomly afterwards, so the value of T _add is different each time, that is, in this case, the additional delay time T _add is variable.

5-7, the present invention will be further described in detail with reference to specific embodiments. Among them, FIG. 5 is a schematic diagram of relationships between various time points involved in the present invention. Time point 51 in FIG. 5 is a time point when user i joins a broadcast / multicast service; time point 52 is a time when user j joins a broadcast / group. Time point of the broadcast service; Time point 53 is the time point when the broadcast / multicast server notifies the user that the new key is valid; Time point 54 is the time point when the user uses the new key; Time point 55 is the user group expected by the broadcast / multicast server The point in time when the group completes the centralized request for shared key work. FIG. 6 is a schematic diagram showing the relationship between discrete time points generated in the method of the present invention. Figure 7 is a schematic diagram of the relationship between the additional delay time and the point of departure. In the following embodiments, the users refer to users in a group, and the user terminal refers to a terminal device corresponding to a corresponding group of users. Embodiment one:

In this embodiment, the time T allocated for the user terminal is directly used as the request initiation time of the user terminal, that is, the timer arrives at time D, and the user terminal sends a request key message to the broadcast / multicast server. Then, the specific process of implementing key distribution in this embodiment includes:

Step 11: When a user joins the multimedia broadcast / multicast service, the broadcast / multicast server allocates a time T to the user, and notifies the user who has joined the multimedia broadcast / multicast service of the allocated time T, and the user sets the duration for himself Is the timer of T.

This time T has the following characteristics: It is assumed that the broadcast / multicast server notifies the user that the new shared key of the group is valid, that is, the user in the group is notified that a key request message can be sent to the broadcast / multicast server The server expects the time interval for the user group to complete the centralized request for shared key work to be TA; the time interval required for user M to initiate a request and broadcast / multicast server to process until user M finally obtains a new shared key is TB; then The selection range of T must be ^^ (^-^). Because the broadcast / multicast server expects that the time when the user group completes the centralized request for the shared key and the time when the user uses the new key may overlap, the above range of values can ensure that all users in the group get the new shared key. The network then uses the new shared secret.

For example, user i and user j respectively join the broadcast / multicast service, and the broadcast / multicast server uses a uniform, distributed, random function in the range [0, ΤΑ-ΤΒ). The time allocated to user i is Ti , Ti = ti, the time allocated to user j is Tj, Tj =. The values of Ti and η can be continuous or discrete. If the time points are discrete, the interval between two adjacent discrete points is fixed as T _x , as shown in FIG. 6.

The broadcast / multicast server can also use a fixed function to allocate time for user i and user j. For example, using a modulo method: The broadcast / multicast server divides the time period [0, TA-TB) into 100 time periods, that is, The length of each time period T _x is (TA-TB) 7100. Then, if user i is the 89th joined user and user j is the 2392th joined user, then T (89 mod 100) * (TA-TB) / 100 = (TA-TB) * 89/100;

(2392 mod 100) * (TA-TB) / 100 = (TA-TB) * 92/100.

Step 12: Continue taking user i and user j as an example. The broadcast / multicast server sends a message that the new key is valid to all users. After receiving the message, user i and user j do not immediately send the message to the broadcast / multicast server. A request key message is sent, but the timers corresponding to Ti and η are immediately triggered. Here, the length of the timer started by user i is ti, and the length of the timer started by user j is tj.

Step 13: User i and user j respectively send a request key message to the broadcast / multicast server to request a new shared key after their respective timers expire; after receiving the request, the broadcast / multicast server respectively sends requests to different The requesting user returned a new shared secret.

For user i, after the corresponding timer Ti expires, user i sends a broadcast / multicast The server sends a request key message; after receiving the request key message, the broadcast / multicast server interacts with user i and sends the key to user i. Similarly, for user j, when the corresponding timer η expires, user j also sends a request key message to the broadcast / multicast server; after receiving the request key message, the broadcast / multicast server performs a request with user j Interact and send the key to user j.

If Ti or Tj needs to be updated, the new Ti or 'η can be sent by the broadcast / multicast server to the corresponding user i or user j during the above interaction process. This is because the network side, specifically the broadcast / group The server controls the key request time of all users, and it can adjust the user request time according to the requirement of uniform distribution of users. For any user, because they send the request key message to the broadcast / multicast server at different times, network congestion caused by sending the request key message at the same time can be avoided. Embodiment two:

In this embodiment, the user terminal currently initiating the request randomly generates an additional delay time T _add , and the additional delay time T _{add is} generated after the timer reaches the time T. In this embodiment, T + T _{add is} used as the request initiation time of the user terminal, that is, T _{add is} delayed after the timer reaches the time T, and then the user terminal sends a request key message to the broadcast / multicast server. Then, the specific process of implementing key distribution in this embodiment includes:

Steps 21 to 22: All descriptions are the same as steps 11 to 12 in the first embodiment.

Step 23: After the respective timers expire, the user i and the user j generate a random number as an additional delay time T _add , such as T _add , i or T _add , j, and continue to delay T _add , ^ T _add , j, and then send a request key message to the broadcast / multicast server to request a new shared key; after receiving the request, the broadcast / multicast server returns a new shared key to different requesting users, respectively. Here, T _add , i represents the additional delay time of the user i, and T _add , j represents the additional delay time of the user j, as shown in FIG. 7. Here, T _add can also be generated by the broadcast / multicast server and sent to the user who currently initiates the request. Then, for user. I, after delaying Ti + T _add , i, user i sends a request key message to the broadcast / multicast server; for user j, after delaying Tj + T _add , j User j sends a request key message to the broadcast / multicast server.

In this step, the additional delay time T _{add of} each user is generated between the present discrete point and the next discrete point. That is, for the user i, T _add , i is randomly generated within the time range of Ti + Tχ), and the values of T _add , i obey a uniform distribution of 0 _≦ Ti ≦ T _x in probability. Similarly, for user j, T _add , j is randomly generated within the time range of [Tj, Tj + T _x ), and the values of T _add , j obey a uniform distribution of 0 <≦ Tχ in probability. Example three:

In this embodiment, the user terminal currently initiating the request randomly generates an additional delay time.

T _add , and the additional delay time T _add is generated when the user terminal receives a new key valid message. In this embodiment, T + T _{add is} used as the request initiation time of the user terminal. The value of the timer can be directly set to T + T _add . After the timer expires, the user terminal sends a request to the broadcast / multicast server. Key message. Then, the specific process of implementing key distribution in this embodiment includes:

Step 31: When the user joins the multimedia broadcast / multicast service, the broadcast / multicast server allocates a time T to the user, and notifies the user who joined the multimedia broadcast / multicast service of the allocated time T; the user receives the time After T, a random number is generated randomly as an additional delay time T _add ; then, the user sets a timer with a duration of T + T _add .

Here, the characteristics and generation method of time T are exactly the same as the characteristics and generation method of time T described in step 11 of the first embodiment. The characteristic of the additional delay time T _add is exactly the same as that described in step 23 of the second embodiment.

Step 32: The broadcast / multicast server sends a message that the new key is valid to all users. The user who received the message does not immediately send a request key message to the broadcast / multicast server, but immediately triggers the timing set by itself. Device. Here, the length of the timer started by the user is T + T _add . Step 33: After the timer expires, send a request key message to the broadcast / multicast server to request a new shared key. After receiving the request, the broadcast / multicast server returns a new shared secret to different requesting users. key.

For user i, the additional delay time is T _add , i, then after delay Ti + T _add , i, user i sends a request key message to the broadcast / multicast server; for user j, the additional delay time is T _add , j, after delaying Tj + T _add , j, user j sends a request key message to the broadcast / multicast server.

The above description is only the preferred embodiments of the present invention, and is not intended to limit the protection scope of the present invention.

Claims

Claim

1. A method for implementing multimedia broadcast / multicast service key distribution, characterized in that the method includes the following steps:

c When the timer described in step b expires, the user terminal corresponding to the timer sends a request key message to the broadcast / multicast server; after receiving the request key message, the broadcast / multicast server sends the request key message to the user terminal that initiated the request Send a new shared secret.

2. The method according to claim 1, further comprising: step a and step b: each user terminal generates a random number as an additional delay time after receiving the time T allocated to itself;

Then, in step b, the user terminal that receives the new key valid message has a startup time length of time.

T plus timer for additional delay time.

3. The method according to claim 1, characterized in that, when the user terminal starts the timer in step b, or after the user terminal starts the timer, or before the request key message is sent after the timer expires in step c, The method further includes: the user terminal corresponding to the timer generates a random number as an additional delay time;

Then, after the timer expires in step c, after continuing to delay the additional delay time, the user terminal sends a request key message to the broadcast / multicast server.

4. The method according to claim 1, 2 or 3, wherein the network side allocates time T to the group user when the group user joins the multimedia broadcast / multicast service; or in the group After the user joins the multimedia broadcast / multicast service, time T is allocated to the group user; or when the shared key is sent to the group user, time τ is allocated to the group user.

5. The method according to claim 4, wherein the network side assigning time T to each group user is specifically: a broadcast / multicast server assigns time T to each group user.

6. The method according to claim 1, 2 or 3, wherein the value of the time T is located from the time when the new shared key is valid until the broadcast / multicast server expects the user group to complete the centralized request for the shared key. The time length of the working time point is different from the length of time required by the user from initiating the request to finally obtaining a new shared key, and it meets a uniform distribution in probability.

7. The method according to claim 6, wherein the time T is generated by a random function, and sample points of the random function obey a uniform distribution in probability.

8. The method according to claim 6, wherein the time T is generated by a modulo method or a HASH function method.

9. The method according to claim 6, wherein the network side allocates time T to the group user when the group user joins the multimedia broadcast / multicast service; or joins the group user to the multimedia broadcast / group Allocate time T to the group users after broadcasting the service; or allocate time T to the group users when sending the shared key to the group users.

10. The method according to claim 2 or 3, wherein the additional delay time is generated within a time interval T _χ between the current discrete point and the next discrete point to which the user terminal that is currently initiating the request belongs, and is probabilistic. subject _[0, Τ Χ] uniform distribution.

11. The method according to claim 10, wherein the network side allocates time T to the group user when the group user joins the multimedia broadcast / multicast service; or joins the group user to the multimedia broadcast / group Allocate time T for the group user after broadcasting the service; or allocate time τ for the group user when sending the shared key to the group user.

12. The method according to claim 1, 2, or 3, wherein the step of updating the shared key and issuing a new key valid message on the network side in step b is specifically: a broadcast / multicast server update Share the key; after that, the broadcast / multicast server sends a new key valid message to all users in the group in step a.