WO2005008949A1 - Procede de mise a jour d'une cle partagee au sein d'un groupe de trafic en multidiffusion - Google Patents

Procede de mise a jour d'une cle partagee au sein d'un groupe de trafic en multidiffusion Download PDF

Info

Publication number
WO2005008949A1
WO2005008949A1 PCT/CN2004/000849 CN2004000849W WO2005008949A1 WO 2005008949 A1 WO2005008949 A1 WO 2005008949A1 CN 2004000849 W CN2004000849 W CN 2004000849W WO 2005008949 A1 WO2005008949 A1 WO 2005008949A1
Authority
WO
WIPO (PCT)
Prior art keywords
shared key
group
users
multicast
list
Prior art date
Application number
PCT/CN2004/000849
Other languages
English (en)
French (fr)
Inventor
Yingxin Huang
Xiaoqin Duan
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2005008949A1 publication Critical patent/WO2005008949A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H04L9/0833—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Definitions

  • the present invention relates to a group shared key technology, and in particular, to a method for updating a shared key of a multicast / broadcast service group. Background of the invention
  • the multicast / broadcast service refers to a one-to-multipoint unidirectional bearer service. Data is sent from one original entity to multiple receiving entities, and data is sent from the multicast / broadcast server to multiple terminals.
  • users who have subscribed to the multicast / broadcast service can enjoy the services of the multicast / broadcast service.
  • the multicast / broadcast service in order to prevent users who have not subscribed to the multicast / broadcast service or have not paid to enjoy the services of the multicast / broadcast service, a key needs to be set in the multicast / broadcast service, and the key is only multicast
  • the users in the / broadcast service group and the multicast / broadcast server know.
  • a multicast / broadcast server refers to a functional entity that can provide multicast / broadcast services and has key generation management functions. It can be a new functional entity in a wireless communication network, or it can be one of the existing wireless communication networks. Functional entity or combination of multiple functional entities.
  • the multicast / broadcast server shares the set key with all users in the group, so this set key can be called the multicast / broadcast service group shared key.
  • the multicast / broadcast server sends the encrypted shared key to each user in the group separately. This sending process is performed by the multicast / broadcast server and each user one-to-one.
  • the users in the group and the multicast / broadcast server perform mutual authentication through the authentication and key agreement protocol (AKA). During the mutual authentication process, the user and the multicast / broadcast server generate and own the encryption key (KEK) at the same time.
  • the encryption key 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, so the secure transmission of the shared key can be guaranteed.
  • the multicast / broadcast server uses the encryption key corresponding to the users in the group to encrypt the shared key, and then sends the encrypted shared key It is sent to the corresponding users in the group, and the user uses the corresponding encryption key to decrypt the shared key, and finally realizes the key sharing between the multicast / broadcast server and the users in the group.
  • the multicast / broadcast server uses the shared key to encrypt the multicast / broadcast service information, and then sends it to each user in the group.
  • the user uses the shared key to decrypt the multicast / broadcast service information, obtain the multicast / broadcast service information, and finally enjoy Services to multicast / broadcast services.
  • the shared key is not static and needs to be updated frequently.
  • the multicast / broadcast server must send a new shared key to users in each group, and then all users in the group and the multicast / broadcast server switch the shared key to the new shared secret. key.
  • the update of the shared key is performed one-to-one between the multicast / broadcast server and the users in the group.
  • the multicast / broadcast server needs to communicate with each user in the group at the same time. Therefore, during the shared key update process
  • the communication volume is relatively large. If the number of users in the group is large, the update of the shared key will cause an instant increase in the amount of information in the wireless communication network, overloading the wireless communication network communication load, and further blocking the communication of the wireless communication network. . Summary of the invention
  • the main object of the present invention is to provide a method for updating a shared key of a multicast / broadcast service group, which reduces the communication of the wireless communication network by reducing the communication amount between the multicast / broadcast server and the users in the group.
  • the burden is achieved at the same time to prevent users in the group from leaking multiple secret data stored by themselves to illegal users.
  • the present invention provides a method for updating a shared key of a multicast / broadcast service group.
  • the method includes the following steps:
  • the multicast / broadcast server sends the current shared key, the shared key serial number count next time, and the updated shared key list information that contains a serial number greater than one and the corresponding shared key to the users in the group. Said the information received by the users in the group is stored;
  • the multicast / broadcast server broadcasts a shared key switch command carrying a new shared key sequence number count for the next switch to the users in the group, and the users in the group take out from the stored updated shared key list
  • the shared key whose serial number is the same as the shared key sequence number of the next switch, and the multicast / broadcast server switches the shared key to the current shared key at the same time, and the users in the group switch the current next switch.
  • the value of the shared key sequence number count is replaced with a new shared key sequence number count for the next switch.
  • step B the following steps are further included:
  • step D The users in the group determine whether there is a sequence number in the updated shared key list stored in the group that is consistent with the current shared key sequence number count of the next switch, and if it exists, no processing is performed; otherwise, step D is performed. ;
  • the users in the group send a request to update the shared key list to the multicast / broadcast server.
  • the multicast / broadcast server After receiving the update of the shared key list request from the users in the group, the multicast / broadcast server sends the request to the group to the group.
  • the internal users send an updated shared key list response carrying the newly updated shared key list, and the users in the group replace the original updated shared key list with the newly updated shared key list.
  • the method further includes: after the user in the group completes the last shared key switch, repeat step C according to a preset time period.
  • the method further includes: the user in the group deletes the shared key included in the updated shared key list.
  • the method further includes: the multicast / broadcast server encrypts and updates each shared key included in the shared key list,
  • the method further includes: decrypting the shared key list by the users in the group Switch to the shared secret of the current shared secret.
  • the decryption is performed after the users in the group take out a shared key with a sequence number that is the same as the number of the shared key sequence number of the current switch next time from the updated shared key list.
  • the encryption and decryption are performed using an encryption key corresponding to users in the group.
  • the encryption and decryption are performed using a combination of an encryption key corresponding to users in the group and a random number corresponding to a shared key,
  • the step A further comprises: the multicast / broadcast server sets and stores the correspondence between the random number and the update serial number in the shared key list;
  • the shared key switch command described in step B further carries: a random number corresponding to a sequence number of the current shared key sequence number switch next time.
  • the users in the group described in step A are the users in the group that meet the user identity requirements preset by the multicast / broadcast server.
  • the method further includes: the multicast / broadcast server broadcasts the update shared key list cancellation notification to the users in the group, and after receiving the notification, the group users delete the updated shared key list stored by themselves;
  • the broadcast server sends a request to update the shared key list, and after receiving the request, the multicast / broadcast server sends an update shared key list response to the users in the group carrying the newly updated shared key list, the group Internal users store a list of newly updated shared keys.
  • the users in the group store the updated shared key list sent by the multicast / broadcast server, so that the users in the group store the shared keys to be used, avoiding the shared keys of the users in the group. Updates at the same time, resulting in an instant surge in the amount of information on the wireless communication network, thereby avoiding excessive communication load on the wireless communication network, and further preventing communication on the wireless communication network from being blocked.
  • the present invention sends a shared key sequence number count for the next switch to the users in the group through the multicast / broadcast server to ensure that the multicast / broadcast server and the users in the group When the key is switched, the same shared key can be switched at the same time.
  • the multicast / broadcast server determines whether to send an updated shared key list to the user according to the identity of the user, which effectively enhances the security of the shared key.
  • FIG. 1 is a flowchart of updating a shared key for a multicast / broadcast service group in the present invention
  • FIG. 2 is a flowchart of an embodiment of the present invention. Mode of Carrying Out the Invention
  • C_SHARE shared key sequence number count
  • N_SHARE_LIST shared key list
  • C—SHARE refers to the shared key currently being used by the multicast / broadcast server and the users in the group. It should be a data structure, including the shared key currently being used by the multicast / broadcast server and the users in the group. The serial number corresponding to the shared key. C-SHARE can also store only the shared key that the multicast / broadcast server and users in the group are currently using, without including the serial number corresponding to the current shared key.
  • K_COUNT is actually a shared key serial number counter for the next switch, that is, a serial number count corresponding to the shared key to be switched next time, and used to identify a serial number corresponding to the shared key to be switched next time.
  • K_COUNT is increased by 1, and the value range of K_COUNT can be set, for example, 0 ⁇ 128.
  • the count of K_COUNT reaches 128, it automatically returns to 0 and continues counting from 0.
  • Multicast / broadcast server and users in the group Use K_COUNT to make both ends use the same shared secret.
  • K_COUNT can also be a number randomly generated by the multicast / broadcast server.
  • N—SHARE—LIST refers to the shared key that the multicast / broadcast server and users in the group will use. Each element in the list should actually be a data structure, that is, the multicast / broadcast server and users in the group will use it. The shared key and a serial number corresponding to the shared key.
  • the N_SHARE_LIST can contain multiple elements, for example, each N_SHARE_LIST can contain 128 elements, or each N_SHARE_LIST can contain 10 elements.
  • the multicast / broadcast server sends N_SHARE_LIST to the users in the group, and the users in the group store N_SHARE_LIST, so that the users in the group store the shared key to be used, so they are sharing
  • the users in the group directly take the corresponding shared key from the N-SHARE-LIST and switch to the current shared key to avoid the wireless communication network information caused by the simultaneous update of the shared key of the users in the group.
  • the amount of traffic surges instantaneously, thereby avoiding overloading the communication load of the wireless communication network, and further preventing the communication of the wireless communication network from being blocked.
  • FIG. 1 is a flowchart of updating a shared key of a multicast / broadcast service group according to the present invention.
  • a specific implementation process of updating a shared key of a multicast / broadcast service group includes the following steps: Step 101 to Step 103 : Set N_SHARE_LIST and K_COUNT in the multicast / broadcast server, the multicast / broadcast server sends N_SHARE_LIST and K_COUNT to the users in the group, and the users in the group store the received N_SHARE — LIST and K— COUNT, K— COUNT is the serial number of the shared key to be switched.
  • the multicast / broadcast server When the user turns on and authenticates as a user in the group that has ordered the multicast / broadcast service, or when the user in the group sends a N_SHARE_LIST request to the multicast / broadcast server, the multicast / broadcast server sends N-SHARE-LIST to the user.
  • the multicast / broadcast server sends K to the group— COUNT.
  • Step 104 ?? Step 105 The multicast / broadcast server broadcasts the shared key to the users in the group. Change the command.
  • the users in the group take out the shared key with the same serial number as the current K_COUNT from N-SHARE-LIST, and switch the shared key to the current shared key.
  • the shared key switch command broadcast by the multicast / broadcast server to the users in the group carries a new K_COUNT corresponding to the next shared key switch, and the users in the group store the K_COUNT, that is, update their own stored K— COUNT.
  • the N_SHARE_LIST may not contain the shared key with the same sequence number as K_COUNT, so after each shared key switch, the user pair in the group is increased. Whether there is a sequence number consistent with K_COUNT in the N_SHARE_LIST to determine the process, if it exists, wait for the next shared key switch; otherwise, request the multicast / broadcast server to provide N_SHARE_LIST, Ensure that the N-SHARE-LIST stored by the users in the group contains the shared key to be used.
  • FIG. 2 is a flowchart of an embodiment of the present invention. As shown in FIG. 2, the specific process of implementing multicast / broadcast service group shared key update in this embodiment includes the following steps:
  • Step 201 When user A is not turned on, the multicast / broadcast server broadcasts the shared key switch command to users in the group other than user A, and the multicast / broadcast server and the users in the group that receive the shared key switch command simultaneously Complete the shared key switch.
  • Steps 202 to 203 User A turns on after a period of time, and after authentication of the wireless communication network, confirms that user A is a user in the group that has subscribed to the multicast / broadcast service.
  • the multicast / broadcast server and user A are generated and owned at the same time.
  • the multicast / broadcast server determines whether to send N-SHARE-LIST to user A. In practical applications, the multicast / broadcast server may determine whether to send N-SHAREJLIST to user A according to the identity of the user. In this embodiment, user A is prepaid.
  • the multicast / broadcast server determines that user A is a fixed user, determines that it can send N_SHARE_LIST to user A, and then sends C_SHARE, N to user A —SHAREJLIST and K_ COUNT, user A receives C—SHARE, N_SHARE— LIST and K_COUNT is stored.
  • the multicast / broadcast server determines whether to send N_SHARE_LIST to the user according to the identity of the user, and may only send N_SHARE_LIST to the fixed user, thereby enhancing the security of the shared key.
  • N_SHARE_LIST contains 5 elements.
  • Step 204 The multicast / broadcast server broadcasts the shared key switch command to the users in the group.
  • User A takes the shared key with the same serial number as the current K_COUNT from N-SHARE-LIST, and uses its own encryption key to The shared key is decrypted, and then the shared key is switched to the current shared key. After user A finishes switching the shared key, the user A deletes the shared key included in N-SHARE-LIST that has been switched to the current shared key.
  • the shared key switch command broadcasted by the multicast / broadcast server to the users in the group carries a new K__COUNT corresponding to the next shared key switch. User A stores the K_COUNT, that is, it updates its stored K_COUNT.
  • user A may not decrypt the shared key used in N_SHARE_LIST in the future.
  • the shared key is switched, the corresponding shared key is taken out for decryption to be effective. Prevent users outside the group from stealing the shared secret.
  • Step 205 After two shared key switchovers, because N_SHARE_LIST in this embodiment contains 5 elements, before the third shared key switchover, user A can determine that the N_SHARE_LIST stored in the user_A K_COUNT is the same serial number, so wait for the next shared key switch.
  • the above-mentioned time point before the shared key switch may be selected as that after the current shared key switch is completed, the users in the group can determine whether a sequence consistent with the current K_COUNT exists in N-SHARE-LIST according to a preset time period.
  • the time period here means that the users in the group will perform a judgment every once in a while, and this time period can ensure that it can be performed once before the next shared key switch, and the users in the group can be added to the multicast.
  • Time of broadcast service as the time period Starting point to avoid a large number of users in the group applying to the multicast / broadcast server at the same time
  • the user A can determine whether there is a sequence number in the N_SHARE_LIST that is consistent with K_COU T. This can make the judgment more practical because When user A has not performed the shared key switch, the stored N-SHARE_LIST must contain the shared key required for the shared key switch, so user A does not need to check whether the existence of the N-SHARE_LIST and the current K — COUNT matches the serial number.
  • Step 206 is basically the same as step 204.
  • Step 206 is another shared key switch after four shared key switches, that is, the fifth shared key switch.
  • the N-SHARE-LIST stored by user A does not include the next shared key switch.
  • the shared secret required.
  • Step 207 Before the next shared key switch, user A determines that there is no sequence number in the N-SHARE-LIST stored in the N-SHARE-LIST that is consistent with the current K-COUNT, and then executes step 208.
  • the above-mentioned time point before the shared key switch may be selected to be that after the current shared key switch is completed, user A performs a pre-set time period on whether a sequence number consistent with the current K_COUNT exists in N_SHARE_LIST Judge.
  • Step 208 to step 209 User A sends an N-SHARE-LIST request to the multicast / broadcast server. After receiving the N_SHARE_LIST request from user A, the multicast / broadcast server sends an N_SHARE_LIST response with SHARE_LIST to user A; N_SHARE_LIST contains the shared key to be used later These shared keys are encrypted by the multicast / broadcast server using an encryption key corresponding to user A. After user A receives the N_SHARE_LIST response, it stores the received N_SHARE_LIST.
  • Step 210 is basically the same as step 204.
  • the multicast / broadcast server can send special encrypted N-SHARE-LIST to users in the group.
  • the multicast / broadcast server generates a set of random numbers RAND_DATA [i] corresponding to each sequence number in N_SHARE_LIST while generating N_SHARE_LIST, and then uses the encryption key corresponding to i
  • the combination of the random number encrypts the shared key corresponding to i; the same method is used to encrypt each shared key included in the N_SHARE_LIST, and the multicast / broadcast server sends N_SHARE_LIST to the group user.
  • the multicast / broadcast server stores RAND_DATA [i] and its correspondence with the shared key serial number.
  • the shared key switch command When the multicast / broadcast server broadcasts the shared key switch command to users in the group, in addition to the new K_COUNT, the shared key switch command further carries a random number RAND_DATA corresponding to the current K_COUNT. [i].
  • the users in the group After receiving the switch command, the users in the group take out the shared key with the same serial number as the current K_COUNT from their stored N-SHARE-LIST, and then use the combination of the encryption key and the current random number to decrypt the shared key. Decrypt, and finally switch the shared key to the current shared key.
  • the multicast / broadcast server considers that the existing N-SHARE-LIST is not secure, cancels these N-SHARE-LISTs, and generates a new N-SHARE-LIST.
  • the multicast / broadcast server broadcasts the N_SHARE_LIST cancellation notification to the users in the group.
  • the users in the group receive the N_SHARE_LIST cancellation notification
  • the users in the group that owns the list know that they should delete the N_SHARE_LIST stored by themselves and need Apply for a new N_SHARE_LIST.
  • users in the group should apply for a new N_SHARE_LISTo to the multicast / broadcast server according to their own specific periodicity.

