Key management method for secure communication

Abstract

The application relates to a key management method for secure communication. Based on the application, a user negotiation communication key can be stored in a server in a shadow negotiation communication key state by using a user communication key container on the client side and the server side, so that the user negotiation communication key can be safely shared between different clients of the same user under the premise of considering key confidentiality, thereby avoiding the re-negotiation of the user negotiation communication key caused by the switching of the clients of the same user.

Description

Technical Field

[0001] This application relates to the field of information security, and in particular to a key management method for secure communication, a client, and a data communication system. Background Technology

[0002] In data communication systems, to ensure data security, end-to-end communication between users typically uses a user-negotiated communication key agreed upon by both parties. That is, the sending party uses the user-negotiated communication key to encrypt the plaintext data to be sent, obtaining ciphertext information, which is then sent to the other party. The receiving party can then decrypt the ciphertext information using the same user-negotiated communication key, thus recovering the plaintext information.

[0003] Furthermore, to ensure the confidentiality of the user-negotiated communication key, it is typically stored locally only on the client machine used by both users during the negotiation; that is, the user-negotiated communication key is bound to the client machine. Moreover, if either user changes their client machine—that is, if their user account is logged in on different clients—then both users need to renegotiate the user-negotiated communication key.

[0004] With the continuous development of science and technology, more and more users have multiple clients and frequently switch between different clients to conduct data communication with other users. In this case, the method of user-negotiated communication key and client-bound key confidentiality will cause users to renegotiate the user-negotiated communication key when switching clients. Therefore, the method of user-negotiated communication key and client-bound key confidentiality is not suitable for users who frequently switch clients to conduct data communication.

[0005] In other words, how to avoid the renegotiation of communication keys caused by switching clients of the same user while ensuring key confidentiality has become a technical problem that needs to be solved in the existing technology. Summary of the Invention

[0006] In view of this, a key management method, a client, and a data communication system for secure communication can avoid the renegotiation of communication keys caused by switching clients of the same user, while ensuring key confidentiality.

[0007] In one embodiment of this application, a key management method for secure communication is provided. The key management method is applied to any client currently logged into a target user account and configured with a first user communication key container created for the target user account. The first user communication key container includes an account access key generated based on the target user account's private identifier. The key management method includes:

[0008] Obtain the user negotiation communication key used for end-to-end communication between the target user account and the peer user account, as well as the peer user account identifier of the peer user account;

[0009] A shadow negotiation communication key is generated using the user negotiation communication key, the peer user account identifier, and the account access key;

[0010] The shadow negotiation communication key is associated with the peer user account identifier and stored in a second user communication key container created for the target user account on the server, so that any client can log in to the target user account, configure the first user communication key container, and need to conduct end-to-end communication with the peer user account:

[0011] Using the peer user account identifier, request the server to obtain the shadow negotiation communication key stored in the second user communication key container;

[0012] The user negotiation communication key is reconstructed using the peer user account identifier, the account access key, and the shadow negotiation communication key successfully obtained from the server.

[0013] In some examples, optionally, generating a shadow negotiation communication key using the user negotiation communication key, the peer user account identifier, and the account access key includes: generating a user negotiation access key based on the peer user account identifier and the account access key, and generating the shadow negotiation communication key based on the user negotiation access key and the user negotiation communication key; the restoring the user negotiation communication key using the peer user account identifier, the account access key, and the shadow negotiation communication key includes: generating the user negotiation access key based on the peer user account identifier and the account access key, and restoring the user negotiation communication key based on the shadow negotiation communication key and the user negotiation access key.

[0014] In some examples, the key management method may optionally further include: storing the shadow negotiation communication key generated locally or obtained locally from the server into a first user communication key container configured locally; wherein the shadow negotiation communication key in the first user communication key container configured by any client and the second user communication key container of the server is subject to key update in response to renegotiation of the user negotiation communication key by the target user account and the peer user account, or is subject to key clearing in response to update of the user private identifier.

[0015] In some examples, optionally, the key update includes: in response to the renegotiation of the user negotiation communication key by the target user account and the peer user account, generating an updated shadow negotiation communication key using the peer user account identifier, the account access key, and the user negotiation communication key determined by the renegotiation of the target user account and the peer user account; replacing the existing shadow negotiation communication key in the first user communication key container configured locally with the updated shadow negotiation communication key; and sending the updated shadow negotiation communication key to the server, so as to cause the server to replace the shadow negotiation communication key stored in the second user communication key container associated with the peer user account identifier with the updated shadow negotiation communication key; wherein the server is configured to: in response to the successful update of the shadow negotiation communication key in the second user communication key container, initiate the update of the shadow negotiation communication key in the first user communication key container configured by other clients.

[0016] In some examples, optionally, the server is configured to: assign a corresponding key version number to the shadow negotiation communication key, wherein the key version number is updated in response to each key update, and the key version number is stored in association with the shadow negotiation communication key in the first user communication key container and the second user communication key container; in response to a successful key update of the shadow negotiation communication key in the second user communication key container and an associated update of the key version number, send a key update notification carrying the updated key version number to each client configured with the first user communication key container; the key update further includes: in response to the received key update notification indicating that the key version number represents a new version compared to the existing key version number in the first user communication key container configured locally, performing the key update on the shadow negotiation communication key in the first user communication key container configured locally.

[0017] Optionally, in some examples, the key management method further includes: generating the account access key based on the account access seed generated locally for the target user account and the user private identifier input locally; sending the account access seed to the server to cause the server to create a second user communication key container including the account access seed for the target user account, and allowing: any client logging into the target user account to initialize a container locally using the account access seed obtained from the server, and to create a first user communication key container containing the account access key for the target user account locally.

[0018] In some examples, the container initialization may optionally include: requesting the server to obtain the account access seed in the second user communication key container; generating the account access key using the user private identifier input locally and the account access seed obtained from the server, so as to create a first user communication key container containing the account access key on the local machine for the target user account.

[0019] Optionally, in some examples, the key management method further includes: regenerating the account access seed in response to an update of the user private identifier, and initiating a container update of the first user communication key container and the second user communication key container using the regenerated account access seed; wherein the shadow negotiation communication key in the first user communication key container configured by any client and the second user communication key container of the server is cleared in response to the container initialization re-executed after the creation of the first user communication key container.

[0020] In some examples, optionally, the container update includes: using the updated user private identifier of the target user account input locally and the account access seed regenerated locally, to regenerate the account access key for the target user account, so as to replace the existing account access key in the first user communication key container configured locally with the regenerated account access key; sending the regenerated account access seed to the server to cause the server to update the account access seed stored in the second user communication key container associated with the target user account identifier; wherein, the server is configured to: in response to the successful update of the account access seed in the second user communication key container, initiate the container initialization of the first user communication key container configured by other clients to be re-executed.

[0021] Optionally, in some examples, the key management method further includes: generating an account access code for the target user account based on the account access key; and sending the account access code to the server and storing it in the second user communication key container; the container initialization includes: requesting the server to obtain the account access seed and the account access code from the second user communication key container; and generating the account access key using the user private identifier input locally and the account access seed obtained from the server, so as to create a system on the local machine for the target user account containing the account access key and the system on the local machine generating based on the account access key. The first user communication key container of the account access code; the container update further includes: regenerating the account access code for the target user account using the updated account access key, so as to replace the existing account access code in the first user communication key container configured locally with the regenerated account access code; and sending the regenerated account access code to the server, so as to cause the server to update the account access code stored in the second user communication key container, and allow: any client logging into the target user account to use the account access seed obtained from the server to initialize the container locally before: using the account access seed obtained from the server to initialize the container locally. The consistency verification of the account access code on the local machine and the server is performed to detect whether the second user communication key container has become invalid due to the update of the user's private identification code. Furthermore, the initialization of the container on the local machine is enabled only if the second user communication key container is determined to be valid. Alternatively, when any client logging into the target user account obtains the shadow negotiation communication key from the server: the consistency verification of the account access code on the local machine and the server is used to detect whether the first user communication key container configured on the local machine has become invalid due to the update of the user's private identification code. Furthermore, the initialization of the shadow negotiation communication key obtained from the server is enabled only if the second user communication key container is determined to be valid. The first user communication key container configured on the machine is considered valid if it is valid; wherein, the first user communication key container configured in any client is destroyed in response to the failure of the consistency check, and the container update of the second user communication key container is allowed to be performed if the same account access code before the update is stored in the first user communication key container of the client initiating the container update and the second user communication key container of the server; the key management method further includes: storing the shadow negotiation communication key generated locally or obtained locally from the server into the first user communication key container configured locally;Specifically, the shadow negotiation communication key in the first user communication key container configured on any client and the second user communication key container on the server are subject to key updates in response to the renegotiation of the user negotiation communication key by the target user account and the peer user account; and the key update of the shadow negotiation communication key in the second user communication key container is permitted only if the same account access code is stored in the first user communication key container of the client initiating the key update and the second user communication key container of the server.

