A key sharing method and corresponding system
Abstract
A key sharing method and a system are provided. The method mainly comprises a group member sending the key information request to the neighbor group member and the neighbor group member sending the key information after receiving the request. The system mainly comprises the request group member and the response group member.

Term
No projected expiry on record.
- Priority
- Filed
- Published
- Today
14 claims: 2 independent, 12 dependent
- 1权利要求书 [1] 1、 一种密钥共享方法, 其特征在于, 包括: 组成员向邻居组成员发送密钥信息请求; 所述邻居组成员接收到所述密钥信息请求后, 向所述组成员发送所述请求 的密钥信息。
- 2[2] 2、 根据权利要求 1所述的方法, 其特征在于, 所述的密钥信息请求具体包 括: 所述的密钥信息请求包括: 密钥报文请求和密钥请求中的至少一项。
- 3[3] 3、 根据权利要求 2所述的方法, 其特征在于, 所述密钥信息请求为密钥报 文请求吋, 所述的组成员向邻居组成员发送密钥信息请求的过程, 具体包 括: 当组成员发现其组密钥和 /或辅助密钥与其它组成员不同步后, 向一个或多 个邻居组成员发送密钥报文请求, 请求所述邻居组成员向其发送携带所述 组密钥和 /或辅助密钥的密钥报文。
- 4[4] 4、 根据权利要求 3所述的方法, 其特征在于, 所述的邻居组成员接收到所 述密钥信息请求后, 向所述组成员发送所述请求的密钥信息的过程, 具体 包括: 所述邻居组成员接收到所述密钥报文请求后, 对发送所述密钥报文请求的 组成员进行身份验证, 当身份验证失败, 则停止处理所述密钥报文请求; 当所述身份验证成功后, 如果所述邻居组成员中存在所述请求的密钥报文 , 则向所述发送密钥报文请求的组成员发送所述请求的密钥报文; 否则, 通知所述发送密钥报文请求的组成员其所请求的密钥报文不存在。
- 5[5] 5、 根据权利要求 4所述的方法, 其特征在于, 所述的对发送所述密钥报文 请求的组成员进行身份验证之前还包括: 所述邻居组成员接收到所述密钥报文请求后, 对发送所述密钥报文请求的 组成员进行防攻击检査, 如果该防攻击检査失败, 则停止处理所述密钥报 文请求; 否则, 对发送所述密钥报文请求的组成员进行身份验证。
- 6[6] 6、 根据权利要求 2所述的方法, 其特征在于, 所述密钥信息请求为密钥请 求吋, 所述的组成员向邻居组成员发送密钥信息请求的过程, 具体包括: 当组成员发现其组密钥和 /或辅助密钥与其它组成员不同步后, 向一个或多 个邻居组成员发送携带请求的组密钥和 /或辅助密钥信息的密钥请求, 并在 该密钥请求中携带其身份证明和密钥拥有权限信息。
- 7[7] 7、 根据权利要求 6所述的方法, 其特征在于, 所述的邻居组成员接收到所 述密钥信息请求后, 向所述组成员发送所述请求的密钥信息的过程, 具体 包括: 所述邻居组成员根据所述密钥请求中携带的身份证明信息, 对所述发送密 钥请求的组成员进行身份验证; 在身份验证通过后, 根据所述密钥请求中 携带的密钥拥有权限信息, 对所述发送密钥请求的组成员进行权限检査; 在所述权限检査通过后, 如果所述邻居组成员中存在所述请求的组密钥和 / 或辅助密钥, 则向所述发送密钥请求的组成员发送所述请求的组密钥和 /或 辅助密钥; 否则, 通知所述发送密钥报文请求的组成员其所请求的组密钥 和 /或辅助密钥不存在。
- 8[8] 8、 根据权利要求 7所述的方法, 其特征在于, 所述的对所述发送密钥请求 的组成员进行身份验证之前还包括: 所述邻居组成员接收到所述密钥请求后, 对发送所述密钥请求的组成员进 行防攻击检査, 如果该防攻击检査失败, 则停止处理所述密钥请求; 否则 , 对所述发送密钥请求的组成员进行身份验证。
- 9[9] 9、 根据权利要求 4或 7所述的方法, 其特征在于, 所述的方法还包括: 当所述邻居组成员发现所述组成员请求的密钥报文或密钥不是最新的密钥 报文或密钥吋, 所述邻居组成员向所述组成员发送相应的通知消息; 或直 接向所述组成员发送最新的密钥报文或密钥。
- 10[10] 10、 一种密钥共享系统, 其特征在于, 包括: 请求者组成员, 用于向与其具有邻居关系的响应者组成员发送密钥信息请 求; 响应者组成员, 用于在接收到所述请求者组成员发送的密钥信息请求后, 向所述请求者组成员发送所述请求的密钥信息。
- 11[11] 11、 根据权利要求 10所述的系统, 其特征在于, 所述响应者组成员具体包 括: 密钥报文缓存模块, 用于将接收到的密钥服务器下发的密钥报文进行缓存 身份验证模块, 用于在接收到请求者组成员发送的密钥报文请求后, 对该 请求者组成员进行身份验证; 当身份验证失败吋, 停止处理所述密钥报文 请求; 密钥报文发送模块, 用于在对所述请求者组成员进行身份验证通过后, 从 密钥报文缓存模块中获取所述请求者组成员所请求的密钥报文, 并发送给 所述请求者组成员。
- 12[12] 12、 根据权利要求 11所述的系统, 其特征在于, 所述响应者组成员还包括 防攻击检査模块, 用于在接收到请求者组成员发送的密钥报文请求后, 对 该请求者组成员进行防攻击检査; 当防攻击检査失败吋, 停止处理所述密 钥报文请求。
- 13[13] 13、 根据权利要求 10所述的系统, 其特征在于, 所述响应者组成员具体包 括: 密钥缓存模块, 用于将接收到的密钥服务器下发的组密钥和 /或辅助密钥信 息进行缓存; 身份验证和权限检査模块, 用于根据接收到的密钥请求中携带的身份证明 信息, 对所述请求者组成员进行身份验证, 当身份验证失败吋停止处理所 述密钥请求; 根据接收到的密钥请求中携带的密钥拥有权限信息, 对所述 请求者组成员进行权限检査, 当权限检査失败吋停止处理所述密钥请求; 密钥发送模块, 用于在对所述请求者组成员进行身份验证和权限检査通过 后, 从密钥缓存模块中获取所述请求者组成员所请求的组密钥和 /或辅助密 钥, 并发送给所述请求者组成员。
- 14[14] 14、 根据权利要求 13所述的系统, 其特征在于, 所述响应者组成员还包括 防攻击检査模块, 用于在接收到请求者组成员发送的密钥请求后, 对该请 求组成员进行防攻击检査; 当防攻击检査失败吋, 停止处理所述密钥请求
Independent claims14
109 paragraphs, as filed
0001Key sharing method and system
0002[1] Technical field
0003[2] The present invention relates to the field of network communications, and in particular, to a key sharing method and system.
0004[3] Background Art
0005[4] Multi-party communication refers to a communication scenario in which two or more members participate. A scenario in which only two members participate is a special case of multi-party communication. Multi-party communication scenarios typically have multiple data recipients, one or more data senders. In multi-party communication, unicast technology or multicast technology can be used to send messages. Multi-cast technology is easier to implement multi-party communication than unicast technology.
0006[5] Common multi-party communication scenarios include remote multi-party conferencing, IP telephony, IPTV, online online gaming, and grid computing. Multi-party communication security refers to providing access control (authorization, authentication) to multi-party communication participants, providing security services such as encryption, integrity protection, replay protection, source authentication and group authentication for communication content, preventing non-group members from eavesdropping and tampering with communication. Content, or interfere with the normal conduct of the communication process, and prevent security threats from within members.
0007[6] The security requirements for multi-party communication mainly include:
0008[7] 1. Authorization and certification. Only those who are allowed and able to prove their identity can join the multi-party communication group and send and receive data to make the multicast group controllable.
0009[8] 2. Confidentiality. Only the node with the decryption key can interpret the contents of the group communication message.
0010[9] 3. Group member certification. A non-group member cannot generate valid authentication information, and thus cannot impersonate a group member to send a multicast message.
0011[10] 4. Source certification (anti-repudiation). A group member cannot generate authentication information for other group members, and thus cannot impersonate other group members to send multicast messages. On the other hand, group members cannot deny the information they send.
0012[11] 5. Anonymity. The mechanism for providing anonymous comments to group members, that is, the receiver cannot infer the identity of the sender from the received multicast message.
0013[12] 6. Integrity. Provides a means of verifying that the received multicast message has been tampered with.
0014[13] 7, anti-replay. Provides a replay detection mechanism to implement anti-replay attacks.
0015[14] In order to ensure the security of multi-party communication, multi-party communication messages are usually transmitted encrypted. Multi-party shared keys for encryption and decryption are known only to group members, which ensures that encrypted messages can only be read by group members. Group member authentication can also be implemented using this key, because only group members who have a key can correctly generate encrypted multicast messages.
0016[15] The key to solving the multi-party communication security problem by using the above-mentioned multi-party shared key is the generation and distribution of keys.
0017This generation and distribution must be exclusive, that is, non-group members cannot obtain keys for generation and distribution. Source authentication, integrity, and anonymous services often also take advantage of the exclusive sharing of information between two or more parties. In multi-party communication, how to implement the exclusive sharing of keys is the research scope of group key management. The group key is a key shared by all group members, which is used for security operations such as encryption and decryption of multicast messages. Group key management focuses on how to generate, publish, and update group keys for group members, and to address the resulting scalability, robustness, and reliability issues.
0018[16] To prevent key leakage, the group key must be encrypted for transmission. The current standard method is to use KEK (Key Encryption Keys) and TPK (Traffic Protection).
0019Keys, encryption group key) to ensure the confidentiality of the group key.
0020[17] KEK is shared between the key server and the group members. For different group members, the key servers are respectively set with different KEKs to implement the pre/post encryption requirements in the group key update. In the simple group key management scheme, the key server and each group member share a KEK. In the initial distribution and update process of the group key, the group key is sequentially encrypted with the KEK of each current group member, and then sent. Give each other. This scheme is simple to implement, but after the key is updated, the number of encryptions and transmissions that the key server needs to perform is directly proportional to the group member size, so the method is less scalable and rarely used in practice.
0021[18] At present, more advanced group key management schemes generally use a tree structure to organize KEK and use IP multicast to send group key messages, thereby reducing the encryption and key server requirements. The number of times sent for better scalability. LKH (Logical Key
0022Hierarchy, logical key hierarchy tree) is a relatively mature and standard tree-based group key management scheme in the industry. The schematic diagram of the LKH group key management scheme is shown in Figure 1.
0023[19] In the LKH group key management scheme shown in Figure 1, the root node (K1-8) corresponds to the group key, and other nodes
0024(Trunk node and leaf node) Corresponding to the auxiliary key, there is a one-to-one correspondence between the leaf node and the group members (ul~u9). Each user has all the keys from the leaf node to the root node path, and the group key is shared by all group members. As shown in Figure 1, the keys owned by the group member u9 before joining ul are kl, kl23, and kl-8, and the keys owned by u4 are k4, k456, and kl-8.
0025[20] In the LKH group key management scheme shown in FIG. 1, when a new group member joins or an existing group member leaves, the key server needs to update a key that all group members will know or already know.
0026[21] For example, when u9 joins 吋, the key server updates the keys k78 and kl-8, and then ul~u to other group members.
00278 Encryption sends the updated key. The specific sending process is: encrypting kl-9 with kl-8, and sending it to the user ul to u
00288; Encrypt k789 with k78, send it to users u7 and u8; then encrypt kl-9 and k789 with k9 and send to user u9.
0029[22] When u9 leaves, the key server updates k789 and kl-9, and then sends the updated key to the group members ul~u8. The specific sending process is as follows: k78 is used to encrypt k789, k7 is encrypted k78, and sent to the user. U7; Encrypt kl-8 with k 123, send it to ul~u3; encrypt kl-8 with k456, and send it to u4~u6.
0030[23] In the above LKH group key management scheme, the number of encryptions of the key server update group key 为 is 0 (log N), where N is the number of group members. In terms of message transmission, LKH uses IP multicast to send key update messages by default, and recommends using group-oriented sending mode, that is, all encrypted key information is encapsulated in one message, and multicast is used. The way to send to all group members, so that the number of times the key update is sent can be kept constant.
0031[24] In addition to the LKH group key management scheme described above, other tree-based group key management schemes include OFT, LKH++, and the like.
0032[25] In the LKH group key management scheme described above, after the key server sends a key message to the group member, the key server must ensure the reliability of the key message and prevent the legitimate group member from receiving the group key report. The group key and/or the secondary key cannot be updated, and the group communication cannot be continued. Factors affecting the reliable transmission of key messages include: network failure, packet loss caused by network congestion, failure of group member nodes, and short-lived offline of group member nodes. At present, there are mainly the following methods for ensuring the reliability of key message distribution.
0033[26] The first method for guaranteeing the reliability of key message distribution in the prior art is: a method of repeatedly transmitting a key message. In this method, after the key server sends a key message to the group member, the key server repeatedly transmits each key message multiple times. The member of the group only needs to process the first received key packet, and discards the repeatedly received packet. This method is applicable to both unicast and multicast key distribution methods. It is simple to implement, can improve the reliability of key message update to a certain extent, and reduce the probability of key synchronization between group members. A group communication scenario that is performed locally.
0034[27] In the process of implementing the present invention, the inventors have found that the first method of the above prior art to ensure the reliability of key message distribution has the following disadvantages:
0035[28] 1. The reliability problem of group key distribution cannot be fundamentally solved. In the case of congestion on the network, it is likely that all the repeatedly sent packets are discarded. The group members still need to obtain group key packets through other methods.
0036[29] 2. Increased bandwidth consumption. Repeated transmission of key messages wastes network bandwidth and is not suitable for bandwidth-constrained scenarios.
0037[30] The second method for guaranteeing the reliability of key message distribution in the prior art is: a group key distribution method based on reliable unicast/multicast. The method introduces a super-retransmission and reception confirmation mechanism between the key server and the group member, and fundamentally implements reliable group key message transmission. For LKH, the scheme of message distribution using IP multicast can use reliable multicast technology.
0038In the process of implementing the present invention, the inventors have found that the second method of the above prior art method for guaranteeing the reliability of key message distribution has the following disadvantages:
0039[32] 1. The positive acknowledgment mechanism used by this method has the phenomenon of confirming the explosion of the message. If an ACK (Answer) is used instead of a NAK (Negative Answer) acknowledgment mechanism, each group member that receives a group key message will send an acknowledgment message. Because the group member receives the group key message with the same engraving, if the group member size is large, a large number of group members send the confirmation message to the same direction almost in the same direction, which will cause the network packet volume to expand rapidly in a short period of time. Deteriorating the congestion of the network, the key server may also be unable to receive all the acknowledgment messages because the network processing burden is too heavy.
0040[33] 2. Increased the burden on the key server. In addition to confirming that the burst of packets will cause the key server to be overburdened, the key server needs to maintain a super-transfer buffer for each group member, which will increase the burden on the key server, thereby limiting each The size of the group members that the server can serve cannot be too large.
0041[34] The third method in the prior art for guaranteeing the reliability of key message distribution is: FEC (Forward Error)
0042Correction, forward error correction) technology group key distribution method. The method adds a certain proportion of redundant information to the key message. For example, the information of the previous message is repeatedly added in subsequent messages, so that the receiver does not have to receive all the messages, and only needs to receive a certain amount. The message can be extracted to complete the message information. This solution is currently a relatively good and relatively versatile solution, and can be applied in other scenarios such as streaming media.
0043[35] In the process of implementing the present invention, the inventors have found that the third method of the above-mentioned prior art guarantees the reliability of key message distribution has the following disadvantages: the number of transmissions is increased, thereby increasing the key server. The burden of sending. Because redundant information is added to the message, the message transmission burden of the key server is correspondingly increased.
0044[36] Summary of the invention
0045[37] An object of the present invention is to provide a key distribution method and system, whereby the reliability of key distribution can be improved.
0046[38] The object of the present invention is achieved by the following technical solutions:
0047[39] A method of key sharing, comprising:
0048[40] The group member sends a key information request to the neighbor group member;
0049[41] After receiving the key information request, the neighbor group member sends the requested steel message to the group member.
0050[42] A key sharing system, comprising:
0051[43] a requester group member for transmitting a key information request to a responder group member having a neighbor relationship with it;
0052[44] a responder group member, configured to send the requested key information to the requester group member after receiving the key information request sent by the requester group member.
0053[45] It can be seen from the technical solution provided by the present invention that the present invention can improve the group secret by sharing a group key message or a shared group key and/or a secondary key between group members having a neighbor relationship. The reliability and availability of key and/or auxiliary key distribution avoids the server performance and network bandwidth bottlenecks in which all group members obtain keys from the key server, and improves the resources of the entire group system (such as network bandwidth, processing). The utilization of capacity) improves the security of multi-party communication data of the entire group system.
0054[46] BRIEF DESCRIPTION OF THE DRAWINGS
0055[47] Figure 1 is a schematic diagram of a key management scheme for the LKH group;
00562 is a specific processing flowchart of an embodiment of a key distribution method based on key packet sharing according to the present invention; [49] FIG. 3 is a key distribution method based on key sharing according to the present invention; [00] FIG. 4 is a schematic diagram of a specific structure of an embodiment of a key distribution system based on key packet sharing according to the present invention;
0057FIG. 5 is a schematic structural diagram of an embodiment of a key distribution based key distribution system according to the present invention.
0058[52] Specific implementation
0059[53] The present invention provides a key sharing method and system. The present invention shares a group key message or a shared group key and/or a secondary key among group members having a neighbor relationship, and some abnormal group members are The normal group member obtains the group key and/or the secondary key to avoid being out of sync with the group key and/or the secondary key of other normal group members.
0060The method of the present invention includes two implementations based on key message sharing and key sharing.
0061[55] The key sharing-based implementation scheme is mainly as follows: The group member receiving the request verifies the identity of the group member that initiated the request, and checks the key ownership rights of the group member that initiated the request. Then, the group member receiving the request sends the group key and/or the auxiliary key directly to the group member initiating the request by means of encrypted transmission.
0062[56] The implementation scheme based on key packet sharing is mainly as follows: The group member receiving the request cannot verify the identity of the group member that initiated the request, and the group member receiving the request can only forward the secret from the key server to the group member that initiated the request. Key message.
0063The present invention is described in detail below with reference to the accompanying drawings. The specific processing flow of the embodiment of the key sharing method based on the key packet sharing of the present invention is shown in FIG. 2 . Including the following steps:
0064[58] Step 2-1. Establish neighbor relationships between group members.
0065[59] First, neighbor relationships need to be established between group members, and group members who have established neighbor relationships can communicate with each other. The present invention does not require that all group members establish a two-way neighbor relationship between each other, allowing the neighbor relationship to exist only between some group members.
0066[60] Establishing neighbor relationships between group members can be established through a key server or by other means.
0067[61] Step 2-2. The group member sends a key message request to the neighbor group member.
0068[62] After a neighbor relationship is established between members of a group, when a group member does not receive the group key message sent by the key server due to network failure, packet loss, short offline, etc., and discovers his own After the group key and/or the auxiliary key are not synchronized with other group members, the group member sends a key message request to the neighbor group member, requesting the neighbor group member to send the corresponding group key and/or the auxiliary key to the user. Key message.
0069[63] The above group members can send key message requests to multiple neighbor group members at the same time, or send key message requests to multiple neighbor group members in turn.
0070[64] Step 2-3: The neighbor group members that have received the key packet request perform attack defense check and identity verification.
0071[65] After receiving the above-mentioned key message request, the neighboring group members firstly prevent the malicious group members from using the request message to initiate DOS attacks on other group members, and firstly perform anti-DOS attack on the group members that request the key message request. check. When the anti-DOS attack check fails, the key message request is stopped.
0072[66] After the anti-DOS attack check succeeds, the group member that sends the key message request is authenticated; if the identity verification fails, the key message request is stopped; otherwise, step 2- 4.
0073[67] Step 2-4: The neighbor group member that receives the key message request sends a key message to the group member that sends the key message request.
0074[68] After the DOS attack check is successful, the neighbor group member that receives the key message request queries whether the key message requested by the group member that sends the key message request is stored in the local cache.
0075[69] If there is a key message requested by the group member that sends the key message request in the local cache, the key message is sent to the group member that sends the key message request. After receiving the key message, the group member that issued the key message request decrypts the group key and/or the auxiliary key, and performs corresponding processing.
0076[70] If there is no key message requested by the group member that sends the key message request in the local cache, the group member that requests the key message request is notified that the requested key message does not exist.
0077[71] The specific processing flow of the embodiment of the key sharing based key sharing method of the present invention is shown in FIG. 3. Including the following steps:
0078[72] Step 3-1. Establish a neighbor relationship between the group members.
0079[73] First, neighbor relationships need to be established between group members, and group members who have established neighbor relationships can communicate with each other. The invention does not require that all group members establish a two-way neighbor relationship between each other, allowing the neighbor relationship to exist only between some group members.
0080[74] Establishing neighbor relationships between group members can be established through a key server or by other means.
0081[75] Step 3-2. The group member sends a key request to the neighbor group member.
0082[76] After a neighbor relationship is established between members of a group, when a group member does not receive the group key message sent by the key server due to network failure, packet loss, short offline, etc., and discovers his own After the group key and/or the auxiliary key are out of sync with other group members, send a key request to other group members who have a neighbor relationship with themselves, and request the other group members to send the corresponding group key and/or auxiliary secret to themselves. key. And carrying the identity certificate and the key possession authority information in the above key request.
0083[77] The above group members can send key requests to other group members who have neighbor relationships with themselves, or send key requests to other group members who have neighbor relationships with them in turn.
0084[78] Step 3-3: The neighbor group member that received the key request performs an anti-attack check.
0085[79] After receiving the above key request, the other group members first perform an anti-DOS attack check to prevent malicious group members from using the request message to initiate DOS attacks on other group members. If the anti-DOS attack check fails, stop processing the key request; otherwise, perform steps 3-4.
0086[80] Step 3-4: The neighbor group members who have received the key request perform authentication and permission check.
0087[81] After the DOS attack check is successful, the neighbor group member authenticates the group member that sends the key request according to the identity certificate information carried in the received key request, and stops processing if the identity verification fails. If the authentication succeeds, it continues to check whether the group member sending the key request has the key access right according to the key possession authority information carried in the received key request.
0088[82] If the above key access permission check fails, the neighbor group member that received the key request stops processing the received key request, and informs the group member who sent the key request that the authority is insufficient; if the above key access If the permission check is successful, go to steps 3-5.
0089[83] Step 3-5: The neighbor group member that receives the key request sends a key to the group member that sends the key request.
0090[84] The neighbor group member that receives the key request queries whether the key and/or the auxiliary key requested by the group member transmitting the key request are saved in the local cache.
0091[85] If there is a key and/or a secondary key requested by the group member transmitting the key request in the local cache, then the key and/or the auxiliary secret are sent to the group member transmitting the key request in an encrypted manner. key. After receiving the key and/or the secondary key, the group member that issued the key request performs corresponding processing.
0092[86] If the key and/or the secondary key requested by the group member transmitting the key request does not exist in the local cache, the group member who sent the key request is notified that the requested key and/or the secondary key are not presence.
0093[87] In the above process of the embodiment based on key sharing or key message sharing, in order to prevent the group key from being out of synchronization between group members, and security considerations, the neighbor group member request should be restricted. The eliminated group key and/or the secondary key or the corresponding key message. Therefore, the administrator needs to configure the corresponding policy. If the member of the group finds that the neighbor group member has requested the group key and/or the auxiliary key or the corresponding group key packet that has been eliminated, the member will be sent to the other party regardless of whether the group key is sent. The key and/or the auxiliary key or the corresponding group key message shall notify the neighbor group member that the group key and/or the auxiliary key or the corresponding group key message have been eliminated, to inform the other party that it should go further. Request the latest group key and/or auxiliary key or corresponding group key message. In order to ensure security, the above notification information should be secured by some kind of verification mechanism.
0094The method of the present invention can be used in combination with the existing method for ensuring the reliability of key message distribution, thereby jointly improving the reliability of key distribution.
0095[89] The specific structure of the embodiment of the key distribution system based on the key message sharing of the present invention is as shown in FIG.
0096. Includes the following modules:
0097[90] Requester group member: includes a key message request sending module, configured to: after the requester group member discovers that its group key and/or the auxiliary key are out of sync with other group members, to one or more of them The responder group member of the neighbor relationship sends a key message request, and requests the responder group member to send a key message carrying the group key and/or the auxiliary key.
0098[91] Responder group member: After receiving the key message request sent by the requester group member, after performing the anti-attack check and identity verification on the member of the requester group, sending the member to the requester group member The requested key message. The method includes: a key message caching module, an anti-attack checking module, an authentication module, and a key message sending module.
0099[92] The key message caching module is configured to cache the key message delivered by the received key server.
0100[93] The anti-attack check module: After receiving the key message sent by the group member, the anti-DOS attack is performed on the member of the group to prevent the malicious group member from using the request message to initiate a DOS attack. an examination. When the anti-DOS attack check fails, the key message request is stopped.
0101[94] wherein, the identity verification module is configured to: after receiving the key message request sent by the requester group member, perform identity verification on the requester group member; when the identity verification fails, stop processing the key report Request for text. [95] The key message sending module is configured to: after performing the anti-DOS attack check and the identity verification on the group member that sends the key message request, acquiring the requester from the key message cache module The key message requested by the group member and sent to the requester group member.
0102[96] A specific structure of an embodiment of the key sharing based key distribution system of the present invention is shown in FIG. 5. Includes the following modules:
0103[97] Requester group member: includes a key request sending module, configured to have one or more neighbor relationships with the requester group member after discovering that the group key and/or the auxiliary key are out of sync with other group members The responder group member sends a key request carrying the identity certificate and the key possession authority information, requesting the responder group member to send the group key and/or the secondary key thereto.
0104[98] Responder group member: Used to perform an anti-attack check, authentication, and permission check on the requester group member after receiving the key request sent by the requester group member, to the requester group member Send the key it requested. Including: key cache module, anti-attack check module, authentication and permission check module and key sending module.
0105[99] The key cache module is configured to cache the group key and/or the auxiliary key information delivered by the received key server.
0106[100] The anti-attack check module is configured to: after receiving the key request sent by the requester group member, in order to prevent the malicious group member from using the request message to initiate a DOS attack, the member of the requester group is prevented. DO S attack check. When the anti-DOS attack check fails, the key request is stopped.
0107[101] The authentication and permission checking module is configured to: perform identity verification on the requester group member according to the identity verification information carried in the received key request, and stop processing the received confidentiality if the identity verification fails. Key request; if the authentication succeeds, it continues to check whether the requester group member has the key access right according to the key possession authority information carried in the received key request. If the permission check fails, the processing of the received key request is stopped, and the requester group member is notified that the authority is insufficient.
0108[102] The key sending module is configured to: after the anti-attack check, the identity verification, and the permission check are performed on the member of the requester group that sends the key request, obtain the requester from the key cache module. The group key and/or the secondary key requested by the group member and sent to the requester group member.
0109The above description is only a preferred embodiment of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can easily think of within the technical scope disclosed by the present invention. Changes or substitutions are intended to be included within the scope of the invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.
3 sheets
Sheet 1 Sheet 2 Sheet 3
Every citation, both ways
| Document | Relation | Office | Category | Cited during |
|---|---|---|---|---|
| CN1444362A | Cites | China | A | International search |
| CN1553600A | Cites | China | Y | International search |
| CN1599312A | Cites | China | A | International search |
| US2005050004A1 | Cites | United States of America | Y | International search |
| WO2005074185A1 | Cites | World Intellectual Property Organization (WIPO) | A | International search |
| US6941457B1 | Cites | United States of America | A | International search |
5 members in 4 offices
Priority claims1
| Document | Office | Kind | Date |
|---|---|---|---|
| 200610152283 | China | A |
Members5
| Document | Office | Kind | |
|---|---|---|---|
| CN101155027A | China | A | |
| WO2008043289A1This record | World Intellectual Property Organization (WIPO) | A1 | |
| US2009190764A1 | United States of America | A1 | |
| EP2120390A1 | European Patent Office (EPO) | A1 | |
| CN101155027B | China | B |
3 legal events, as 2 offices reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | Office | |
|---|---|---|---|
| Wipo information: entry into national phaseWWE | WWE | WO | |
| Non-entry into the national phaseNENP | NENP | DE | |
| Ep: the epo has been informed by wipo that ep was designated in this application121 | 121 | WO |
Numbers
- Publication
- 2008/043289
- Application
- 70719
Titles2
- English
- A KEY SHARING METHOD AND CORRESPONDING SYSTEM
- French
- PROCÉDÉ DE PARTAGE DE CLÉ ET SYSTÈME CORRESPONDANT
Classification
- CPC, 2
- H04L9/0833
- H04L9/3271
- IPC, 1
- H04L9 08
Designated states4
- Regional, 4
- Zimbabwe
- Turkmenistan
- Türkiye
- Togo