Description

一种多播 /广播业务群组共享密钥的更新方法
技术领域
本发明涉及群组共享密钥技术，特别是指一种多播 /广播业务群组共 享密钥的更新方法。 发明背景
在无线通信网络中 , 多播 /广播业务是指一点到多点的单向承载业 务， 数据由一个原实体发送至多个接收实体，数据由多播 /广播服务器发 送至多个终端。在一定区域内， 已经订阅多播 /广播业务的用户能够享受 多播 /广播业务的服务。 在多播 /广播业务中， 为防止没有订阅多播 /广播 业务或未付费的用户享受到多播 /广播业务的服务， 需要在多播 /广播业 务中设置密钥 , 并且密钥只有多播 /广播业务群组内用户和多播 /广播服 务器知道。 多播 /广播服务器是指能够提供多播 /广播服务， 兼具密钥生 成管理功能的功能实体， 可以是在无线通信网络中新增的功能实体, 也 可以是现有无线通信网络中的一个功能实体或多个功能实体的组合。
多播 /广播服务器和群组内所有用户共享设置的密钥， 因此可将这个 设置密钥称为多播 /广播业务群组共享密钥。 多播 /广播服务器向群组内 每个用户单独发送加密的共享密钥，这个发送过程是多播 /广播服务器和 每个用户一对一进行的。群组内用户和多播 /广播服务器通过鉴权和密钥 协商协议（AKA )进行互鉴权， 在互鉴权过程中， 用户和多播 /广播服务 器同时生成并拥有加密密钥 ( KEK ), 该加密密钥用来加密共享密钥, 群组内每个用户的加密密钥是唯一的， 即群组内用户拥有的加密密钥各 不相同， 因此可保证共享密钥的安全传送。 多播 /广播服务器使用与群组 内用户相对应的加密密钥加密共享密钥， 然后将经过加密的共享密钥发 送给群组内相应用户， 用户使用与其相对应的加密密钥解密共享密钥， 最终实现多播 /广播服务器和群组内用户的密钥共享。 多播 /广播服务器 使用共享密钥加密多播 /广播业务信息， 然后发送给群组内每个用户， 用 户使用共享密钥解密多播 /广播业务信息， 获取多播 /广播业务信息， 最 终享受到多播 /广播业务的服务。
为防止群组外的用户享受多播 /广播业务， 共享密钥不是一成不变 的， 需要经常更新。 共享密钥更新时， 多播 /广播服务器要分别向每个群 组内用户发送新的共享密钥，然后群组内所有用户和多播 /广播服务器共 同将共享密钥切换至新的共享密钥。共享密钥的更新是多播 /广播服务器 和群组内各用户间一对一进行的，多播 /广播服务器需要同时和群组内每 个用户进行一次通信， 因此在共享密钥更新过程中， 通信量比较大， 如 果群组内用户数量艮多 , 则共享密钥更新将导致无线通信网络中的信息 量瞬间激增， 使无线通信网络通信负担过重， 进而使无线通信网络的通 信受到阻塞。 发明内容
有鉴于此，本发明的主要目的在于提供一种多播 /广播业务群组共享 密钥的更新方法， 通过降低多播 /广播服务器和群组内用户间的通信量， 减轻无线通信网络的通信负担， 同时达到防止群组内用户将自身存储的 多个秘密数据泄露给非法用户的目的。
为了达到上述目的，本发明提供了一种多播 /广播业务群组共享密钥 的更新方法， 该方法包含以下步骤：
A、 多播 /广播服务器向群组内用户发送当前共享密钥、 下次切换共 享密钥序列号计数和包含有大于一个的序列号及相对应共享密钥的更 新共享密钥列表信息， 所述群组内用户存储收到的所述信息； B、 多播 /广播服务器向所述群组内用户广播携带有新下次切换共享 密钥序列号计数的共享密钥切换命令， 所述群组内用户从存储的更新共 享密钥列表中取出序列号与当前下次切换共享密钥序列号计数相同的 共享密钥， 与多播 /广播服务器同时将所述共享密钥切换为当前共享密 钥， 所述群组内用户将当前下次切换共享密钥序列号计数的值替换为新 的下次切换共享密钥序列号计数。
所述步骤 B之后进一步包括以下步驟：
C、 所述群组内用户判断自身存储的更新共享密钥列表中是否存在 与当前下次切换共享密钥序列号计数相一致的序列号， 如果存在， 则不 进行处理， 否则， 执行步骤 D;
D、所述群组内用户向多播 /广播服务器发送更新共享密钥列表请求， 多播 /广播服务器收到来自所述群组内用户的更新共享密钥列表请求后， 向所述群组内用户发送携带有新更新共享密钥列表的更新共享密钥列 表响应， 所述群组内用户使用新更新共享密钥列表替换原有更新共享密 钥列表。
该方法进一步包括： 所述群组内用户完成上一次共享密钥切换后， 根据预先设定的时间周期重复执行所述步骤 C。
步骤 B 中所述群组内用户将所述共享密钥切换为当前共享密钥之 后， 进一步包括： 所述群组内用户将更新共享密钥列表中包含的所述共 享密钥删除。
步骤 A 中所述多播 /广播服务器向群组内用户发送更新共享密钥列 表之前， 进一步包括： 多播 /广播服务器加密更新共享密钥列表中包含的 每个共享密钥，
所述步骤 B 中所述与多播 /广播服务器同时将所述共享密钥切换为 当前共享密钥之前， 进一步包括： 所述群组内用户解密共享密钥列表中 将切换为当前共享密钥的的共享密钥。
所述解密是在所述群组内用户从更新共享密钥列表中取出序列号与 当前下次切换共享密钥序列号计数相同的共享密钥之后进行的。
所述加密和解密是使用与所述群组内用户相对应的加密密钥进行 的。
所述加密和解密使用与所述群组内用户相对应的加密密钥和对应于 共享密钥的随机数的组合进行的，
所述步骤 A进一步包括：多播 /广播服务器设置并存储所述随机数与 更新共享密钥列表中序列号的对应关系；
步骤 B中所述的共享密钥切换命令中进一步携带有： 与当前下次切 换共享密钥序列号计数的序列号相对应的随机数。
步骤 A 中所述群组内用户是符合多播 /广播服务器预先设置的用户 身份要求的群組内用户。
该方法进一步包括：多播 /广播服务器向群组内用户广播更新共享密 钥列表取消通知， 群组内用户收到所述通知后， 删除自身存储的更新共 享密钥列表； 然后向多播 /广播服务器发送更新共享密钥列表请求， 多 播 /广播服务器收到所述请求后 , 向所述群组内用户发送携带有新更新 共享密钥列表的更新共享密钥列表响应， 所述群组内用户存储新更新共 享密钥列表。
根据本发明提出的方法，群组内用户存储多播 /广播服务器向其发送 的更新共享密钥列表， 使得群组内用户存储有将使用的共享密钥， 避免 因群组内用户共享密钥的同时更新， 而导致的无线通信网络信息量瞬间 激增， 从而避免无线通信网络通信负担过重， 进而避免无线通信网络的 通信受到阻塞。 另外， 本发明通过多播 /广播服务器向群组内用户发送下 次切换共享密钥序列号计数，保证多播 /广播服务器和群组内用户在共享 密钥切换时， 能够同时切换至同一共享密钥。 此外， 本发明中群组内用 户在切换共享密钥时， 才对更新共享密钥列表中相应的密钥解密， 可有 效避免合法的群组内用户将共享密钥泄露给非群组内用户； 本发明中多 播 /广播服务器根据用户身份确定是否向用户发送更新共享密钥列表，那 个有效增强共享密钥的安全性。 附图简要说明
图 1为本发明中多播 /广播业务群組共享密钥更新流程图；
图 2为本发明中一实施例流程图。 实施本发明的方式
下面结合附图对本发明进行详细描述。
在多播 /广播服务器中除设置当前共享密钥 （C_SHARE ) 夕卜， 还设 置下次切换共享密钥序列号计数（K— COUNT ) 和更新共享密钥列表 ( N— SHARE— LIST ), 下面对它们进行详细介绍。
C— SHARE是指多播 /广播服务器和群组内用户当前正在使用的共享 密钥， 实际应为数据结构， 包括多播 /广播服务器和群组内用户当前正在 使用的共享密钥及与该共享密钥相对应的序列号。 C— SHARE也可只存 储多播 /广播服务器和群组内用户当前正在使用的共享密钥，而不包括与 当前共享密钥相对应的序列号。
K— COUNT实际为下次切换共享密钥序列号计数器， 即与下一次将 要切换的共享密钥相对应的序列号计数， 用以标识与下一次将要切换的 共享密钥相对应的序列号。 共享密钥每切换一次， K— COUNT加 1 , 可 设定 K— COUNT的取值范围，例如 0〜128,当 K— COUNT的计数达到 128 后， 自动返回至 0, 继续从 0开始计数。 多播 /广播 ϋ艮务器和群组内用户 通过 K— COUNT使两端使用相同的共享密钥。 K_COUNT也可为由多播 /广播服务器随机生成的数字。
N— SHARE— LIST是指多播 /广播服务器和群组内用户将使用的共享 密钥， 列表中的每个元素实际应为数据结构， 即多播 /广播服务器和群組 内用户将使用的共享密钥及与该共享密钥相对应的序列号。 N— SHARE— LIST中可包含多个元素， 例如， 每个 N_SHARE_LIST中可 包含 128个元素， 或每个 N— SHARE— LIST中可包含 10个元素。
在本发明中， 多播 /广播服务器向群组内用户发送 N— SHARE— LIST, 群组内用户存储 N— SHARE— LIST,使得群组内用户存储有将使用的共享 密钥， 因而在共享密钥切换时， 群组内用户直接从 N— SHARE— LIST中 取出相应的共享密钥切换为当前共享密钥， 避免因群组内用户共享密钥 的同时更新， 而导致的无线通信网络信息量瞬间激增， 从而避免无线通 信网絡通信负担过重， 进而避免无线通信网络的通信受到阻塞。
图 1为本发明中多播 /广播业务群组共享密钥更新流程图，如图 1所 示， 多播 /广播业务群组共享密钥更新的具体实现过程包括以下步驟： 步骤 101〜步骤 103: 多播 /广播服务器中设置 N— SHARE— LIST和 K— COUNT , 多播 /广播服务器向群组内用户发送 N— SHARE— LIST 和 K— COUNT, 群组内用户存储收到的 N— SHARE— LIST和 K— COUNT, K— COUNT为即将切换的共享密钥的序列号。 用户开机并认证为已定购 多播 /广播业务的群组内用户时， 或群组内用户向多播 /广播服务器发送 N_SHARE_LIST 请求时， 多播 /广播服务器向该用 户发送 N— SHARE— LIST。用户开机并认证为已定购多播 /广播业务的群组内用户 时， 或多播 /广播服务器向群组内用户广播共享密钥切换命令时， 多播 / 广播服务器向群组内发送 K— COUNT。
步骤 104〜步骤 105:多播 /广播服务器向群组内用户广播共享密钥切 换命令 ,群组内用户从 N— SHARE— LIST中取出序列号与当前 K— COUNT 相同的共享密钥， 将该共享密钥切换为当前共享密钥。 多播 /广播服务器 向群组内用户广播的共享密钥切换命令中携带有与下次切换共享密钥 相对应的新 K— COUNT, 群组内用户存储该 K— COUNT, 即更新自身存 储的 K— COUNT。
当 N—SHAREJLIST中包含的元素数量较少时， N— SHARE— LIST中 可能不包含序列号与 K— COUNT相同的共享密钥， 因此在每次共享密钥 切换后， 增加群组内用户对 N一 SHARE— LIST中是否存在与 K— COUNT 相一致的序列号进行判断过程，如果存在，则等待下一次共享密钥切换； 否则， 请求多播 /广播服务器提供 N— SHARE—LIST， 以此保证群组内用 户存储的 N— SHARE— LIST中包含即将使用的共享密钥。
图 2为本发明中一实施例流程图， 如图 2所示， 本实施例中实现多 播 /广播业务群组共享密钥更新的具体过程包括以下步驟：
步驟 201: 用户 A未开机时， 多播 /广播服务器向除用户 A外的群组 内用户广播共享密钥切换命令，多播 /广播服务器和收到共享密钥切换命 令的群组内用户同时完成共享密钥的切换。
步骤 202〜步骤 203: —段时间后用户 A开机， 经过无线通信网络的 认证， 确认用户 A为已订购多播 /广播业务的群组内用户， 多播 /广播服 务器和用户 A同时生成并拥有与用户 A相对应的加密密钥。 多播 /广播 服务器判断是否向用户 A发送 N— SHARE— LIST, 实际应用中， 多播 /广 播服务器可根据用户身份， 判断是否向用户 A发送 N—SHAREJLIST, 本实施例中， 用户 A为预付费用户， 将在较长时期内享受多播 /广播业 务， 因此多播 /广播服务器确定用户 A为固定用户， 判断出可向用户 A 发送 N— SHARE— LIST, 随后向用户 A发送 C_SHARE、 N—SHAREJLIST 和 K— COUNT , 用户 A 对收到的 C— SHARE、 N_SHARE— LIST 和 K一 COUNT进行存储。 在本实施例中， 多播 /广播服务器根据用户身份确 定是否向用户发送 N— SHARE— LIST , 可只向 固定用户发送 N— SHARE—LIST , 以此增强共享密钥的安全性。 本实施例中， N— SHARE— LIST中包含 5个元素。
步骤 204: 多播 /广播服务器向群组内用户广播共享密钥切换命令， 用户 A从 N— SHARE— LIST中取出序列号与当前 K— COUNT相同的共享 密钥， 使用自身的加密密钥将该共享密钥解密， 然后将该共享密钥切换 为当前共享密钥。 用户 A完成共享密钥的切换后， 将 N— SHARE— LIST 中包含的已切换为当前共享密钥的共享密钥删除。多播 /广播服务器向群 组内用户广播的共享密钥切换命令中携带有与下次切换共享密钥相对 应的新 K__COUNT, 用户 A存储该 K— COUNT, 即更新自身存储的 K一 COUNT。
在实际应用中， 用户 A 收到 N— SHARE— LIST 后， 可先不对 N_SHARE_LIST中以后将使用的共享密钥进行解密，等到切换共享密钥 时， 再取出相应的共享密钥进行解密， 以有效避免非群组内用户窃取共 享密钥。
步驟 205 : 经过两次共享密钥切换后， 由于本实施例中的 N_SHARE_LIST包含 5个元素， 因此用户 A在第三次共享密钥切换前， 可判断出自身存储的 N_SHARE— LIST中存在与当前 K— COUNT相一致 的序列号， 因此等待下一次共享密钥切换。 上述共享密钥切换前的时间 点可选定为完成当前共享密钥切换后， 群组内用户才艮据预先设定的时间 周期对 N— SHARE—LIST中是否存在与当前 K_COUNT相一致的序列号 进行判断， 这里的时间周期是指群组内用户每隔一段时间就执行一次判 断， 并且这个时间周期能够保证在下一次共享密钥切换前肯定能够执行 一次 ,可以将群组内用户加入多播 /广播业务的时间点作为所述时间周期 的开始点， 以尽量避免大量群组内用户同时向多播 /广播服务器申请
N— SHARE— LIST。
在实际应用中， 用户 A 可在进行过一次共享密钥切换后， 再对 N— SHARE— LIST中是否存在与 K_COU T相一致的序列号进行判断， 这样可使判断更具实际意义， 因为在用户 A还没进行过共享密钥切换 时， 其存储的 N—SHARE_LIST中一定包含共享密钥切换时所需的共享 密钥，所以用户 A不需对 N— SHARE— LIST中是否存在与当前 K— COUNT 相一致的序列号进行判断。
步骤 206与步骤 204基本相同。 步骤 206为经过四次共享密钥切换 后进行的又一次共享密钥切换， 即第五次共享密钥切换， 此时用户 A存 储的 N— SHARE— LIST中已不包含下次共享密钥切换时所需的共享密钥。
步驟 207: 用户 A 在下次共享密钥切换前， 判断出自身存储的 N— SHARE— LIST中不存在与当前 K— COUNT相一致的序列号， 然后执 行步驟 208。 上述共享密钥切换前的时间点可选定为完成当前共享密钥 切换后， 用户 A根据预先设定的时间周期对 N— SHARE— LIST中是否存 在与当前 K— COUNT相一致的序列号进行判断。
步骤 208〜步骤 209:用户 A向多播 /广播服务器发送 N— SHARE— LIST 请求。 多播 /广播服务器收到来自用户 A的 N— SHARE— LIST请求后， 向 用户 A 发送携带有 SHARE一 LIST 的 N— SHARE— LIST 响应； N— SHARE— LIST中包含以后将使用的共享密钥，这些共享密钥经过多播 /广播服务器使用与用户 A 相对应的加密密钥加密。 用户 A 收到 N一 SHARE— LIST响应后 , 存储收到的 N—SHARE—LIST。
步骤 210与步驟 204基本相同。
后续过程与以上描述基本相同， 在此不再赘述。
另外， 由于群组内用户存储 N—SHAREJJST, 为防止非群组内用户 对共享密钥的窃取， 增加 N— SHARE— LIST的安全性， 多播 /广播服务器 可向群组内用户发送经过特殊加密的 N—SHARE—LIST。 在实际应用中 , 多播 /广播服务器在生成 N— SHARE— LIST 的 同 时， 生成与 N_SHARE_LIST 中每一序列号相对应的一组随机数 RAND_DATA[i] , 然后使用加密密钥与 i相对应的随机数的组合加密与 i相对应的共享密 钥； 采用相同的方法对 N— SHARE— LIST中包含的每一个共享密钥进行 加密后， 多播 /广播服务器将 N— SHARE_LIST发送给群组内用户。 多播 / 广播服务器存储 RAND— DATA[i]及其与共享密钥序列号的对应关系。
多播 /广播服务器向群组内用户广播共享密钥切换命令时，该共享密 钥切换命令除携带有新的 K— COUNT外， 还进一步携带有对应于当前 K— COUNT的随机数 RAND— DATA[i]。 群组内用户收到切换命令后， 从 自身存储的 N— SHARE— LIST中取出序列号与当前 K— COUNT相同的共 享密钥， 然后使用加密密钥与当前随机数的组合解密该共享密钥解密， 最后将该共享密钥切换为当前共享密钥。
在实际应用中也有可能出现多播 /广播服务器认为目前存在的 N— SHARE— LIST 已经不安全、 取消这些 N— SHARE— LIST 而生成新的 N— SHARE— LIST 的情况， 在这种情况下， 多播 /广播服务器向群组内用 户广播 N_SHARE—LIST取消通知，群组内用户收到 N— SHARE— LIST取 消通知后， 使拥有列表的群组内用户获知应该删除自身存储的 N_SHARE_LIST, 并需要申请新的 N— SHARE— LIST, 这时群组内用户 就应该按照自 己特定的周期规律向多播 /广播服务器申请新的 N_SHARE_LISTo
总之， 以上所述仅为本发明的较佳实施例而已， 并非用于限定本发 明的保护范围。