[0022] In some examples, the server is optionally configured to: assign container version numbers to the first user communication key container and the second user communication key container, and update the container version numbers in response to each container update of the first user communication key container and the second user communication key container, and send a container reinitialization notification carrying the updated container version number to each client configured with the first user communication key container; the container version numbers are stored in the first user communication key container and the second user communication key container such that: any client logged into the target user account, in response to the received container reinitialization notification indicating a new version of the container version number compared to the existing container version number in the first user communication key container configured locally, re-executes the container initialization for the first user communication key container configured locally.

[0023] In some examples, optionally, the first user communication key container configured on any client is destroyed in response to the target user account logging out of the client.

[0024] In some examples, the server is optionally configured to, in response to a container destruction request initiated by the management control platform for the target user account, perform a destruction operation on the second user communication key container, and send a container destruction notification for the target user account to each client configured with the first user communication key container, such that: any client, in response to the received container destruction notification, performs a destruction operation on the first user communication key container configured locally.

[0025] In another embodiment of this application, a key management method for secure communication is provided. The key management method is applied to an online client currently logged into a target user account. The online client is configured with a first user communication key container created for the target user account. The first user communication key container includes an account access key generated based on the target user account's private identifier. The key management method includes:

[0026] Obtain the peer user account identifier of the peer user account that is communicating end-to-end with the target user account;

[0027] Using the peer user account identifier, a request is made to the server to obtain a shadow negotiation communication key stored in the second user communication key container created for the target user account. The shadow negotiation communication key is generated by any client using the user negotiation communication key negotiated between the target user account and the peer user account, along with the peer user account identifier and the account access key.

[0028] The user negotiation communication key is reconstructed using the peer user account identifier, the account access key, and the shadow negotiation communication key successfully obtained from the server.

[0029] In another embodiment of this application, a client is provided, including a processor, a communication component, a human-computer interaction component, and a storage medium. The processor is used to execute the key management method as described in the foregoing embodiments, and the storage medium is used to store the first user communication key container.

[0030] In another embodiment of this application, a data communication system is provided, comprising:

[0031] The client described in the foregoing embodiments;

[0032] The server that communicates with the client; and

[0033] A storage device that is communicatively connected to the server, the storage device being used to store the second user communication key container.

[0034] In another embodiment of this application, a non-transitory computer-readable storage medium is provided that stores instructions which, when executed by a processor, cause the processor to perform the key management method as described in the foregoing embodiments.

[0035] Based on the above embodiments, any user possessing a target user account can have any client they own log into the target user account to be online. The currently logged-in online client can utilize a first user communication key container configured locally to convert the user negotiation communication key negotiated between the target user account and the peer user account into a shadow negotiation communication key, and store it in a second user communication key container created by the server for the target user account. Therefore, when the user logs into the target user account using any client they own, by configuring the first user communication key container for that client and obtaining the shadow negotiation communication key from the server, they can obtain the user negotiation communication key negotiated between the target user account and the peer user account. Thus, the embodiments of this application can utilize user communication key containers on both the client and server sides to replace the storage of the user negotiation communication key in the server as a shadow negotiation communication key. Therefore, while maintaining key confidentiality, it is possible to securely share the user negotiation communication key between different clients of the same user, avoiding the need for renegotiation of the user negotiation communication key when switching clients of the same user. Attached Figure Description

[0036] The following figures are for illustrative purposes only and do not limit the scope of this application:

[0037] Figure 1 This is a schematic diagram illustrating the configuration of a user communication key container on both the client and server sides in a key management method for secure communication, as shown in one embodiment of this application.

[0038] Figure 2 This is a schematic diagram illustrating a key management method for secure communication in one embodiment of this application, which securely shares user-negotiated communication keys between different clients of the same user.

[0039] Figure 3 An exemplary flowchart illustrating the creation of a user communication key container for a key management method for secure communication in one embodiment of this application;

[0040] Figure 4 This is an exemplary flowchart illustrating a key management method for secure communication in one embodiment of this application, which obtains a user communication key container through container initialization.

[0041] Figure 5 This is an exemplary flowchart illustrating a key management method for secure communication that initiates a container update in one embodiment of this application.

[0042] Figure 6 This is an exemplary flowchart illustrating a key management method for secure communication in response to container updates, as shown in one embodiment of this application.

[0043] Figure 7 This is an exemplary flowchart illustrating a key management method for secure communication in one embodiment of this application, in which a shadow negotiation communication key is stored in a user communication key container.

[0044] Figure 8 This is an exemplary flowchart illustrating a key management method for secure communication in one embodiment of the present application, in which a shadow negotiation communication key is retrieved from a user communication key container on the server side.

[0045] Figure 9 This is an exemplary flowchart illustrating a key update process for a key management method used for secure communication in one embodiment of this application.

[0046] Figure 10 This is an exemplary flowchart illustrating a key management method for secure communication in response to a key update, as shown in one embodiment of this application.

[0047] Figure 11 This is an extended schematic diagram of a key management method for secure communication in one embodiment of this application, which configures user communication key containers on the client and server sides.

[0048] Figure 12 This is an extended schematic diagram of a key management method for secure communication in one embodiment of the present application, illustrating the secure sharing of user-negotiated communication keys between different clients of the same user.

[0049] Figure 13 This is an exemplary structural diagram of a client in an embodiment of this application. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided with reference to the accompanying drawings and embodiments.

[0051] In the embodiments of this application, a User Communication Key Container (UCKC) can be configured on both the client and the server. Using the UCKC configured on both the client and server, the user-negotiated communication key is stored on the server as a shadow negotiation communication key, thereby enabling secure sharing of the user-negotiated communication key between different clients of the same user while maintaining key confidentiality. This avoids the need for renegotiation of the user-negotiated communication key when switching clients of the same user. Here, "the same user" refers to the same target user account with the same account identifier (User ID).

[0052] Before detailing the technical solutions of the embodiments of this application, the parameters and corresponding reference numerals involved in the embodiments of this application are briefly described as follows:

[0053] 810: The first UCKC is configured on the client side. The first UCKC can be created by any client logged into the target user account (i.e., any client belonging to the same user as the target user account). However, the first UCKC is not uniquely bound to the client that created it, but rather to the target user account. For example, the binding method between the first UCKC and the target user account can be that the first UCKC stores the account identifier of the target user account, or that there is a corresponding relationship between the first UCKC and the account identifier of the target user account. Therefore, any client logged into the target user account (i.e., any client belonging to the same user as the target user account) is allowed to configure the first UCKC. Furthermore, the first UCKC configured by any client will be automatically destroyed after the target user logs out of that client. That is, the first UCKC configured by any client logged into the target user account can be destroyed in response to the target user account logging out of that client.