Claims

权利要求书
1、 一种多播 /广播业务群组共享密钥的更新方法， 其特征在于， 该 方法包含以下步骤：
A、 多播 /广播服务器向群组内用户发送当前共享密钥、 下次切换共 享密钥序列号计数和包含有大于一个的序列号及相对应共享密钥的更 新共享密钥列表信息， 所述群组内用户存储收到的所述信息；
B、 多播 /广播服务器向所述群组内用户广播携带有新下次切换共享 密钥序列号计数的共享密钥切换命令， 所述群组内用户从存储的更新共 享密钥列表中取出序列号与当前下次切换共享密钥序列号计数相同的 共享密钥， 与多播 /广播服务器同时将所述共享密钥切换为当前共享密 钥， 所述群组内用户将当前下次切换共享密钥序列号计数的值替换为新 的下次切换共享密钥序列号计数。
2、 根据权利要求 1所述的方法， 其特征在于， 所述步骤 B之后进 一步包括以下步骤：
C、 所述群组内用户判断自身存储的更新共享密钥列表中是否存在 与当前下次切换共享密钥序列号计数相一致的序列号 , 如果存在， 则不 进行处理， 否则， 执行步驟 D;
D、所述群组内用户向多播 /广播服务器发送更新共享密钥列表请求， 多播 /广播服务器收到来自所述群组内用户的更新共享密钥列表请求后， 向所述群組内用户发送携带有新更新共享密钥列表的更新共享密钥列 表响应， 所述群组内用户使用新更新共享密钥列表替换原有更新共享密 钥列表。
3、 根据权利要求 2所述的方法， 其特征在于， 该方法进一步包括： 所述群组内用户完成上一次共享密钥切换后， 根据预先设定的时间周期 重复执行所述步骤 C。
4、 根据权利要求 1所述的方法， 其特征在于， 步骤 B中所述群组 内用户将所述共享密钥切换为当前共享密钥之后， 进一步包括： 所述群 组内用户将更新共享密钥列表中包含的所述共享密钥删除。
5、 根据权利要求 1所述的方法， 其特征在于，
步骤 A 中所述多播 /广播服务器向群组内用户发送更新共享密钥列 表之前， 进一步包括： 多播 /广播服务器加密更新共享密钥列表中包含的 每个共享密钥，
所述步驟 B 中所述与多播 /广播服务器同时将所述共享密钥切换为 •当前共享密钥之前， 进一步包括： 所述群组内用户解密共享密钥列表中 将切换为当前共享密钥的的共享密钥。
6、根据权利要求 5所述的方法， 其特征在于， 所述解密是在所述群 組内用户从更新共享密钥列表中取出序列号与当前下次切换共享密钥 序列号计数相同的共享密钥之后进行的。
7、根据权利要求 5所述的方法， 其特征在于， 所述加密和解密是使 用与所述群组内用户相对应的加密密钥进行的。
8、 根据权利要求 5所述的方法， 其特征在于，
所述加密和解密使用与所述群组内用户相对应的加密密钥和对应于 共享密钥的随机数的組合进行的，
所述步骤 A进一步包括：多播 /广播服务器设置并存储所述随机数与 更新共享密钥列表中序列号的对应关系；
步骤 B中所述的共享密钥切换命令中进一步携带有： 与当前下次切 换共享密钥序列号计数的序列号相对应的随机数。
9、 根据权利要求 1所述的方法， 其特征在于， 步骤 A中所述群組 内用户是符合多播 /广播服务器预先设置的用户身份要求的群组内用户。
10、根据权利要求 1所述的方法， 其特征在于， 该方法进一步包括： 多播 /广播服务器向群组内用户广播更新共享密钥列表取消通知， 群组 内用户收到所述通知后， 删除自身存储的更新共享密钥列表； 然后向多 播 /广播服务器发送更新共享密钥列表请求， 多播 /广播服务器收到所述 请求后， 向所述群组内用户发送携带有新更新共享密钥列表的更新共享 密钥列表响应， 所述群组内用户存储新更新共享密钥列表。
PCT/CN2004/000849 2003-07-22 2004-07-22 Procede de mise a jour d'une cle partagee au sein d'un groupe de trafic en multidiffusion WO2005008949A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CNB031460976A CN100342687C (zh) 2003-07-22 2003-07-22 一种多播/广播业务群组共享密钥的更新方法
CN03146097.6 2003-07-22

Publications (1)

Publication Number Publication Date
WO2005008949A1 true WO2005008949A1 (fr) 2005-01-27

Family

ID=34069986

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2004/000849 WO2005008949A1 (fr) 2003-07-22 2004-07-22 Procede de mise a jour d'une cle partagee au sein d'un groupe de trafic en multidiffusion

Country Status (2)

Country Link
CN (1) CN100342687C (zh)
WO (1) WO2005008949A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9948455B2 (en) 2011-09-20 2018-04-17 Koninklijke Philips N.V. Management of group secrets by group members

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7412600B2 (en) * 2005-10-28 2008-08-12 Cisco Technology, Inc. Approaches for automatically switching message authentication keys
KR101158155B1 (ko) * 2005-11-10 2012-06-19 삼성전자주식회사 휴대 방송 시스템에서 암호화 정보 송수신 방법 및 그에따른 시스템
CN1845599B (zh) * 2006-05-17 2010-09-01 中国移动通信集团公司 移动电视业务中获取及更新业务密钥的方法
CN101162997B (zh) * 2007-08-09 2010-06-02 四川长虹电器股份有限公司 一种电子设备接口间广播共享密钥的更新方法
CN103957101B (zh) * 2014-05-15 2017-05-24 三星电子（中国）研发中心 一种群组通信中的组密钥建立方法
CN104168320B (zh) * 2014-08-19 2018-01-26 三星电子（中国）研发中心 一种用户数据分享的方法和系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001076133A1 (en) * 2000-03-31 2001-10-11 British Telecommunications Public Limited Company Data distribution
WO2002025861A1 (en) * 2000-09-20 2002-03-28 The University Of Maryland Dynamic key management architecture for ensuring conditional access to secure multimedia multicast
WO2003017568A1 (en) * 2001-08-17 2003-02-27 Nokia Corporation Security in communications networks

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002290396A (ja) * 2001-03-23 2002-10-04 Toshiba Corp 暗号鍵更新システムおよび暗号鍵更新方法
US20030068047A1 (en) * 2001-09-28 2003-04-10 Lee David A. One-way broadcast key distribution

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001076133A1 (en) * 2000-03-31 2001-10-11 British Telecommunications Public Limited Company Data distribution
WO2002025861A1 (en) * 2000-09-20 2002-03-28 The University Of Maryland Dynamic key management architecture for ensuring conditional access to secure multimedia multicast
WO2003017568A1 (en) * 2001-08-17 2003-02-27 Nokia Corporation Security in communications networks

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9948455B2 (en) 2011-09-20 2018-04-17 Koninklijke Philips N.V. Management of group secrets by group members