[0054] 820: Second UCKC, configured on the server, wherein the second UCKC is also bound to the target user account. For example, the binding method of the second UCKC to the target user account can be that the second UCKC stores the account identifier of the target user account, or that the second UCKC and the account identifier of the target user account have a corresponding relationship. It can assist any client that logs into the target user account (i.e., any client belonging to the same user as the target user account) in creating or initializing the first UCKC. Any client mentioned here includes the client that creates the first UCKC, because the client that creates the first UCKC may lose or destroy the first UCKC created on its own machine for various reasons. Furthermore, the second UCKC configured on the server will not be destroyed by the client, but it can be destroyed by the management and control platform. That is, the server can be configured to respond to a container destruction request initiated by the management and control platform for a target user account (e.g., a container destruction request initiated due to an administrator resetting the target user account's private identifier), and perform a destruction operation on the second UCKC of the target user account. Moreover, the destruction of the second UCKC of the target user account will also trigger the server to destroy the first UCKC of the target user account on the client side. That is, the server can also be configured to send a container destruction notification for the target user account to each client that has the first UCKC configured for the target user account, so that: any client logged into the target user account responds to the received container destruction notification and performs a container destruction operation on the first UCKC configured on its own machine.

[0055] 90: Account Private Identifier, which uniquely identifies the target user account. For example, the account private identifier can be a PIN (Personal Identification Number). This private identifier, being confidential information, is not stored in the first UCKC or the second UCKC. When the target user account's account private identifier is updated by a client configured with the first UCKC, this update triggers an update to the containers of the first UCKC configured on that client and the second UCKC on the server. Furthermore, the server also triggers the destruction of the containers of the first UCKC configured on other online clients besides that client. Additionally, when the target user account's account private identifier is updated by a client configured with the first UCKC, the target user account's login status on other clients will be automatically set to logged-out. That is, the target user's login can be voluntary or forced due to an update of the account private identifier on a non-local machine.

[0056] 91: Access Seed, which can be generated by any client. For example, the access seed can be generated randomly by any client. The access seed can be regenerated after the account private identifier is updated. The access seed generated for any user account needs to be stored in the second UCKC bound to that user account. That is, the access seed stored in the second UCKC bound to the target user account is the access seed of the target user account.

[0057] 92: The account access key can be generated by any client based on the account's private identifier. Therefore, the account access key can be updated after the account's private identifier is updated. The account access key can be used to implement encryption and decryption related to user negotiation communication keys. The account access key generated for any user account needs to be stored in the first UCKC bound to that user account. That is, the account access key stored in the first UCKC bound to the target user account is the account access key of that target user account. Preferably, the account access key can be generated by any client based on the account's private identifier and the account access seed. For example, the account access key can be obtained by extracting information from the account's private identifier and the account access seed. The extraction of information from the account's private identifier and the account access seed can use information extraction algorithms such as hashing. Taking the account's private identifier as a PIN and the extraction of information from the account's private identifier and the account access seed using a hash algorithm as an example, the process of obtaining the account access key through information extraction can be expressed as: Access Key = Hash(PIN + Access Seed).

[0058] 93: Access Code, which can be generated by any client based on the account access key. For example, the access code can be obtained by extracting information from the account access key (such as using an information extraction algorithm like a hash algorithm), i.e., Access Code = Hash(Access Key). The access code is related to the account private identifier, i.e., the access code can be updated after the account private identifier is updated. However, the correlation between the access code and the account private identifier is weaker than the correlation between the account access key and the account private identifier. Therefore, the access code may not be involved in the encryption and decryption related to the user's negotiated communication key. Instead, it is mainly used by any client to determine whether the first UCKC configured on its own machine has become invalid due to the update of the account private identifier. The access code can be an optional parameter in the first UCKC and the second UCKC. Furthermore, the access code generated for any user account can be stored in the first UCKC and the second UCKC bound to that user account. That is, the access code stored in the first UCKC and the second UCKC bound to the target user account is the account access key of that target user account.

[0059] 94: Container Version, used to identify the version of the first UCKC and the second UCKC that is triggered by the update of the user's private identifier after their initial creation. It is created by the server and stored in the first UCKC and the second UCKC. The first creation of the first UCKC on the client precedes the first creation of the second UCKC on the server. That is, the first creation of the first UCKC refers to the creation of the first UCKC that occurs on any client before the first creation of the second UCKC.

[0060] 95: Peer User ID. The "Peer" in the peer user account identifier identifies the relative location relative to the target user account. The peer user ID uniquely identifies the peer user account (Peer User) that conducts end-to-end communication with the target user account. Furthermore, the peer user ID can be obtained from the server. For example, the server can maintain a list of peer user accounts for the target user account, which may include the peer user ID obtained by the server from clients logged into the peer user account. To distinguish the target user account's ID from the peer user account ID, the target user account's ID is referred to as the target user account ID in this document.

[0061] 96: The Co-User Message Key (Co-User Message Key) can be negotiated and determined by the client logging into the target user account and the client logging into the peer user account through a key exchange algorithm such as the Diffie-Hellman algorithm. "Negotiation by the client logging into the target user account and the client logging into the peer user account" will be simplified to "negotiation between the target user account and the peer user account" in the following text. The embodiments of this application do not attempt to impose unnecessary limitations on the negotiation method of the Co-User Message Key. The Co-User Message Key, which is private information, is not stored in the first UCKC and is not stored in the second UCKC.

[0062] 97: Co-User Access Key, which is an intermediate auxiliary parameter in the encryption and decryption process related to the user negotiation communication key using the account access key. For example, the Co-User Access Key can be obtained by extracting information about the peer user's account identifier and account access key (e.g., using an information extraction algorithm such as a Hash algorithm), that is, Co-User Access Key = Hash(Peer User ID + Access Key). Furthermore, the Co-User Access Key is not stored in the first UCKC and is not stored in the second UCKC.

[0063] 98: Co-User Shadow Message Key. This is a shadow negotiation communication key generated based on the user negotiation communication key negotiated between the target user account and the peer user account. It can be stored in association with the peer user account identifier in the first UCKC and the second UCKC bound to the target user account. Similarly, the shadow negotiation communication key will also be stored in the first UCKC and the second UCKC bound to the peer user account. Furthermore, as the peer of the peer user account, the target user account identifier will be stored in association with the shadow negotiation communication key in the first UCKC and the second UCKC bound to the peer user account. The shadow negotiation communication key can be obtained by encrypting the user negotiation communication key with the account access key, and the user negotiation communication key can be obtained by decrypting the shadow negotiation communication key with the account access key. For example, the above encryption and decryption can use any symmetric encryption and decryption algorithm such as Data Encryption Standard (DES), Advanced Encryption Standard (AES), or RivestCipher 4 (RC4). The embodiments of this application do not attempt to impose unnecessary restrictions on the encryption or decryption algorithm. Therefore, the encryption and decryption conversion relationship between the user negotiation communication key and the shadow negotiation communication key can be generally expressed as follows:

[0064] Co-User Shadow Message Key=Encrypt(Co-User Access Key, Co-UserMessage Key);

[0065] Co-User Message Key=Decrypt(Co-User Access Key, Co-User ShadowMessage Key);

[0066] 99: Co-User Key Version, used to identify the updated version of the shadow negotiated communication key caused by the update of the user negotiated communication key. The key version number is created by the server and stored in the first UCKC and the second UCKC. The update of the user negotiated communication key mentioned here can refer to an update initiated by the target user account or the peer user account that is unrelated to the client switch, rather than an update passively triggered by the client switch of either the target user account or the peer user account. That is, the embodiments of this application aim to avoid the forced update of the user negotiated communication key due to the user switching clients, but do not prohibit the two parties in the end-to-end communication from actively initiating the update of the user negotiated communication key.

[0067] In the embodiments of this application, the storage in the first UCKC and the second UCKC can both refer to persistent storage. "Persistent storage" means that the stored object is saved to a non-volatile storage medium such as flash memory or disk. That is, any information in persistent storage can be lost in response to operations with the intention to discard, such as deletion, or due to objective reasons such as hardware damage, but will not be automatically lost due to reasons without the intention to discard, such as hardware power failure.

[0068] In the embodiments of this application, parameters not stored in the first UCKC and the second UCKC may be allowed to be stored non-persistently. "Non-persistent storage" means that the stored objects are only saved to volatile storage media (such as the client's memory) such as RAM (Random-Access Memory), and not to non-volatile storage media such as Flash or disk. Therefore, any information in non-persistent storage will be automatically discarded after being used locally because there is no intention to discard it.

[0069] Figure 1 This is a schematic diagram illustrating the configuration of user communication key containers on the client and server sides of a key management method for secure communication in one embodiment of this application. Figure 2 This is a schematic diagram illustrating a key management method for secure communication in one embodiment of this application, demonstrating the principle of securely sharing user-negotiated communication keys between different clients of the same user. Figure 1 and Figure 2 As shown, in embodiments of this application, the data communication system may include a server 20, which may refer to a single physical server or a server cluster comprising multiple physical servers; furthermore, in embodiments of this application, the data communication system may also include multiple clients, wherein the multiple clients may include at least: a first client 10 belonging to a first user, a second client 70 belonging to a second user, and a third client 30 belonging to the first user, wherein the first user possesses a target user account, the second user possesses a peer user account, and in Figure 1 and Figure 2 In the diagram, the target user account logs in to the first client 10 and the third client 30 in turn.

[0070] Each of the first client 10, the second client 70, and the third client 30 described above can be a mobile terminal or a computer device such as a PC (Personal Computer). The embodiments of this application do not attempt to impose unnecessary restrictions on the physical form of the client.

[0071] Please refer to [the website / information] first. Figure 1Taking the initial creation of the first UCKC 810 of the target user account by the first client 10, and the initial creation of the second UCKC 820 in the server 20 triggered by the first client 10 as an example, in the process of creating the first UCKC 810 for the target user account, the first client 10 is an online client logged into the target user account, and the process of using the first client 10 to create the first UCKC 810 for the first time may include:

[0072] Using the user private identification code 90 input locally and the account access seed 91 generated locally, an account access key 92 is generated for the target user account, so as to create a first UCKC 810 containing the account access key 92 for the target user account on the local machine;

[0073] The account access seed 91 is sent to the server 20 to cause the server 20 to create a second UCKC 820 including the account access seed 91 for the target user account. That is, the second UCKC 820 can be created in the server 20 in response to the first creation of the first UCKC 810.

[0074] See also Figure 1 Taking the example of a third client 30 obtaining the first UCKC 810 of the target user account through the container initialization (or UCKC initialization) process of server 20, in the container initialization process, the third client 30 is an online client logged into the target user account, and the container initialization process may include:

[0075] The server 20 requests the account access seed 91 in the second UCKC 820 of the target user account. For the online client at this time (i.e., the third client 30), the account access seed 91 is generated by other clients (i.e., the first client 10) when the first UCKC 810 is first created.

[0076] Using the user private identification code 90 input locally and the account access seed 91 obtained from the server 20, an account access key 92 is generated to create a first UCKC 810 containing the account access key 92 on the local machine for the target user account. That is, for the online client (i.e. the third client 30) at this time, the first UCKC 810 configured locally is created through the container initialization process performed locally by interacting with the server 20.

[0077] It is understood that the aforementioned third client 30 can refer to any client other than the first client 10 that can log in to the target user account. Furthermore, if the first UCKC 810, which was first created by the local machine in the first client 10, is destroyed for some reason, the first client 10 can also re-obtain the first UCKC 810 through the aforementioned container initialization process.

[0078] In other words, any client belonging to the same user as the target user account can re-obtain the first UCKC 810 through the container initialization process described above. Furthermore, the account access seed 91 obtained from the server 20 through the container initialization process can be generated by any client that logs into the target user account when the first UCKC 810 is first created.

[0079] Figure 3 This is an exemplary flowchart illustrating the creation of a user communication key container using a key management method for secure communication in one embodiment of this application. Please refer to... Figure 3 The key management method for secure communication in this embodiment can be applied to an online client of the currently logged-in target user account, such as the first client 10 described above. Furthermore, the key management method may include the following steps for creating a UCKC:

[0080] S310: Using the user private identification code input locally and the account access seed generated locally, generate an account access key for the target user account, so as to create a first UCKC containing the account access key for the target user account on the local machine;

[0081] S330: Sends an account access seed to the server to prompt the server to create a second UCKC for the target user account, including the account access seed.

[0082] Figure 4 This is an exemplary flowchart illustrating a key management method for secure communication in one embodiment of this application, illustrating the process of obtaining a user communication key container through container initialization. Please refer to... Figure 4 The key management method for secure communication in this embodiment can be applied to an online client of the currently logged-in target user account, such as the third client 30 described above. Furthermore, the key management method may include the following steps for obtaining a first UCKC through container initialization:

[0083] S410: Request the server to obtain the account access seed from the second UCKC created for the target user account, wherein the account access seed can be generated by any client that logs into the target user account;

[0084] S430: Using the user private identification code input locally and the account access seed obtained from the server, generate an account access key to create a first UCKC containing the account access key on the local machine for the target user account.

[0085] In the embodiments of this application, the first UCKC 810 and the second UCKC 820 can also perform container updates in response to the update of the user private identifier 90. Furthermore, the container updates of the first UCKC 810 and the second UCKC 820 can be initiated by any client belonging to the same user as the target user account. That is, any client can initiate container updates of the first UCKC 810 and the second UCKC 820 in response to the update of the user private identifier 90 when logging into the target user account.

[0086] For example, in Figure 1 In the process, the first UCKC 810 of the target user account is created by the first client 10 for the first time, and the second UCKC 820 in the server 20 is created by the first UCKC 810 for the first time created by the first client 10. However, the container update of the first UCKC 810 and the second UCKC 820 in response to the update of the user private identifier 90 can be initiated by the first client 10 or by the third client 30.

[0087] Furthermore, the container updates for the first UCKC 810 and the second UCKC 820 involve updating the account access key 92 in the first UCKC 810 and updating the account access seed 91 in the second UCKC 820, wherein:

[0088] For any client that initiates a container update to the first UCKC 810 and the second UCKC 820:

[0089] The updated user private identification code (New PIN) input locally and the updated account access seed (New Access Seed) regenerated locally can be used to regenerate the updated account access key (New Access Key) according to the account access key 92 generation method described above. That is, New Access Key = Hash(New PIN + New Access Seed), thereby realizing the container update of the first UCKC 810 configured locally.

[0090] Alternatively, the account access seed 91 regenerated locally (i.e., the updated account access seed) can be used to update the account access seed 91 in the second UCKC 820 of server 20, thereby enabling container updates of the second UCKC 820 of server 20.

[0091] For other clients that have already configured the first UCKC 810, the server 20 can trigger a reinitialization of the locally configured first UCKC 810. For example, in response to each update triggered by an update of the target user account's second UCKC 820 due to an update of its user private identifier 90, the server 20 can send a container reinitialization notification to each other client that has configured the first UCKC 810 for that target user account. This prompts other clients logged into the target user account and online to destroy their locally configured first UCKC 810 for that target user account in response to the container reinitialization notification. Furthermore, after destroying their locally configured first UCKC 810, other clients logged into the target user account and online can update the container of their locally configured first UCKC 810 through a re-container initialization after the destruction of the locally configured first UCKC 810.

[0092] In other words, the conditions for destroying the first UCKC 810 include not only the target user account actively or passively logging out of the client, and the second UCKC 820 in server 20 being destroyed by the management and control platform, but also the client logged into the target user account and in an online state receiving a container reinitialization notification.

[0093] In the embodiments of this application, "account access seed 91" is used to generalize the first-generation account access seed and the updated account access seed that is updated in response to any update of the user's private identifier. Similarly, "account access key 92" is used to generalize the first-generation account access key and the updated account access key that is updated in response to any update of the user's private identifier.

[0094] That is, in the embodiments of this application, the key management method may further include: regenerating the account access seed 91 in response to an update of the user private identification code 90, so as to initiate a container update of the first UCKC 810 and the second UCKC 820 using the regenerated account access seed 91. Specifically, the container update may include the following steps performed by any client:

[0095] Using the updated user private identification code 90 of the target user account input on the local machine and the account access seed 91 regenerated on the local machine, an account access key 92 is regenerated for the target user account, so as to replace the existing account access key 92 in the first UCKC 810 configured on the local machine with the regenerated account access key 92.

[0096] The regenerated account access seed 91 is sent to server 20 to prompt server 20 to update the account access seed 91 stored in the second UCKC820;

[0097] Server 20 is configured to: in response to a successful update of account access seed 91 in the second UCKC 820, clear the information associated with the target user account in the second UCKC bound to the peer user account, initiate container initialization (including container destruction operation) in the first UCKC 810 configured by other clients, and initiate information clearing operations performed by all clients logging into the peer user account on the information associated with the target user account (e.g., all information stored in the first UCKC bound to the peer user account with the target user account as the peer).

[0098] Figure 5 This is a schematic diagram illustrating an exemplary process for initiating a container update using a key management method for secure communication, as shown in one embodiment of this application. Please refer to... Figure 5 The key management method for secure communication in this embodiment can be applied to an online client currently logged into the target user account, such as the first client 10 or the third client 30 described above. Furthermore, the key management method may include the following steps for initiating container updates to the first UCKC and the second UCKC:

[0099] S510: Using the updated user private identifier of the target user account input locally and the updated account access seed regenerated locally, an updated account access key is regenerated for the target user account, so as to replace the existing account access key in the first UCKC configured locally with the updated account access key. For example, the existing account access key may be the original account access key included when the first UCKC was first created or the updated account access key after the last container update.

[0100] S530: Send the updated account access seed to the server to prompt the server to replace the existing account access seed in the second UCKC with the updated account access seed.

[0101] Figure 6 This is an exemplary flowchart illustrating a key management method for secure communication in response to container updates, as shown in one embodiment of this application. Please refer to... Figure 6 The key management method for secure communication in this embodiment can be applied to an online client currently logged into the target user account, such as the first client 10 or the third client 30 described above. Furthermore, the key management method may include the following steps (executed by the client logged into the target user account and currently online) to re-execute container initialization in response to a container update:

[0102] S610: In response to a container reinitialization notification sent from the server after the second UCKC is updated by the container, destroy the first UCKC that has been configured locally;

[0103] S630: By re-initializing the container (i.e., as...) Figure 4 (The process shown) reconfigures the first UCKC on the local machine after it has been updated by the container.

[0104] As can be seen above, in the embodiments of this application:

[0105] Any client that logs into the target user account can use the account access seed 91 obtained from the server 20 to initialize the container on the local machine, so as to create a first UCKC containing the account access key 92 for the target user account on the local machine. Specifically, through container initialization, any client that logs into the target user account can generate an account access key 92 based on the user private identification code 90 entered on the local machine and the account access seed 91 obtained from the server 20, so as to create a first UCKC 810 containing the account access key 92 for the target user account on the local machine.

[0106] Any client that initiates a container update can use the locally regenerated account access seed 91 to update the account access key 92 in the first UCKC 810 and the account access seed 91 in the second UCKC in the local configuration;

[0107] The second UCKC 820 can be created in the server 20 in response to the initial creation of the first UCKC, and the account access seed 91 in the second UCKC 820 can be generated by any client for the target user account when the first UCKC 810 is first created or when a container update is initiated due to the update of the user's private identifier 90.

[0108] Please review Figure 2 In the embodiments of this application, the online client currently logged into the target user account can also utilize the first UCKC 810 configured locally to convert the user negotiation communication key 96 negotiated between the target user account and the peer user account into a shadow negotiation communication key 98, and store it in the second UCKC 820 created by the server 20 for the target user account. Therefore, when the user logs into the target user account using any client they own, by configuring the first UCKC 810 for the client and obtaining the shadow negotiation communication key 98 from the server 20, they can obtain the user negotiation communication key 96 negotiated between the target user account and the peer user account.

[0109] exist Figure 2In the example of the first client 10 acting as an online client to convert the user-negotiated communication key 96 into a shadow-negotiated communication key 98 and send it to the server 20, the process may specifically include:

[0110] The first client 10 obtains a user negotiation communication key 96 for end-to-end communication between the target user account and the peer user account, as well as the peer user account identifier 95 of the peer user account. The obtained user negotiation communication key 96 can be directly used by the first client 10 to realize communication between the target user account and the peer user account. Furthermore, the obtained user negotiation communication key 96 will not be stored by the first client 10 in the first UCKC 810 configured on its own machine, nor will it be stored by the server 20 in the second UCKC 820.

[0111] The first client 10 uses the obtained user negotiation communication key 96, the peer user account identifier 95, and the account access key 92 in the first UCKC 810 configured locally to generate a shadow negotiation communication key 98. For example, it first generates a user negotiation access key 97 based on the peer user account identifier 95 and the account access key 92, and then generates a shadow negotiation communication key 98 based on the user negotiation access key 96 and the user negotiation communication key 97. The shadow negotiation communication key 98 generated locally can be stored in the first UCKC 810 configured locally.

[0112] The first client 10 associates the shadow negotiation communication key 98 with the peer user account identifier 95 and stores it in the second UCKC 820 created for the target user account in the server 20, so as to allow any client (e.g., the third client 30) to log in to the target user account, configure the first UCKC 810, and need to conduct end-to-end communication with the peer user account:

[0113] Using the peer user account identifier 95 obtained from the second client 70 that logs in to the peer user account, the client requests the server 20 to obtain the shadow negotiation communication key 98 stored in the second UCKC 820. The shadow negotiation communication key 98 obtained from the server 20 can be stored in the first UCKC 810 configured locally.

[0114] Using the peer user account identifier 95 obtained from the second client 70 that logs into the peer user account, the account access key 92 in the first UCKC 810 configured on the local machine, and the shadow negotiation communication key 98 successfully obtained from the server 20, the user negotiation communication key is restored. For example, a user negotiation access key 97 is first generated based on the peer user account identifier 95 and the account access key 92, and then a user negotiation communication key 96 is restored based on the shadow negotiation communication key 98 and the user negotiation access key 97. The restored user negotiation communication key 96 is not stored in the first UCKC 810 configured on the local machine.

[0115] It is understood that the online client used to convert the user negotiation communication key 96 into a shadow negotiation communication key 98 and store the shadow negotiation communication key 98 in the second UCKC 820 of the server 20 may not be limited to the first client 10, but may also be the third client 30; the first client 10 may also use the shadow negotiation communication key 98 in the second UCKC 820 of the server 20 to restore the user negotiation communication key 96.

[0116] Furthermore, in the embodiments of this application, any client that logs into the target user account can store the shadow negotiation communication key 98 generated or obtained locally into the first UCKC configured locally.

[0117] Figure 7 This is a schematic diagram illustrating an exemplary process of storing a shadow-negotiated communication key in a user communication key container, as part of a key management method for secure communication in one embodiment of this application. Please refer to... Figure 7 The key management method for secure communication in this embodiment can be applied to an online client currently logged into a target user account, such as the first client 10 or the third client 30 described above. This online client is configured with a first UCKC, which includes an account access key generated based on the target user account's private identifier. Furthermore, the key management method may include the following steps: storing a shadow negotiation communication key in a second UCKC on the server.

[0118] S710: Obtain the user-negotiated communication key used for end-to-end communication between the target user account and the peer user account, as well as the peer user account identifier of the peer user account.

[0119] The user negotiation communication key obtained by S710 can be directly used by the local machine.

[0120] S730: Generates a shadow negotiation communication key using the obtained user negotiation communication key, the peer user account identifier, and the account access key in the first UCKC configured on the local machine.

[0121] For example, S730 may specifically include: generating a user negotiation access key based on the peer user account identifier and account access key, and generating a shadow negotiation communication key based on the user negotiation access key and the user negotiation communication key; moreover, the shadow negotiation communication key generated by S730 can be stored in the first UCKC configured on the local machine.

[0122] S750: Associates the shadow negotiation communication key with the peer user account identifier and stores it in the server to create a second UCKC for the target user account.

[0123] Figure 8 This is an exemplary flowchart illustrating a key management method for secure communication in one embodiment of this application, illustrating the process of retrieving a shadow negotiation communication key from a user communication key container on the server side. Please refer to... Figure 8 The key management method for secure communication in this embodiment can be applied to an online client currently logged into a target user account, such as the first client 10 or the third client 30 described above. This online client is configured with a first UCKC, which includes an account access key generated based on the target user account's private identifier. Furthermore, the key management method may include the following steps: retrieving a shadow negotiation communication key from a second UCKC on the server.

[0124] S810: Obtain the peer user account identifier of the peer user account that is communicating end-to-end with the target user account.

[0125] S830: Using the obtained peer user account identifier, request the server to obtain the shadow negotiation communication key stored in the second UCKC created for the target user account. The shadow negotiation communication key is generated by any client logged into the target user account using the user negotiation communication key negotiated between the target user account and the peer user account, as well as the peer user account identifier and account access key.

[0126] The shadow negotiation communication key obtained by S830 can be stored in the first UCKC configured on the local machine.

[0127] S850: Using the obtained peer user account identifier, the account access key in the first UCKC configured on the local machine, and the shadow negotiation communication key successfully obtained from the server, the user negotiation communication key is restored.

[0128] For example, S850 may specifically include: generating a user negotiation access key based on the peer user account identifier and account access key, and generating a user negotiation communication key based on the shadow negotiation communication key and the user negotiation access key.

[0129] The user-negotiated communication key obtained by restoring the S850 can be directly used by the local machine.

[0130] As described above, in the embodiments of this application, the user negotiation communication key 96 can also be updated by a renegotiation initiated by either the target user account or the peer user account (the reason for renegotiation may be unrelated to client switching). That is, according to the method for determining the shadow negotiation communication key 98 described above, the updated shadow negotiation communication key is re-determined using the peer user account identifier 95, the account access key 92, and the updated user negotiation communication key (New Co-User Message Key). Moreover, the user negotiation communication key 96 can be initiated even if the user private identification code 90 of the target user account has not been updated, and it triggers a key update of the shadow negotiation communication key 98 stored in the first UCKC 810 and the second UCKC 820 bound to the target user account.

[0131] As mentioned above, if the user private identifier 90 of the target user account is updated, the first UCKC 810 bound to the target user account in any client that is logged into the target user account and is online will respond to the container reinitialization notification and perform a container initialization operation. Furthermore, the container destruction triggered by the container initialization operation can clear the existing shadow negotiation communication key 98 in the first UCKC 810.

[0132] That is, the shadow negotiation communication key 98 in the first UCKC 810 configured by any client and the second UCKC 820 of the server 20 can be updated in response to the renegotiation of the user negotiation communication key 96 by the target user account and the peer user account, or the key can be cleared in response to the update of the user private identifier 90 of the target user account (e.g., in response to the container initialization that is re-executed after the creation of the first UCKC 810).

[0133] In the embodiments of this application, "user negotiation communication key 96" is used to generalize the user negotiation communication key determined in the first negotiation and the updated user negotiation communication key determined in any renegotiation. Similarly, "shadow negotiation communication key 98" is used to generalize the shadow negotiation communication key generated in the first negotiation and the updated shadow negotiation communication key 98 in response to any renegotiation of the user negotiation communication key.

[0134] Therefore, in response to the renegotiation of the user negotiation communication key 96 by the target user account and the peer user account:

[0135] Any client (e.g., first client 10 or third client 30) that is logged into the target user account and configured with the first UCKC 810 can initiate a key update for the shadow negotiation communication key 98 in the first UCKC 810 and the second UCKC 820 configured on the local machine;

[0136] Other clients configured with the first UCKC 810 can be triggered by server 20 to update the existing shadow negotiation communication key 98 in their local configuration of the first UCKC 810. Furthermore, other clients can, when they need to conduct end-to-end communication with the peer user account, further update the key via methods such as... Figure 8 The process shown re-acquires the updated shadow negotiation communication key 98 and uses the updated shadow negotiation communication key 98 to restore the updated user negotiation communication key 96.

[0137] For example, in response to an update of the shadow negotiation communication key 980 in the second UCKC, server 20 can send a key update notification to each client configured with the first UCKC, thereby allowing any client to update the user negotiation communication key 96 in the first UCKC configured locally in response to the key update notification received from server 20.

[0138] In other words, in the embodiments of this application, key update may specifically include the following steps performed by any client:

[0139] In response to the renegotiation of the user negotiation communication key 96 between the target user account and the peer user account, an updated shadow negotiation communication key 98 is generated using the peer user account identifier and account access key 92, as well as the user negotiation communication key 96 determined by the renegotiation between the target user account and the peer user account.

[0140] The updated shadow negotiation communication key 98 is used to replace the existing shadow negotiation communication key 98 in the first UCKC 810 configured locally, and the updated shadow negotiation communication key 98 is sent to the server 20 so that the server 20 can use the updated shadow negotiation communication key 98 to replace the shadow negotiation communication key 98 that is already stored in the second UCKC 820 associated with the peer user account identifier.

[0141] Server 20 can be configured to initiate an update of the shadow negotiation communication key 98 in the first UCKC 810 configured by other clients in response to a successful update of the shadow negotiation communication key 98 in the second UCKC 820.

[0142] Figure 9 This is an exemplary flowchart illustrating a key update process initiated by a key management method for secure communication in one embodiment of this application. Please refer to... Figure 9The key management method for secure communication in this embodiment can be applied to an online client currently logged into a target user account, such as the first client 10 or the third client 30 described above. This online client is configured with a first UCKC, which includes an account access key generated based on the target user account's private identifier. Furthermore, the key management method may include the following steps for initiating a key update to the shadow negotiation communication key:

[0143] S910: In response to the renegotiation of the user negotiation communication key between the target user account and the peer user account, an updated shadow negotiation communication key is generated using the obtained peer user account identifier, the account access key in the first UCKC configured on the local machine, and the updated user negotiation communication key determined by the renegotiation between the target user account and the peer user account, so as to replace the shadow negotiation communication key in the first UCKC configured on the local machine with the updated shadow negotiation communication key.

[0144] S930: Send the updated shadow negotiation communication key to the server to prompt the server to replace the shadow negotiation communication key stored in the second UCKC that is associated with the peer user account identifier with the updated shadow negotiation communication key.

[0145] Figure 10 This is an exemplary flowchart illustrating a key management method for secure communication in response to a key update, as shown in one embodiment of this application. Please refer to... Figure 9 The key management method for secure communication in this embodiment can be applied to an online client currently logged into a target user account, such as the first client 10 or the third client 30 described above. This online client is configured with a first UCKC, which includes an account access key generated based on the target user account's private identifier. Furthermore, the key management method may include the following steps in response to a key update for the shadow negotiation communication key:

[0146] S950: In response to a key update notification issued by the server after the shadow negotiation communication key in the second UCKC has been updated, obtain the updated shadow negotiation communication key.

[0147] For example, the S950 can retrieve the updated shadow negotiation communication key from the server's second UCKC, for example, through... Figure 8 The process shown is retrieved again.

[0148] S970: Using the obtained updated shadow negotiation communication key, perform an update operation on the shadow negotiation communication key in the first UCKC configured on the local machine. That is, replace the existing shadow negotiation communication key in the first UCKC configured on the local machine with the obtained updated shadow negotiation communication key. Thus, the renegotiationd user negotiation communication key can be obtained using the updated key.

[0149] Figure 11 This is an extended schematic diagram of a key management method for secure communication in one embodiment of this application, which configures user communication key containers on the client and server sides. Figure 12 This is an extended schematic diagram illustrating a key management method for secure communication in one embodiment of this application, demonstrating the secure sharing of user-negotiated communication keys between different clients of the same user. Please refer to... Figure 11 and Figure 12 In the embodiments of this application, in order to facilitate the client in determining whether the local machine needs to perform the corresponding operations associated with container update and key update, container version number 94 and key version number 95 can be introduced.

[0150] With container version number 94 introduced, server 20 can be configured to: assign a corresponding container version number 94 to the first UCKC 810 in response to the initial creation of the first UCKC 810 and the second UCKC 820; and update the container version number 94 in response to each container update of the first UCKC 810 and the second UCKC 820 due to user private identifier 90. This container version number 94 can be stored in the first UCKC 810 and the second UCKC 820, such that:

[0151] In response to each container update triggered by the update of the second UCKC 820 due to the update of the user private identifier 90, server 20 sends a container reinitialization notification carrying the updated container version number 94 to each client configured with the first UCKC 810, i.e., as mentioned above. Figure 6 The container reinitialization notification received in S610 of the illustrated process can further carry the updated container version number, and any client responding to the received container reinitialization notification can, as described above... Figure 6 In step S610 of the illustrated process, further determination is made based on whether the container version number in the container reinitialization notification represents a newer version than the container version number in the first UCKC 810 configured on the local machine. This determines whether to perform a reinitialization operation in response to the container update on the first UCKC 810 configured on the local machine.

[0152] If the container version number carried in the container reinitialization notification indicates a new version compared to container version number 94 in the first UCKC810 configured on the local machine, then the container is destroyed and the container is reinitialized for the first UCKC810 configured on the local machine.

[0153] Otherwise, the container reinitialization notification is deemed expired, and the first UCKC810 configuration for the local machine is abandoned, and the container destruction and reinitialization operations are abandoned.

[0154] With the introduction of key version number 99, server 20 can be configured to: assign a corresponding key version number 99 to shadow negotiation communication key 98 in response to the first generation of shadow negotiation communication key 98; update key version number 99 in response to each key update of shadow negotiation communication key 98; and store key version number 99 in association with shadow negotiation communication key 98 in first UCKC and second UCKC, such that:

[0155] Server 20 can respond to the update of the shadow negotiation communication key 98 in the second UCKC and the associated update of the key version number 99 by sending a key update notification carrying the updated key version number to the client configured with the first UCKC, i.e., as mentioned above. Figure 10 The key update notification received in S950 of the illustrated process can further carry the updated key version number, and any client, in response to the received key update notification, can, as described above... Figure 10 In step S950 of the illustrated process, the system further determines whether to perform an update operation on the shadow negotiation communication key 98 in the first UCKC configured on the local machine, based on whether the key version number in the key update notification represents a new version compared to the existing key version number in the first UCKC 810 configured on the local machine.

[0156] If the key version number carried in the key update notification indicates a new version compared to the key version number 99 in the first UCKC 810 configured locally, then an update operation in response to the key update is performed on the shadow negotiation communication key 98 in the first UCKC 810 configured locally.

[0157] Otherwise, the key update notification is deemed expired, and the update operation for the shadow negotiation communication key 98 in the first UCKC 810 configured on the local machine is abandoned.

[0158] As mentioned above, the container update occurs after the update of the user private identifier 90. Moreover, after the container update, some clients that have configured the first UCKC 810 may miss the container reinitialization notification issued by the server 20 and fail to perform the destruction and reinitialization of the first UCKC 810. For example, a client logged into the target user account but in an offline state neither performs the destruction of the first UCKC 810 due to logging out, nor does it receive the container reinitialization notification due to being offline, thus missing the destruction and reinitialization of the first UCKC 810. As a result, the account access key 92 in the first UCKC 810 of such a client is an invalid account access key that has become invalid due to the update of the user private identifier 90. Furthermore, even if the shadow negotiation communication key 98 updated due to the renegotiation of the user negotiation communication key 96 is obtained from the server 20, the invalid account access key cannot restore the updated shadow negotiation communication key 98 to the renegotiation of the user negotiation communication key 96.

[0159] It is evident that for the client in the above situation:

[0160] During the first delay period after the user's private identifier 90 is updated and before the container is updated, the second UCKC 820 of server 20 is actually in a invalid state, and container initialization implemented using server 20 at this time is meaningless.

[0161] During the second delay period after the second UCKC 820 of server 20 completes container update (i.e., account access key 92 has been updated) and key update of shadow negotiation communication key 98, and before the local machine completes container reinitialization of the first UCKC 810 (i.e., the local machine's account access key 92 becomes invalid), the account access key 92 configured in the first UCKC 810 of the local machine cannot restore the updated shadow negotiation communication key 98 to the renegotiated user negotiation communication key 96.

[0162] See also Figure 11 and Figure 12 In order to facilitate the client in determining whether the second UCKC 820 of the server 20 and the first UCKC 810 configured on the local machine have become invalid due to the update of the account private identification code 90, the embodiments of this application can further introduce an account access code 93. This avoids using the invalid second UCKC 820 stored by the server 20 to initialize the local machine container, or avoids the local machine using the account access key 92 in the invalid first UCKC 810 to restore the shadow negotiation communication key 98 to the user negotiation communication key 96, which cannot enable the end-to-end session to proceed successfully. This avoids unnecessary waste of computing resources on the client.

[0163] The account access code 93 can be generated by any client when the first UCKC 810 is first created, or when a container update is initiated due to an update of the user's private identifier 90. For example, when a container update occurs, the updated account access code (New Access Code) can also be generated in the same way as when the account access code 93 was first created, i.e., New Access Code = Hash (New Access Key). In the embodiments of this application, "account access code 93" is used to generalize the first generated account access code and the updated account access code that is updated in response to any update of the user's private identifier 90.

[0164] Furthermore, the first UCKC 810 and the second UCKC 820 may also include account access code 93.

[0165] That is, in the embodiments of this application:

[0166] The previous text is as follows Figure 3 In the process shown, S310 can further generate account access code 93 and store it in the first UCKC 810 created on the local machine;

[0167] The previous text is as follows Figure 3 In the process shown, S330 can further send the account access code 93 to the server 20 and associate it with the account access seed 91 in the second UCKC 820 for storage;

[0168] The previous text is as follows Figure 4 In the process shown, S410 can further obtain the account access code 93 stored in the second UCKC 820 from the server 20;

[0169] The previous text is as follows Figure 4 S430 in the process shown can further verify the consistency of account access codes 93 and 93' on the local machine and server 20, detect whether the second UCKC 820 has become invalid due to the update of the user private identification code 90, and the container initialization on the local machine is enabled to be executed if the second UCKC 820 is determined to be valid.

[0170] If in such Figure 4In the illustrated process, S430 determines that the account access code 93' generated by the local machine using the input user private identifier 90' (first generating the account access key 92', then generating the account access code 93' based on the account access key 92') is inconsistent with the account access code 93 retrieved and provided by the server 20 from the second UCKC 820. Therefore, it is determined that the user private identifier 90' currently input by the local machine has been updated compared to the user private identifier 90 on which the account access code 93 was generated in the second UCKC 820. Thus, although the container update has not yet been initiated, the second UCKC 820 of the server 20 is currently in an invalid state. Therefore, the use of the second UCKC 820 of the server 20 for container initialization is abandoned, and instead, the following method can be used instead: Figure 3 In the process shown, S310 creates the first UCKC 810 on the local machine, and through, as... Figure 5 In the process shown, S530 initiates an update to the second UCKC 20, that is, as follows: Figure 3 S310 of the process shown and as Figure 5 S530 in the process shown can be combined into another container update process;

[0171] The previous text is as follows Figure 5 In the process shown, S510 can further update the account access code 93 during container update. That is, S510 can use the updated user private identifier 90 (i.e., updated user private identifier) ​​of the target user account input locally and the account access seed 91 (i.e. updated account access seed) regenerated for the target user account to regenerate the account access key 92 (i.e. updated account access key), so as to replace the account access key 92 in the first UCKC 810 configured locally with the updated account access key. Moreover, S510 also uses the regenerated account access key 92 (i.e. updated account access key) to regenerate the account access code 93 (i.e. updated account access code) of the target user account, so as to replace the account access code 93 in the first UCKC 810 configured locally with the regenerated account access code 93 (i.e. updated account access code).

[0172] The previous text is as follows Figure 5In the process shown, S530 can further send the updated account access code 93 together with the updated account access seed 91, or together with the updated account access seed 91 and the updated shadow negotiation communication key 98 to the server 20 and update it in the second UCKC 820. That is, S530 can send the regenerated account access seed 91 (i.e., updated account access seed), the regenerated account access code 93 (i.e., updated account access code), and the regenerated shadow negotiation communication key 98 (i.e., updated shadow negotiation communication key) to the server 20, so that the server 20 can use the regenerated account access seed 91 (i.e., updated account access seed), the regenerated account access code 93 (i.e. updated account access code), and the regenerated shadow negotiation communication key 98 (i.e. updated shadow negotiation communication key) to replace the account access seed 91, account access code 93, and shadow negotiation communication key 98 stored in the second UCKC 820.

[0173] The previous text is as follows Figure 8 In the process shown, S850 can further obtain the account access code 93' sent together with the shadow negotiation communication key 98 from the server 20. Using the consistency check of the account access codes 93 and 93' on the local machine and the server 20, it can detect whether the first UCKC 810 configured on the local machine has become invalid due to the update of the user private identification code 90. If the shadow negotiation communication key 98 obtained by the local machine is determined to be valid, it is determined to be valid and allowed to be stored in the first UCKC 810 configured on the local machine. If the first UCKC 810 configured on the local machine is determined to be invalid, the container is destroyed.

[0174] If in such Figure 8In the illustrated process, S850 determines that the account access code 93 in the first UCKC 810 configured on the local machine is inconsistent with the account access code 93' retrieved and provided by the server 20 from the second UCKC 820. Therefore, it is confirmed that both the account access key 92 and the account access code 93 in the first UCKC 810 configured on the local machine are invalid due to the update of the user private identifier 90. Thus, the shadow negotiation communication key 98 obtained from the second UCKC 820 of the server 20 can be discarded, and the restoration operation of the user negotiation communication key 96 is no longer performed. Furthermore, the first UCKC 810 configured on the local machine is destroyed when the account access key 92 and the account access code 93 are determined to be invalid. The shadow negotiation communication key 98 requested by the client from the server 20 can be the shadow negotiation communication key 98 corresponding to the peer user account that is communicating end-to-end with the current client for the first time, or it can be the updated shadow negotiation communication key 98 corresponding to the peer user account that has already communicated end-to-end with the current client. In the latter case, the client that logs into the target user account requests the latest shadow negotiation communication key 98 from the server 20. This can be triggered after the end-to-end session fails for a preset duration or after the number of times the encrypted information fails to be decrypted reaches a preset number. The reason for the end-to-end session failure is that the client cannot restore the updated shadow negotiation communication key 98 to the renegotiated user negotiation communication key 96.

[0175] As can be seen above, when the account access code 93 is introduced in the embodiments of this application, the key management method may further include: generating an account access code 93 for the target user account based on the account access key 92; and sending the account access code 93 to the server 20 and storing it in the second UCKC 820. Moreover, any client may perform a container destruction operation on the first UCKC 810 configured on its local machine when the consistency verification of account access codes 93 and 93' between the local machine and the server 20 fails.

[0176] That is, the conditions for destroying the first UCKC 810 include, in addition to the target user account actively or passively logging out of the client, the second UCKC 820 in the server 20 being destroyed by the management and control platform, and the client logged into the target user account and in an online state receiving a container reinitialization notification, the conditions for destroying the first UCKC 810 may also include the failure of consistency verification of account access codes 93 and 93' on the local machine and the server 20.

[0177] Furthermore, in the case of introducing account access code 93 in this application embodiment, container update may further include: regenerating account access code 93 for the target user account using the updated account access key 92, so as to replace the existing account access code 93 in the first UCKC 810 configured locally with the locally generated account access code 93; and sending the regenerated account access code 93 to the server 20 to cause the server 20 to update the account access code stored in the second UCKC 820, and allowing:

[0178] Any client that logs into the target user account can also, before initializing the container on the local machine using the account access seed 91 obtained from the server 20: check the consistency of account access codes 93 and 93' on the local machine and the server 20 to detect whether the second UCKC 820 has become invalid due to the update of the user's private identifier 90. The container initialization on the local machine is enabled and executed if the second UCKC 820 is determined to be valid. Furthermore, the first UCKC 810 configured on the local machine can be executed to destroy the container in response to the consistency check of account access codes 93 and 93' on the local machine and the server 20.

[0179] After any client logging into the target user account obtains the shadow negotiation communication key 98 from server 20 and before restoring the user negotiation communication key 96 using the shadow negotiation key 98: the consistency check of account access codes 93 and 93' between the local machine and server 20 is used to check whether the first UCKC 810 configured on the local machine has become invalid due to the update of the user private identification code 90. The shadow negotiation communication key 98 obtained by the local machine is determined to be valid if the first UCKC 810 configured on the local machine is determined to be valid, and is allowed to be stored in the first UCKC 810 configured on the local machine. It can also be considered that the restoration of the user negotiation communication key 96 by the local machine is enabled to be executed if the first UCKC 810 configured on the local machine is determined to be valid. Furthermore, the first UCKC 810 configured on the local machine can be destroyed in response to the consistency check of account access codes 93 and 93' between the local machine and server 20.

[0180] In the embodiments of this application, the account access code 93 can also be used by the server 20 to verify the container update of the second UCKC 820 initiated by any client. That is, the container update of the second UCKC 820 in the server 20 can be allowed to be executed if the same account access code 93 before the update is stored in the first UCKC 810 of the client that initiates the container update and the second UCKC 820 of the server 20.

[0181] In this scenario, when any client initiates a container update for the second UCKC 820 on server 20, it can send the two account access codes 93 (before and after the update) from the first UCKC 810 configured on its local machine, along with the updated access seed 91, to server 20 in the container update request. Server 20 can use the consistency check between the account access code 93 (before the update) carried in the container update request and the account access code 93' currently stored in the second UCKC 820 to determine whether to allow the container update of the second UCKC 820 using the updated access seed 91 and the updated account access code 93 in the container update request.

[0182] Similarly, in the embodiments of this application, the account access code 93 can also be used by the server 20 to verify the key update initiated by any client for the shadow negotiation communication key 98. That is, the key update of the shadow negotiation communication key 98 in the second UCKC 820 of the server 20 can be allowed to be performed if the same account access code 93 is stored in the first UCKC 810 of the client that initiates the key update and the second UCKC 820 of the server 20.

[0183] In this scenario, when any client initiates a key update request for the shadow negotiation communication key 98 in the second UCKC 820 of server 20, it can send the account access code 93 configured in the first UCKC 810 on its own machine along with the updated shadow negotiation communication key 98 to server 20. Server 20 can use the consistency check between the account access code 93 carried in the key update request and the account access code 93' in the second UCKC 820 to determine whether it is allowed to use the shadow negotiation communication key 98 in the key update request to update the key of the second UCKC 820.

[0184] In addition, Figure 2 and Figure 12 The peer user account logged into by the second client 70 shown in the figure can also be used as another target user account to apply the key management method in this application embodiment. In this case, when multiple users use the key management method in this application embodiment in pairs, the destruction of the first UCKC 810 and the second UCKC 820 of each target user account can trigger other target user accounts that regard the target user account as the peer user account to simultaneously clean up the information associated with the destroyed target user account in the first UCKC and the second UCKC of the other target user accounts.

[0185] Figure 13 This is a schematic diagram illustrating an exemplary structure of a client in an embodiment of this application. Please refer to [link / reference]. Figure 13In another embodiment of this application, a client is also provided, which may include a processor 1300, a communication component 1310, a human-computer interaction component 1320, and a storage medium 1330. The processor 1300 is used to execute the key management method as described in the foregoing embodiments. The communication component 1310 can be used to enable the client to communicate with the server and other clients that have logged into the peer user account. The human-computer interaction component 1320 can be used to input the user private identification code of the target user account. The storage medium 1330 can be used to store the first UCKC.

[0186] In another embodiment of this application, a data communication system is also provided, which may include the aforementioned client, a server connected in communication with the client, and a storage device connected in communication with the server, the storage device being used to store a second UCKC.

[0187] In another embodiment of this application, a non-transitory computer-readable storage medium is also provided, which stores instructions that, when executed by a processor, cause the processor to perform the key management method as described in the foregoing embodiments.

[0188] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A key management method for secure communication, characterized in that, The key management method is applied to any client currently logged into a target user account and configured with a first user communication key container created for the target user account. The first user communication key container includes an account access key generated based on the target user account's private identifier. Furthermore, the key management method includes: Obtain the user negotiation communication key used for end-to-end communication between the target user account and the peer user account, as well as the peer user account identifier of the peer user account; A shadow negotiation communication key is generated using the user negotiation communication key, the peer user account identifier, and the account access key; The shadow negotiation communication key is associated with the peer user account identifier and stored in a second user communication key container created for the target user account on the server. This allows any client to communicate end-to-end with the peer user account when logged into the target user account, configured with the first user communication key container, and needing to communicate with the peer user account. Using the peer user account identifier, request the server to obtain the shadow negotiation communication key stored in the second user communication key container; The user negotiation communication key is reconstructed using the peer user account identifier, the account access key, and the shadow negotiation communication key successfully obtained from the server.

2. The key management method according to claim 1, characterized in that, The step of generating a shadow negotiation communication key using the user negotiation communication key, the peer user account identifier, and the account access key includes: generating a user negotiation access key based on the peer user account identifier and the account access key, and generating the shadow negotiation communication key based on the user negotiation access key and the user negotiation communication key. The step of restoring the user negotiation communication key using the peer user account identifier, the account access key, and the shadow negotiation communication key includes: generating the user negotiation access key based on the peer user account identifier and the account access key, and restoring the user negotiation communication key based on the shadow negotiation communication key and the user negotiation access key.

3. The key management method according to claim 1, characterized in that, The key management method further includes: Store the shadow negotiation communication key generated locally or obtained locally from the server into the first user communication key container configured locally; The shadow negotiation communication key in the first user communication key container configured on any client and the second user communication key container on the server is subject to key update in response to the renegotiation of the user negotiation communication key by the target user account and the peer user account, or is subject to key clearing in response to the update of the user private identifier.

4. The key management method according to claim 3, characterized in that, The key update includes: In response to the renegotiation of the user negotiation communication key between the target user account and the peer user account, an updated shadow negotiation communication key is generated using the peer user account identifier, the account access key, and the user negotiation communication key determined by the renegotiation between the target user account and the peer user account. The updated shadow negotiation communication key is used to replace the existing shadow negotiation communication key in the first user communication key container configured on the local machine, and the updated shadow negotiation communication key is sent to the server so that the server can use the updated shadow negotiation communication key to replace the shadow negotiation communication key that is stored in the second user communication key container associated with the peer user account identifier. The server is configured to: in response to the successful update of the shadow negotiation communication key in the second user communication key container, initiate an update of the shadow negotiation communication key in the first user communication key container configured by other clients.

5. The key management method according to claim 4, characterized in that, The server is configured as follows: Assign a corresponding key version number to the shadow negotiation communication key, wherein the key version number is updated in response to each key update, and the key version number is stored in association with the shadow negotiation communication key in the first user communication key container and the second user communication key container; In response to the successful key update of the shadow negotiation communication key in the second user communication key container and the associated update of the key version number, a key update notification carrying the updated key version number is sent to each client configured with the first user communication key container. The key update also includes: In response to the key version number carried in the received key update notification indicating a new version compared to the existing key version number in the first user communication key container configured locally, the key update is performed on the shadow negotiation communication key in the first user communication key container configured locally.

6. The key management method according to claim 1, characterized in that, The key management method further includes: The account access key is generated based on the account access seed generated by the local machine for the target user account and the user private identification code input by the local machine; The account access seed is sent to the server to cause the server to create a second user communication key container including the account access seed for the target user account, and to allow: Any client that logs into the target user account initializes a container on its local machine using the account access seed obtained from the server, and creates a first user communication key container containing the account access key for the target user account on the local machine.

7. The key management method according to claim 6, characterized in that, The container initialization includes: Request the server to obtain the account access seed from the second user communication key container; The user private identification code input locally and the account access seed obtained from the server are used to generate the account access key, so as to create a first user communication key container containing the account access key on the target user account locally.

8. The key management method according to claim 6, characterized in that, The key management method further includes: In response to the update of the user private identifier, the account access seed is regenerated to initiate a container update of the first user communication key container and the second user communication key container using the regenerated account access seed; The shadow negotiation communication key in the first user communication key container configured by any client and the second user communication key container of the server is cleared by execution key in response to the container initialization that is re-executed after the creation of the first user communication key container.

9. The key management method according to claim 8, characterized in that, The container update includes: Using the updated user private identification code of the target user account input by the local machine and the account access seed regenerated by the local machine, the account access key is regenerated for the target user account, so as to replace the existing account access key in the first user communication key container configured by the local machine with the regenerated account access key. The regenerated account access seed is sent to the server to cause the server to update the account access seed stored in the second user communication key container that is associated with the peer user account identifier; The server is configured to: in response to a successful update of the account access seed in the second user communication key container, initiate the container initialization of the first user communication key container configured by other clients to be re-executed.

10. The key management method according to claim 9, characterized in that, The key management method further includes: generating an account access code for the target user account based on the account access key; and sending the account access code to the server and storing it in the second user communication key container. The container initialization includes: requesting the server to obtain the account access seed and the account access code in the second user communication key container; and generating the account access key using the user private identification code input locally and the account access seed obtained from the server, so as to create a first user communication key container on the local machine containing the account access key and the account access code generated locally based on the account access key for the target user account. The container update further includes: regenerating the account access code for the target user account using the updated account access key, so as to replace the existing account access code in the first user communication key container configured on the local machine with the regenerated account access code; and sending the regenerated account access code to the server to cause the server to update the account access code stored in the second user communication key container, and allowing: any client logging into the target user account to perform the container initialization on the local machine using the account access seed obtained from the server: using the consistency check of the account access code on the local machine and the server to detect whether the second user communication key container has become invalid due to the update of the user private identification code, and the container initialization on the local machine is enabled only if the second user communication key container is determined to be valid. Alternatively, when any client logged into the target user account obtains the shadow negotiation communication key from the server: using the consistency check of the account access code on the local machine and the server, it checks whether the first user communication key container configured on the local machine has become invalid due to the update of the user's private identification code, and the shadow negotiation communication key obtained from the server is considered valid if the first user communication key container configured on the local machine is determined to be valid; wherein, the first user communication key container configured in any client is destroyed in response to the failure of the consistency check, and the container update of the second user communication key container is allowed to be performed if the same account access code before the update is stored in the first user communication key container of the client that initiated the container update and the second user communication key container of the server; The key management method further includes: storing the shadow negotiation communication key generated locally or obtained locally from the server into the first user communication key container configured locally; wherein, the shadow negotiation communication key in the first user communication key container configured by any client and the second user communication key container of the server are subject to key updates in response to the renegotiation of the user negotiation communication key by the target user account and the peer user account; and the key update of the shadow negotiation communication key in the second user communication key container is allowed to be performed if the same account access code is stored in the first user communication key container of the client initiating the key update and the second user communication key container of the server.

11. The key management method according to claim 9, characterized in that, The server is configured to: assign container version numbers to the first user communication key container and the second user communication key container, and update the container version numbers in response to each container update of the first user communication key container and the second user communication key container, and send a container reinitialization notification carrying the updated container version number to each client configured with the first user communication key container. The container version number is stored in the first user communication key container and the second user communication key container, such that: Any client logged into the target user account responds to the new version of the container version number in the received container reinitialization notification compared to the existing container version number in the first user communication key container configured on the local machine, and re-executes the container initialization on the first user communication key container configured on the local machine.

12. The key management method according to claim 1, characterized in that, The first user communication key container configured on any client is destroyed in response to the target user account logging out of the client; and / or, The server is configured to, in response to a container destruction request initiated by the management control platform for the target user account, perform a destruction operation on the second user communication key container, and send a container destruction notification for the target user account to each client configured with the first user communication key container, so that: In response to the received container destruction notification, any client performs a destruction operation on the first user communication key container configured on its local machine.

13. A key management method for secure communication, characterized in that, The key management method is applied to an online client currently logged into a target user account. The online client is configured with a first user communication key container created for the target user account. The first user communication key container includes an account access key generated based on the target user account's private identifier. Furthermore, the key management method includes: Obtain the peer user account identifier of the peer user account that is communicating end-to-end with the target user account; Using the peer user account identifier, a request is made to the server to obtain a shadow negotiation communication key stored in a second user communication key container created for the target user account. This shadow negotiation communication key is generated by any client using the user negotiation communication key negotiated between the target user account and the peer user account, along with the peer user account identifier and the account access key. The user negotiation communication key is reconstructed using the peer user account identifier, the account access key, and the shadow negotiation communication key successfully obtained from the server.

14. A client, characterized in that, The device includes a processor, a communication component, a human-computer interaction component, and a storage medium, wherein the processor is configured to execute the key management method as described in any one of claims 1 to 13, and the storage medium is configured to store the first user communication key container.

15. A data communication system, characterized in that, include: The client as described in claim 14; The server that communicates with the client; as well as A storage device that is communicatively connected to the server, the storage device being used to store the second user communication key container.

16. A non-transitory computer-readable storage medium, characterized in that, The non-transitory computer-readable storage medium stores instructions, which, when executed by a processor, cause the processor to perform the key management method as described in any one of claims 1 to 13.

Images