Also Published As

Publication number Publication date
CN100342687C (zh) 2007-10-10
CN1571343A (zh) 2005-01-26

Similar Documents

Publication Publication Date Title
US8160254B2 (en) Method for managing group traffic encryption key in wireless portable internet system
CA2496677C (en) Method and apparatus for secure data transmission in a mobile communication system
JP4390808B2 (ja) 携帯無線端末及びそのセキュリティシステム
JP4898919B2 (ja) ブロードキャストサービスの暗号化されたデータを連続的にモバイル端末装置に伝送するための方法とシステム
JP2812312B2 (ja) 暗号化システム
EP1889399B1 (en) Method for managing group traffic encryption key in wireless portable internet system
WO2008000165A1 (fr) Procédé et système de fourniture de clé dans un réseau sans fil
Gong et al. Elements of trusted multicasting
JP4156588B2 (ja) 暗号通信システム、その鍵配布サーバ、端末装置及び鍵共有方法
CN100504804C (zh) 用于广播服务传输和接收的装置和方法
CN100362785C (zh) 一种共享密钥更新的方法
Gharout et al. Key management with host mobility in dynamic groups
CN100364332C (zh) 一种保护宽带视音频广播内容的方法
WO2005008949A1 (fr) Procede de mise a jour d'une cle partagee au sein d'un groupe de trafic en multidiffusion
JP2023550280A (ja) マルチキャスト暗号化鍵を分配するための方法及びデバイス
EP1880506A1 (en) System and method for efficient encryption and decryption of drm rights objects
JP2872197B2 (ja) 移動通信システム
KR20130096575A (ko) 공개키 기반 그룹 키 분배 장치 및 방법
WO2010094185A1 (zh) 安全切换方法及系统
CN101087188A (zh) 无线网络中mbs授权密钥的管理方法及系统
Eya et al. New user authentication and key management scheme for secure data transmission in wireless mobile multicast
JP2003174440A (ja) コンテンツ配信方法，コンテンツ配信システム，認証機能付きルーティング装置およびクライアント装置
JP2001211147A (ja) キーエスクロー方法
SURESH et al. Distributed Data Protection using Multi Key Authority in Disruption Tolerant Networks
KUMAR et al. Implementing Data Privacy using Decenteralized Multi Key Distribution Centers in DTN’s Networks

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase