Key exchange method and device

Abstract

The invention discloses a key exchange method and device, and relates to the field of cloud computing. The method is applied to a first communication party, the first communication party holds a first fixed private key fragment, a server having a cooperative relationship with the first communication party holds a second fixed private key fragment, and the method comprises the following steps: the first communication party receives a first fixed public key and a first temporary public key sent by a second communication party; the first communication party generates a first secret key fragment based on the first fixed public key, the first temporary public key and the first fixed private key fragment; the first communication side sends a key exchange parameter to the server side, wherein the key exchange parameter is related to the first fixed public key and the first temporary public key; the first communication party receives a second key fragment sent by the server, wherein the second key fragment is generated based on the key exchange parameter and a second fixed private key fragment; the first communication party generates a shared key based on the first key fragment and the second key fragment, and the shared key is used for deriving a session key for communication between the first communication party and the second communication party. The method is used for effectively protecting the private key and improving the security.

Description

[0001] This application claims the priority of a Chinese patent application with the application number 202311704027.4 and the application title "A Method, Device and Other Equipment for Data Processing" filed with the China National Intellectual Property Administration on December 12, 2023, the entire content of which is incorporated herein by reference. Technical Field

[0002] This application relates to the field of cloud computing, and in particular, to a key exchange method and device. Background Art

[0003] The domestic cryptographic algorithms recognized by the State Cryptography Administration (i.e., national cryptography) mainly include algorithms such as SM2, SM3, SM4, and SM9. Among them, the SM2 algorithm is an elliptic curve public key cryptography algorithm. The key exchange protocol and its process of the SM2 algorithm can be used in commercial cryptographic applications to satisfy the process of two or optionally three information transmissions between two communication parties, and calculate and obtain a shared secret key (session key) jointly determined by both parties.

[0004] When performing key exchange, the fixed private key of the initiator (or responder) participates in the calculation of key exchange. Once controlled by an attacker, the attacker can crack the session message of this time, thus causing great risks. Therefore, how to securely store and use the private key is a very important issue. Summary of the Invention

[0005] This application provides a key exchange method and device for effectively protecting the private key and enhancing security.

[0006] To achieve the above object, the following technical solutions are adopted in this application.

[0007] In a first aspect, an embodiment of this application provides a key exchange method. This method is applied to a first communication party. The first communication party holds a first fixed private key shard, and a server having a cooperative relationship with the first communication party holds a second fixed private key shard. The method includes: the first communication party receives a first fixed public key and a first temporary public key sent by a second communication party; the first communication party generates a first key shard based on the first fixed public key, the first temporary public key, and the first fixed private key shard; the first communication party sends key exchange parameters to the server, and the key exchange parameters are related to the first fixed public key and the first temporary public key; the first communication party receives a second key shard sent by the server, and the second key shard is generated based on the key exchange parameters and the second fixed private key shard; the first communication party generates a shared key based on the first key shard and the second key shard, and the shared key is used to derive a session key for communication between the first communication party and the second communication party.

[0008] In the above method, the fixed private key of the first communication party is not stored in a single device, but is split into two parts: the first fixed private key shard and the second fixed private key shard. Among them, the first fixed private key shard is held by the first communication party, and the second fixed private key shard is held by the server. Even if an attacker attacks either the first communication party or the server, it is difficult to recover the complete fixed private key, which can greatly ensure the security of private key storage. In addition, during the key exchange process, the first communication party generates a first key shard based on the first fixed private key shard it holds, and receives a second key shard generated by the server based on the second fixed private key shard. This means that when determining the shared key, the first communication party does not need to expose the complete private key, but generates the complete shared key through cooperation with the server. During the entire process, neither of the cooperating parties can obtain the fixed private key shard of the other party, and when the fixed private key shard participates in the calculation, the complete private key does not appear on either side, thus effectively ensuring the security of the private key during use. It can be seen that the key exchange method provided in the embodiments of the present application can effectively protect the private key and improve security.

[0009] In one implementation, the method further includes: the first communication party generates a first random number; the first communication party receives a second random number sent by the server; the first communication party generates the first fixed private key shard based on the first random number and the second random number.

[0010] In the above implementation, the first fixed private key shard of the first communication party is generated through cooperation with the server, that is, it requires both the random number generated by the first communication party and the random number generated by the server, rather than being determined by a single device alone. This private key generation method is more random and more difficult to be restored by other illegal users, thus more effectively ensuring the security of the first fixed private key shard.

[0011] In one implementation, the first communication party generates the first key shard based on the first fixed public key, the first temporary public key, and the first fixed private key shard, including: the first communication party generates a combined temporary private key based on the first fixed private key shard and the second temporary public key, and the second temporary public key is generated based on the target temporary private key generated by the random number generator; the first communication party verifies the first temporary public key; when the first communication party determines that the verification is successful, it generates a combined temporary public key based on the first temporary public key and the first fixed public key; the first communication party generates the first key shard based on the combined temporary public key and the combined temporary private key.

[0012] In the above implementation manner, it more clearly describes how to generate the first key shard. The entire process only needs to use the first fixed private key shard held by itself, without exposing the complete fixed private key of the first communication party, nor obtaining the other part of the fixed private key shard of the first communication party held by the server, thus effectively ensuring the security of the private key during use.

[0013] In one implementation manner, the key exchange parameters include a first ephemeral public key and a first fixed public key, or the key exchange parameters include a combined ephemeral public key, which is generated based on the first ephemeral public key and the first fixed public key.

[0014] In the above implementation manner, there are two cases for the key exchange parameters: In the first case, when the first communication party receives the first ephemeral public key and the first fixed public key sent by the second communication party, it does not need to wait for the first communication party to generate the first key shard, but can directly send the first ephemeral public key and the first fixed public key to the server, thereby enabling the server and the first communication party to calculate two key shards in parallel, greatly saving the generation time of the key shards, and thus improving the generation efficiency of the shared key. In the second case, when the first communication party receives the determination of the first key shard by the second communication party, it needs to calculate the first ephemeral public key and the first fixed public key to obtain the combined ephemeral public key. This combined ephemeral public key is also the parameter required by the server when generating the second key shard. Therefore, the first communication party can directly send the already calculated combined ephemeral public key to the server without the server having to recalculate, saving the server's computing resources.

[0015] In one implementation manner, the key exchange parameters further include an index identifier, which is used to indicate the correspondence between the first fixed private key shard and the second fixed private key shard.

[0016] In the above implementation manner, when the number of fixed private key shards held by the server is too large, the second fixed private key shard corresponding to the first fixed private key shard can be quickly and accurately found through the index identifier.

[0017] In one implementation manner, the first communication party and the second communication party communicate through the Transport Layer Security (TLS) protocol.

[0018] The above implementation manner means that this key exchange method of the embodiments of the present application can be used in the TLS protocol, thereby effectively ensuring the security of the fixed private key of the first communication party in the TLS scenario.

[0019] In one implementation manner, the first fixed private key shard and the second fixed private key shard form the fixed private key of the first communication party.

[0020] In the above implementation manner, the fixed private key of the first communication party is split into a first fixed private key shard and a second fixed private key shard. This solution for protecting the private key by using private key shards does not require reliance on hardware devices, is easier to deploy, and does not require excessive costs.

[0021] In a second aspect, an embodiment of the present application provides a key exchange method, which is applied to a server. The server holds fixed private key shards respectively corresponding to N communication parties, where N is a positive integer. The N communication parties include a first communication party, and the first communication party holds a first fixed private key shard. The method includes: the server receives a key exchange parameter sent by the first communication party, and the key exchange parameter is related to a first fixed public key and a first temporary public key; the server determines a second fixed private key shard corresponding to the first fixed private key shard from the N fixed private key shards; the server generates a second key shard based on the second fixed private key shard and the key exchange parameter; the server sends the second key shard to the first communication party.

[0022] In the above implementation manner, the server can hold fixed private key shards respectively corresponding to N communication parties, which means that the fixed private keys of the N communication parties are not stored in a separate device, thereby effectively ensuring the fixed private keys of multiple communication parties and further enhancing security. Taking the first communication party among the N communication parties as an example, the fixed private key of the first communication party is split into two parts: a first fixed private key shard and a second fixed private key shard. Among them, the first fixed private key shard is held by the first communication party, and the second fixed private key shard is held by the server. Even if an attacker attacks either the first communication party or the server, it is difficult to recover the complete fixed private key, which can greatly ensure the security of the storage of the fixed private key of the first communication party. In addition, during the key exchange process, the server generates a second key shard based on the second fixed private key shard and the received key exchange parameter. The entire process does not expose the complete private key, nor does it need to obtain the first fixed private key shard held by the first communication party. The complete private key does not appear on any party, thereby effectively ensuring the security of the private key during use. It can be seen that the key exchange method provided by the embodiment of the present application can effectively protect the private key and enhance security.

[0023] In one implementation manner, the method further includes: the server generates a third random number; the server receives a fourth random number sent by the first communication party; the server generates a second fixed private key shard based on the third random number and the fourth random number.

[0024] In the above implementation method, the second fixed private key shard is generated by the server in cooperation with the first communication party, that is, it requires both the random number generated by the first communication party and the random number generated by the server, rather than being determined by a single device alone. This private key generation method is more random and more difficult to be restored by other illegal users, thus more effectively ensuring the security of the second fixed private key shard.

[0025] In one implementation method, the key exchange parameters include a first temporary public key and a first fixed public key, or the key exchange parameters include a combined temporary public key, and the combined temporary public key is generated based on the first temporary public key and the first fixed public key.

[0026] In the above implementation method, there are two cases for the key exchange parameters: In the first case, when the key exchange parameters include the first temporary public key and the second fixed public key, the server can directly determine the second key shard based on the first temporary public key and the second fixed public key, that is, without waiting for the first communication party to generate the first key shard, thereby enabling the server and the first communication party to calculate the two key shards in parallel, greatly saving the generation time of the key shards, and further improving the generation efficiency of the second key shard. In the second case, when the key exchange parameters include the combined temporary public key, the server can directly determine the second key shard based on the combined temporary public key, reducing the time spent on calculating the combined temporary public key and saving the computing resources of the server.

[0027] In one implementation method, the key exchange parameters further include an index identifier, and the index identifier is used to indicate the corresponding relationship between the first fixed private key shard and the second fixed private key shard.

[0028] In the above implementation method, when the number of fixed private key shards held by the server is excessive, the second fixed private key shard corresponding to the first fixed private key shard can be quickly and accurately found through the index identifier.

[0029] In one implementation method, the second fixed private key shard and the first fixed private key shard form the fixed private key of the first communication party.

[0030] In the above implementation method, splitting the fixed private key of the first communication party into the first fixed private key shard and the second fixed private key shard. This solution for protecting the private key by using private key shards does not require relying on hardware devices, is easier to deploy, and does not require excessive costs.

[0031] In a third aspect, an embodiment of the present application provides a key exchange device for implementing the method in the foregoing first aspect or any implementation manner of the first aspect. Specifically, the device includes: a transceiver module, configured to receive a first fixed public key and a first ephemeral public key sent by a second communication party, where a first fixed private key shard is held by the first communication party, and a second fixed private key shard is held by a server having a cooperative relationship with the first communication party; a processing module, configured to generate a first key shard for the first communication party based on the first fixed public key, the first ephemeral public key, and the first fixed private key shard; the transceiver module is further configured to send key exchange parameters by the first communication party to the server, where the key exchange parameters are related to the first fixed public key and the first ephemeral public key; the transceiver module is further configured to receive a second key shard sent by the server, where the second key shard is generated based on the key exchange parameters and the second fixed private key shard; the processing module is further configured to generate a shared key based on the first key shard and the second key shard, and the shared key is used to derive a session key for communication between the first communication party and the second communication party.

[0032] In one implementation manner, the processing module is further configured to generate a first random number; the transceiver module is further configured to receive a second random number sent by the server; the processing module is further configured to generate a first fixed private key shard based on the first random number and the second random number.

[0033] In one implementation manner, the processing module is configured to generate a first key shard for the first communication party based on the first fixed public key, the first ephemeral public key, and the first fixed private key shard, specifically including: the processing module is further configured to generate a combined ephemeral private key based on the first fixed private key shard and a second ephemeral public key, where the second ephemeral public key is generated based on a target ephemeral public key generated by a random number generator; the processing module is further configured to verify the first ephemeral public key; the processing module is further configured to determine that the verification is successful, and generate a combined ephemeral public key based on the first ephemeral public key and the first fixed public key; the processing module is further configured to generate a first key shard based on the combined ephemeral public key and the combined ephemeral private key.

[0034] In one implementation manner, the key exchange parameters include the first ephemeral public key and the first fixed public key, or the key exchange parameters include a combined ephemeral public key, where the combined ephemeral public key is generated based on the first ephemeral public key and the first fixed public key.

[0035] In one implementation manner, the key exchange parameters further include an index identifier, and the index identifier is used to indicate the correspondence between the first fixed private key shard and the second fixed private key shard.

[0036] In one implementation manner, the first communication party and the second communication party communicate through the Transport Layer Security (TLS) protocol.

[0037] In one implementation, the first fixed private key shard and the second fixed private key shard constitute the fixed private key of the first communication party.

[0038] Fourthly, an embodiment of the present application provides a key exchange device for implementing the method in the foregoing second aspect or any implementation manner of the second aspect. Specifically, the device includes: a transceiver module, configured to receive key exchange parameters sent by a first communication party, where the key exchange parameters are related to a first fixed public key and a first temporary public key, and the server holds N fixed private key shards corresponding to N communication parties respectively, N is a positive integer, the N communication parties include the first communication party, and the first communication party holds the first fixed private key shard; a determination module, configured to determine, from the N fixed private key shards, the second fixed private key shard corresponding to the first fixed private key shard; a generation module, configured to generate a second key shard based on the second fixed private key shard and the key exchange parameters; and the transceiver module is further configured to send the second key shard from the server to the first communication party.

[0039] In one implementation, the generation module is further configured to generate a third random number; the transceiver module is further configured to receive a fourth random number sent by the first communication party; and the generation module is further configured to generate, by the server, the second fixed private key shard based on the third random number and the fourth random number.

[0040] In one implementation, the key exchange parameters include a first temporary public key and a first fixed public key, or the key exchange parameters include a combined temporary public key, and the combined temporary public key is generated based on the first temporary public key and the first fixed public key.

[0041] In one implementation, the key exchange parameters further include an index identifier, and the index identifier is used to indicate the correspondence between the first fixed private key shard and the second fixed private key shard.

[0042] In one implementation, the second fixed private key shard and the first fixed private key shard constitute the fixed private key of the first communication party.

[0043] Fifthly, an embodiment of the present application provides a computing device cluster, including at least one computing device, and each computing device includes a processor and a memory. The processors of the at least one computing device are configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the key exchange method in the first aspect or any possible implementation manner of the first aspect.

[0044] Sixthly, an embodiment of the present application provides a computer program product including instructions, which, when run on a computing device cluster, causes the computing device cluster to execute the key exchange method in the first aspect or any possible implementation manner of the first aspect.

[0045] In a seventh aspect, an embodiment of the present application provides a computer-readable storage medium, including computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster executes the key exchange method in the first aspect or any possible implementation manner of the first aspect.

[0046] In an eighth aspect, an embodiment of the present application provides a computing device cluster, including at least one computing device, and each computing device includes a processor and a memory. The processor of at least one computing device is configured to execute instructions stored in the memory of at least one computing device, so that the computing device cluster executes the key exchange method in the second aspect or any possible implementation manner of the second aspect.

[0047] In a ninth aspect, an embodiment of the present application provides a computer program product containing instructions. When the instructions are run by a computing device cluster, the computing device cluster is caused to execute the key exchange method in the second aspect or any possible implementation manner of the second aspect.

[0048] In a tenth aspect, an embodiment of the present application provides a computer-readable storage medium, including computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster executes the key exchange method in the second aspect or any possible implementation manner of the second aspect.

[0049] For the technical effects generated by the above-mentioned second aspect to the tenth aspect and any implementation manner in each aspect, reference may be made to the above-mentioned first aspect and the corresponding implementation manner in the first aspect, and the repeated parts will not be elaborated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Figure 1 FIG. is a schematic structural diagram of a network architecture provided by an embodiment of the present application;

[0051] Figure 2 FIG. is a schematic diagram of a method for collaborative key generation provided by an embodiment of the present application;

[0052] Figure 3 FIG. is a schematic diagram of a method for key exchange provided by an embodiment of the present application;

[0053] Figure 4 FIG. is an interaction schematic diagram of a key exchange method provided by an embodiment of the present application Figure 1 ;

[0054] Figure 5 FIG. is a schematic diagram of a scenario for key exchange based on national cryptography TLS provided by an embodiment of the present application;

[0055] Figure 6 FIG. is a collaboration schematic diagram for key exchange in a national cryptography TLS scenario provided by an embodiment of the present application;

[0056] Figure 7 It is an interaction diagram of a key exchange method provided by an embodiment of the present application Figure 2 ;

[0057] Figure 8 It is a flowchart of a key exchange process provided by an embodiment of the present application Figure 1 ;

[0058] Figure 9 It is a flowchart of a key exchange process provided by an embodiment of the present application Figure 2 ;

[0059] Figure 10 It is a structural diagram of a key exchange device provided by an embodiment of the present application Figure 1 ;

[0060] Figure 11 It is a structural diagram of a key exchange device provided by an embodiment of the present application Figure 2 ;

[0061] Figure 12 It is a structural diagram of a key exchange system provided by an embodiment of the present application;

[0062] Figure 13 It is a structural diagram of a computing device provided by an embodiment of the present application;

[0063] Figure 14 It is a structural diagram of a computing device cluster provided by an embodiment of the present application;

[0064] Figure 15 It is a structural diagram of the connection between computing devices through a network provided by the present application. Detailed implementation manners

[0065] Next, the technical solutions in the embodiments of the present application will be described with reference to the accompanying drawings in the embodiments of the present application. Among them, in order to clearly describe the technical solutions in the embodiments of the present application, in the embodiments of the present application, terms such as "first" and "second" are used to distinguish the same items or similar items with basically the same functions and effects. Those skilled in the art can understand that the terms "first" and "second" do not limit the quantity and execution order, and the terms "first" and "second" do not necessarily limit to be different. At the same time, in the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design solution described as "exemplary" or "for example" in the embodiments of the present application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Exactly speaking, using words such as "exemplary" or "for example" aims to present relevant concepts in a specific way for easy understanding.

[0066] Among them, the relevant parameters (p, a, b, n, G) of the elliptic curve used in the solution described in the embodiments of this application are the relevant regulations in the specification of GM / T 0003-2012 "SM2 Elliptic Curve Public Key Cryptography Algorithm". To facilitate the understanding of the technical solution provided by the embodiments of this application, the relevant parameters of the elliptic curve E involved in the embodiments of this application are introduced first:

[0067] Among them, p is the order of the finite field ; a and b are the parameters of the elliptic curve E: y 2 =x 3 +ax + b; n is the number of points on the elliptic curve E in the finite field ; G is the base point of , with the abscissa xG and the ordinate yG.

[0068] The description of the operation symbols used in the process of the solution described in this application is as follows:

[0069] (1) If P and Q are points in the elliptic curve point group, then P + Q represents the point addition of the elliptic curve, and [k]P represents the addition of k P points;

[0070] (2) x -1 represents the multiplicative inverse of the integer x modulo n, that is, x -1 *x ≡ 1 mod n;

[0071] (3) The four arithmetic operations of the integers in this application all represent operations modulo n. For example, B + b represents a + b mod n, and a * b represents a * b mod n; the symbol || represents the concatenation of two strings;

[0072] To facilitate the understanding of the technical solution provided by the embodiments of this application, a brief introduction to the related technologies of the embodiments of this application is given.

[0073] In the current technical solution, the traditional method is to store the private key of the communicating party in a dedicated key hardware for use, such as a hardware cryptographic module. However, the cost of a dedicated hardware cryptographic module is relatively high and it is not easy to deploy. This makes it impossible for the communicating party to rely on the hardware cryptographic module to store the private key and use the private key for key exchange during the encrypted communication process in many cases. A solution is to use a software cryptographic module to store the private key of the communicating party in a permanent storage medium of a local computing device (for example, the hard disk of a personal computer, the built-in memory in a mobile communication terminal), and protect the private key with a key for identity verification (for example, a PIN code). When the communicating party needs to use the private key for key exchange, the software cryptographic module can extract the private key from the permanent storage medium of the communicating party. However, this solution still has the risk of key leakage. For example, an attacker can steal the private key in the permanent storage medium of the signer's local computing device by implanting a Trojan program. In addition, since the private key will exist in plaintext in the memory during the key exchange process, an attacker may steal the private key in the memory through certain attack methods, resulting in the risk of private key leakage when using the private key. Therefore, how to securely store and use the private key without using a hardware cryptographic module is a problem that needs to be solved currently.

[0074] To solve the above problems, the embodiments of the present application provide a new key exchange method. This method can be applied to a first communicating party (for example, an initiator or a responder). The first communicating party holds a first fixed private key shard, and a server having a cooperative relationship with the first communicating party holds a second fixed private key shard. In this method, the first communicating party can receive a first fixed public key and a first temporary public key sent by a second communicating party, and generate a first key shard based on the first fixed public key, the first temporary public key, and the first fixed private key shard. Further, the first communicating party can send key exchange parameters to the server and receive a second key shard returned by the server (generated based on the key exchange parameters and the second fixed private key shard). Here, the key exchange parameters are related to the first fixed public key and the first temporary public key. Then, the first communicating party can generate a shared key based on the first key shard and the second key shard. Among them, the shared key here can be used to derive a session key for communication between the first communicating party and the second communicating party.

[0075] In the embodiments of the present application, the fixed private key of the first communication party is not stored in a single device, but is split into two parts: the first fixed private key shard and the second fixed private key shard. Among them, the first fixed private key shard is held by the first communication party, and the second fixed private key shard is held by the server. Even if an attacker attacks either the first communication party or the server, it is difficult to recover the complete fixed private key, which can greatly ensure the security of private key storage. In addition, during the key exchange process, the first communication party calculates the first key shard based on the first fixed private key shard it holds, and receives the second key shard calculated by the server based on the second fixed private key shard. This means that when determining the shared key, the first communication party does not need to expose the complete private key, but through cooperation with the server, calculates the complete shared key. During the entire process, neither of the two parties involved in the cooperation can obtain the fixed private key shard of the other party, and when the fixed private key shard participates in the calculation, the complete private key does not appear on either side, thus effectively ensuring the security of the private key during use. It can be seen that the key exchange method provided by the embodiments of the present application can effectively protect the private key and improve security.

[0076] The following introduces the network architecture applying the key exchange method provided by the embodiments of the present application:

[0077] Please refer to Figure 1 , Figure 1 which is a schematic structural diagram of a network architecture provided by the embodiments of the present application. As Figure 1 shown, the network architecture may include a server 100 and a client cluster. The client cluster may include N clients, where N is a positive integer. As Figure 1 shown, the client cluster may specifically include Client A, Client B, Client C,..., Client N. As Figure 1 shown, Client A, Client B, Client C,..., Client N may be respectively connected to the above-mentioned server 100 through a network connection, so that each client can perform data interaction with the server 100 through this network connection. Among them, the network connection here does not limit the connection method, and it can be directly or indirectly connected through a wired communication method, or directly or indirectly connected through a wireless communication method, or through other methods, which are not limited in the present application.

[0078] Among them, each client in the client cluster can have a cooperative relationship with the server 100, and each of these clients may include: intelligent terminals with data processing functions such as smartphones, tablets, laptops, desktop computers, smart speakers, smart watches, vehicle terminals, smart TVs, etc.

[0079] As Figure 1As shown, the server 100 in the embodiments of the present application can be an independent physical server, a server cluster or a distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. Among them, the number of servers in the embodiments of the present application will not be limited.

[0080] It should be understood that in order to effectively ensure the security of the private key storage, the fixed private key of the SM2 encryption certificate in the embodiments of the present application can be split into two parts and stored in the client and server of the password module respectively. Only by collaborating between the two parties can the elliptic curve point sharding (i.e., key sharding) be calculated respectively. In this process, neither of the collaborating parties can obtain the private key shard of the other party.

[0081] For ease of understanding, further, please refer to Figure 2 , Figure 2 is a schematic diagram of a method for collaborative key generation provided by the embodiments of the present application. Among them, this method can be jointly executed by the client and the server. Here, the client can be Figure 1 any one of the client clusters shown (for example, client A). Here, the server can be Figure 1 the server 100 shown. This method can specifically include steps S11 - S15 executed by the server, and steps S21 - S25 executed by the client:

[0082] As Figure 2 shown, the client can execute steps S21 - S22 to generate a random number a 1 and a random number b 1 , and based on the random number b 1 , calculate the elliptic curve point B 1 . Among them, a 1 , b 1 ∈Z n .

[0083] Specifically, the specific way for the client to calculate the elliptic curve point B 1 can be seen in the following formula (1):

[0084] B 1 =[b 1 G (1)

[0085] Similarly, the server can also execute steps S11 - S12 to generate a random number a 2 and a random number b 2 , and based on the random number b 2 , calculate the elliptic curve point B 2 . Among them, a 2 , b 2 ∈Z n . Specifically, the server calculates the elliptic curve point B2 The specific method can be seen in the following formula (2):

[0086] B 2 = [b 2 G (2)

[0087] Where Z n refers to the set of non - negative integers smaller than n, that is, Z n = {0, 1, …, (n - 1)}.

[0088] Furthermore, for the client, after the server calculates the elliptic curve point B 2 , the client can execute step S23 to receive the random number a 2 and the elliptic curve point B 2 . Furthermore, the client can execute steps S24 - S25. Based on the random number a 2 and the random number b 1 generated by itself, determine the private key shard d 1 , and based on the random number a 1 , the random number a 2 , the elliptic curve point B 1 and the elliptic curve point B 2 , determine the public key P.

[0089] Specifically, the specific method for the client to determine the private key shard d 1 can be seen in the following formula (3):

[0090] d 1 = a 2 b 1 (3)

[0091] The specific method for the client to determine the public key P can be seen in the following formula (4):

[0092] P = [a 1 B 2 + [a 2 B 1 (4)

[0093] Similarly, for the server, after the client calculates the elliptic curve point B 1 , the server can execute step S13 to receive the random number a 1 and the elliptic curve point B 1 . Furthermore, the server can execute steps S14 - S15. Based on the random number a 1 and the random number b 2 generated by itself, determine the private key shard d 2 , and based on the random number a 1 、random number a2 and the elliptic curve point B 1 and the elliptic curve point B 2 , to determine the public key P.

[0094] Specifically, the specific manner for the server to determine the private key shard d 2 can be seen in the following formula (5):

[0095] d 2 = a 1 b 2 (5)

[0096] The specific manner for the server to determine the public key P can be seen in the following formula (6):

[0097] P = [a 1 B 2 + [a 2 B 1 (6)

[0098] Among them, in the embodiments of the present application, the private key d and the public key P can be referred to as a complete key pair. The specific formula for the private key d can be seen in the following formula (7), and the public key P can be seen in the following formula (8):

[0099] d = d 1 + d 2 = a 2 b 1 + a 1 b 2 (7)

[0100] P = [d]G = [a 1 B 2 + [a 2 B 1 = [a 2 b 1 + a 1 b 2 G (8)

[0101] In other words, the private key shard d 1 and the private key shard d 2 here can form Figure 2 the fixed private key of the client shown (for example, the fixed private key of the SM2 certificate). In the embodiments of the present application, the Figure 2 key generation method shown can be applied in a communication scenario. Among them, the communication scenario here can be a scenario of communicating through various protocols. For example, it can be a scenario of communicating through the Transport Layer Security (TLS) protocol (also known as the TLS communication scenario).

[0102] It can be understood that in a communication scenario, since the private key file of a general SM2 certificate has no extension items, in order to facilitate the subsequent rapid implementation of key exchange, the embodiments of the present application can add an extension field to the private key of the encryption certificate of the national cryptographic double certificate. For example, the SM2 private key in the PKCS8 format is used. Here, the extension field can be the index identifier corresponding to the private key shard, and this index identifier can be used for the corresponding relationship of the private key shards held after the collaboration between a certain client and the server. For example, the private key shard d held by the client 1 The index identifier of the corresponding private key file, and the private key shard d held by the server 2 The index identifier of the corresponding private key file is the same identifier.

[0103] In the key exchange scenario, the embodiments of the present application can refer to the private key shards generated through the collaboration between the server and the client as fixed private key shards, and refer to the public keys generated through the collaboration between the server and the client as fixed public keys. Due to the above Figure 1 Each client in the client cluster shown has a collaborative relationship with the server 100. Therefore, when the server 100 collaborates with each of the N clients respectively, the server 100 can hold the fixed private key shards corresponding to these N clients respectively. For the convenience of understanding, further, please refer to Table 1. Table 1 is a relationship mapping table related to the fixed private key shards provided by the embodiments of the present application. As shown in Table 1:

[0104] Table 1

[0105] Fixed public key Fixed private key shard Index identifier <![CDATA[Public key P A > <![CDATA[Private key shard d A2 > Index identifier A <![CDATA[Public key P B > <![CDATA[Private key shard d B2 > Index identifier B … … … <![CDATA[Public key P N > <![CDATA[Private key shard d N2 > Index identifier N

[0106] Among them, the public key P A Can be used to represent the fixed public key generated when the client A collaborates with the server 100. When other clients communicate with the client A, this public key P A Can participate in the key exchange calculation; the private key shard d A2 Can be used to represent a part of the fixed private key shards held by the server 100 after collaborating with the client A, and the index identifier A can be used to indicate the correspondence between the private key shard d A2 And another part of the fixed private key shards held by the client A (for example, the private key shard d A1 ).

[0107] Similarly, the public key P B Can be used to represent the fixed public key generated when the client B collaborates with the server 100. When other clients communicate with the client B, this public key P B Can participate in the key exchange calculation; the private key shard d B2It can be used to represent a part of the fixed private key shard held by the server 100 after cooperation with the client B, and the index identifier B can be used to indicate the private key shard d B2 The corresponding relationship with another part of the fixed private key shard held by the client B (for example, the private key shard d B1 ).

[0108] And so on. It should be noted that the items shown in Table 1 are only a reference form. In actual business scenarios, other items (such as the terminal identifier of the client, etc.) can also be established according to needs. The specific form of Table 1 in this embodiment of the application is not limited.

[0109] For ease of understanding, further, please refer to Figure 3 , Figure 3 which is a schematic diagram of a key exchange method provided by an embodiment of the present application. As Figure 3 shown, this method can be jointly executed by the initiator, the responder, and the server. Among them, the responder here can be any one of the clients shown above Figure 1 (for example, the client B), the initiator can be another client communicating with the client B (for example, the client A), and the server can be the server 100 shown above Figure 1 . This method can specifically include steps S301 - S312:

[0110] As Figure 3 shown, the client A can generate a random number r A locally based on a random number generator. Among them, the random number generator here can be a random number generator approved by the State Cryptography Administration. For ease of description, in this embodiment of the present application, the random number generated by the random number generator during the key exchange process can be called a temporary private key. Then, the client A can execute steps S301 - S302, and based on the random number r A , determine the temporary public key R A , and send the temporary public key R A and the fixed public key P A to the client B. Among them, when the client A and the client B communicate through the TLS protocol, the fixed public key P A here can refer to the public key of the SM2 encryption certificate.

[0111] Specifically, the specific manner for the client A to determine the temporary public key R A can be seen in the following formula (9):

[0112] R A =[r A G=(x 1 ,y 1 ) (9)

[0113] where r A ∈Z n , and G is the base point of the SM2 elliptic curve system parameters.

[0114] It can be understood that the client B holds the fixed public key P B and the fixed private key shard d B1 , while the server holds another fixed private key shard corresponding to the client B (for example, the fixed private key shard d B2 ).

[0115] Similarly, the client B can also generate a random number r B (i.e., the temporary private key of the client B) based on the random number generator, and then can execute steps S303 - S304 to determine the combined temporary private key t B .

[0116] Specifically, the specific method for the client B to determine the combined temporary private key t B can be seen in the following formulas (10) - (12):

[0117] R B =[r B G=(x 2 ,y 2 ) (10)

[0118]

[0119]

[0120] where R B refers to the temporary public key determined by the client B based on the random number r B , r B ∈Z n ; x 2 refers to the field element extracted from the temporary public key R B ; refers to the element obtained after converting the data type of the field element x 2 to an integer (i.e., the integer field element corresponding to the temporary public key R B ); d B1 is the fixed private key shard held by the client B.

[0121] Furthermore, after the client B receives the temporary public key R A and the fixed public key P A sent by the client A, it can execute step S305 to verify whether the temporary public key R A satisfies the curve equation. If the temporary public key R AIf the curve equation is not satisfied, the negotiation fails. If the ephemeral public key R A satisfies the curve equation, it can be determined that the verification is successful. At this time, the client B can execute steps S306 - S308, that is, first based on the ephemeral public key R A and the fixed public key P A , determine the combined ephemeral public key K A , then based on the combined ephemeral private key t B and the combined ephemeral public key K A , determine the elliptic curve point shard V 1 , and send the key exchange parameter to the server. Among them, the key exchange parameter here can include the combined ephemeral public key K A , or the key exchange parameter includes the ephemeral public key R A and the fixed public key P A .

[0122] Specifically, the specific method for the client B to determine the elliptic curve point shard V 1 can refer to the following formulas (13) - (15):

[0123]

[0124]

[0125]

[0126] where x 1 refers to the field element extracted from the ephemeral public key R A ; refers to the element obtained after converting the data type of the field element x 1 to an integer (i.e., the integer field element corresponding to the ephemeral public key R A ); h is the cofactor of the SM2 elliptic curve system parameter (for example, 1).

[0127] After receiving the key exchange parameter, the server can execute steps S309 - S310, that is, based on the fixed private key shard d B2 and the key exchange parameter, determine the elliptic curve point shard V 2 , and send the elliptic curve point shard V 2 to the client B.

[0128] Specifically, the specific method for the server to determine the elliptic curve point shard V 2 can refer to the following formula (16):

[0129]

[0130] At this time, the client B can execute steps S311 - S312, that is, first based on the elliptic curve point shard V1 and the elliptic curve point shard V 2 , determine the complete elliptic curve point V, and then derive the session key according to the elliptic curve point V.

[0131] Specifically, the specific method for the client B to determine the complete elliptic curve point can be seen in the following formula (17):

[0132] V = V 1 + V 2 = (x v , y v ) (17)

[0133] It can be seen that in the embodiment of the present application, in order to effectively ensure the security of the private key, the fixed private key of the SM2 encryption certificate in the embodiment of the present application can be split into two parts and stored in the client B and the server of the password module respectively. Only by collaborating with both parties can the elliptic curve point shards (i.e., key shards) be calculated respectively. In this process, neither party in the collaboration can obtain the private key shard information of the other party.

[0134] Further, please refer to Figure 4 , Figure 4 which is an interaction schematic diagram of a key exchange method provided by the embodiment of the present application. Figure 1 . As Figure 4 shown, this method can be jointly executed by the first communication party, the second communication party and the server. Among them, the server here can be the server shown above Figure 3 . The first communication party (for example, the client B shown above Figure 3 ) having a collaborative relationship with the server holds the first fixed private key shard. The second communication party here (for example, the client A shown above Figure 3 ) can communicate with the first communication party. This method can at least include steps S401 - S407:

[0135] Step S401, the first communication party receives the first fixed public key and the first temporary public key sent by the second communication party.

[0136] Among them, the first communication party in the embodiment of the present application can be the initiator or the responder. For the convenience of description, the first communication party can be taken as the responder in the following, and the second communication party can be taken as the initiator. When the second communication party is the initiator (for example, the client A) shown above Figure 3 , the first fixed public key here can be represented by the fixed public key P A , and the first temporary public key can be represented by the temporary public key R A . The temporary public key R A is generated based on the temporary private key generated by the random number generator (for example, the random number r A ).

[0137] When communicating between a first communication party and a second communication party via the Transport Layer Security (TLS) protocol, the first communication party here can be referred to as the TLS responder, and the second communication party can be referred to as the TLS initiator.

[0138] It should be understood that before the second communication party initiates a connection, it has prepared a fixed public-private key pair composed of a first fixed public key. If the second communication party is also a client having a collaborative relationship with the server, the fixed public-private key pair here can be generated by using the key generation method shown above Figure 2 If the second communication party has no collaborative relationship with the server, the fixed public-private key pair here can also be issued by a certificate authority. Of course, the fixed public-private key pair may also be generated by using other key generation methods, which will not be limited here.

[0139] Exemplarily, when the second communication party wants to communicate with the first communication party, the second communication party can use a random number generator to generate a random number r A . Among them, in the embodiments of the present application, the random number r generated by the second communication party during the key exchange process A can be referred to as the first temporary private key. Further, the second communication party can refer to the above formula (9) to perform a scalar point multiplication operation on the first temporary private key and the base point of the SM2 elliptic curve system parameters to obtain the first temporary public key. Then, the second communication party initiates a TLS connection request (i.e., an encrypted communication request) and sends the first fixed public key and the first temporary public key to the first communication party. For example, the second communication party can preferentially use the ECDHE-SM4-SM3 algorithm suite to send the fixed public key P A and the temporary public key R A .

[0140] Step S402, the first communication party generates a first key shard based on the first fixed public key, the first temporary public key, and the first fixed private key shard.

[0141] Among them, when the first communication party is the responder shown above Figure 3 (for example, client B), the first fixed private key shard here is the fixed private key shard d B1Representation. Specifically, the first communication party can generate a combined temporary private key based on the first fixed private key shard and the second temporary public key, where the second temporary public key is generated based on the target temporary private key generated by a random number generator. Further, when the first communication party receives the first fixed public key and the first temporary public key, it can verify the first temporary public key. If the first communication party determines that the verification is successful (i.e., the first temporary public key satisfies the curve equation), it can generate a combined temporary public key based on the first temporary public key and the first fixed public key, and then generate the first key shard based on the combined temporary public key and the combined temporary private key.

[0142] Exemplarily, the first communication party can use a random number generator to generate a random number r B . Among them, in the embodiments of the present application, the random number r generated by the first communication party during the key exchange process B is called the second temporary private key (i.e., the target temporary private key). Further, the first communication party can refer to the above formula (10) to perform a scalar point multiplication operation on the second temporary private key and the base point of the SM2 elliptic curve system parameters, so as to obtain the second temporary public key (for example, the temporary public key R B ). Then, the first communication party can refer to the above formula (11) to extract the first field element (for example, x 2 ) from the second temporary public key, and convert the data type of the first field element to an integer to obtain the integer field element corresponding to the second temporary public key. Further, the first communication party can refer to the above formula (12) to determine the scalar multiplication result of the integer field element corresponding to the second temporary public key and the second temporary private key, and add the scalar multiplication result to the first fixed private key shard (for example, the fixed private key shard d B1 ) to obtain the combined temporary private key (for example, the combined temporary private key t B ).

[0143] When the first communication party determines that the first temporary public key (for example, the temporary public key R A ) satisfies the curve equation, the first communication party can refer to the above formula (13) to extract the second field element (for example, x 1 ) from the first temporary public key, and convert the data type of the second field element to an integer to obtain the integer field element corresponding to the first temporary public key. Then, the first communication party can refer to the above formula (14) to determine the scalar point multiplication result of the integer field element corresponding to the first temporary public key and the first temporary public key, and then add the scalar point multiplication result to the first fixed public key (for example, the fixed public key P A ) to obtain the combined temporary public key (for example, the combined temporary public key K A)。Furthermore, the first communicating party can refer to the above formula (15) to determine the scalar multiplication result of the combined temporary private key and the cofactor of the SM2 elliptic curve system parameters, and then can generate the first key shard based on the scalar multiplication result and the combined temporary public key (for example, the above elliptic curve point shard V 1 )。

[0144] Step S403, the first communicating party sends key exchange parameters to the server.

[0145] Among them, the server here can hold the fixed key shards corresponding to N communicating parties respectively, and these N communicating parties include the first communicating party, where N is a positive integer. When N = 1, the key exchange parameter here can be the first fixed public key and the first temporary public key. Of course, in order to save the computing resources of the server, the key exchange parameter can also be the combined temporary public key, which is determined by the first communicating party referring to the above formulas (13)-(14); when N is a positive integer greater than 1, the key exchange parameter here can be the first fixed public key, the first temporary public key, and the index identifier, or the combined temporary public key and the index identifier. The key exchange parameter will not be limited here. The index identifier here can be used to indicate the correspondence between the first fixed key shard and the fixed key shard corresponding to the first communicating party held by the server (i.e., the second fixed key shard).

[0146] Among them, the index identifier here can be included in the private key file corresponding to the first fixed key shard. For example, the private key file corresponding to the first fixed key shard includes an extended field, and the extended field here includes the index identifier. It can be understood that since the fixed private key of the first communicating party is split into two parts, when the first communicating party determines the session key with the second communicating party, it needs to send the key exchange parameter for coordination to the server so that the server can generate the second key shard.

[0147] Step S404, the server determines the second fixed key shard corresponding to the first fixed key shard from the N fixed key shards.

[0148] Specifically, since the server holds the fixed key shards corresponding to N clients respectively, when the server receives the key exchange parameters sent by the first communicating party, it can determine the fixed key shard that matches the index identifier from the N fixed key shards, and then can determine the determined fixed key shard as the second fixed key shard.

[0149] It can be understood that the private key file corresponding to the second fixed key shard can also include an extended field, and the extended field includes the index identifier. For example, when the first communicating party is client B, the first fixed key shard held by the first communicating party (for example, the fixed key shard d B1)The corresponding index identifier is the same as the second fixed private key shard held by the server (e.g., the fixed private key shard d B2 )That is, it can be the index identifier B shown in Table 1 above.

[0150] Step S405: The server generates a second key shard based on the second fixed private key shard and the key exchange parameter.

[0151] Specifically, if the key exchange parameter received by the server includes the first fixed public key and the first temporary public key, the server can refer to the above formula (16), first extract the second field element (e.g., x 1 ) from the first temporary public key, and convert the data type of the second field element to an integer to obtain the integer field element corresponding to the first temporary public key. Then, the server can determine the scalar dot product result of the integer field element corresponding to the first temporary public key and the first temporary public key, and further add the scalar dot product result to the first fixed public key (e.g., the fixed public key P A ) to obtain a combined temporary public key (e.g., the combined temporary public key K A ). Further, the server can determine the scalar multiplication result of the second fixed private key shard and the cofactor of the SM2 elliptic curve system parameters, and then generate a second key shard (e.g., the elliptic curve point shard V 2 ) based on the scalar multiplication result and the combined temporary public key.

[0152] Optionally, if the key exchange parameter received by the server includes the combined temporary public key, the server can refer to the above formula (16) to more quickly determine the second key shard based on the second fixed private key shard and the combined temporary public key, which not only saves the computing resources consumed by calculating the combined temporary public key but also improves the computing efficiency of the second key shard, so as to more quickly determine the shared key subsequently.

[0153] Step S406: The server sends the second key shard to the first communication party.

[0154] Step S407: The first communication party generates a shared key based on the first key shard and the second key shard.

[0155] Specifically, the first communication party can refer to the above formula (17) to add the first key shard and the second key shard to obtain a shared key (e.g., the complete elliptic curve point V). The shared key is used to derive the session key between the first communication party and the second communication party. The key derivation algorithm here is the key derivation algorithm specified by the SM2 public key cryptography algorithm, which will not be elaborated in this application.

[0156] It is understandable that the embodiments of the present application can be well adapted to the national secret TLS algorithm suite, that is, the ECDHE algorithm in the national secret TLS algorithm suite ECDHE-SM4-SM3 can be replaced with the above key exchange algorithm to enhance the protection of the private key in the national secret encryption and decryption certificate, thereby effectively improving security.

[0157] The following takes the TLS server as an example to illustrate the collaborative national secret TLS solution. For a TLS connection, since the cofactor and integer domain elements of the SM2 elliptic curve system parameters are both fixed constants, for the convenience of description, the cofactor and integer domain elements are omitted in the embodiments of the present application. For better understanding, further, please refer to Figure 5 , Figure 5 which is a schematic diagram of a scenario of key exchange based on national secret TLS provided by the embodiments of the present application. As Figure 5 shown, the TLS initiator (taking client B as an example) here can be the above-mentioned second communication party, and the TLS responder (taking client A as an example) can be the above-mentioned first communication party. Among them, the TLS initiator can hold a fixed private key d A and a fixed public key P A (i.e., the first fixed public key); the TLS responder can hold a fixed private key shard d B1 (i.e., the first fixed private key shard) and a fixed public key P B (i.e., the second fixed public key); the server can hold the fixed private key shard d B2 corresponding to the TLS responder (i.e., the second fixed private key shard).

[0158] As Figure 5 shown, the TLS initiator can refer to the above formula (9) to generate a temporary private key r A and a temporary public key R A ; while the TLS responder can refer to the above formula (10) to generate a temporary private key r B and a temporary public key R B .

[0159] Among them, when the TLS initiator communicates with the TLS responder over TLS, the TLS initiator can send the fixed public key P A and the temporary public key R A to the TLS responder so that the TLS responder can determine the shared key V through cooperation with the server.

[0160] It is understandable that when the TLS responder receives the fixed public key P A and the temporary public key R A sent by the TLS initiator, it can determine the key shard V 1 . Specifically, the TLS responder (for example, client B) determines the key shard V 1The specific method can be seen in the following formula (18):

[0161] V 1 = [d B1 ·r B (P A + R A ) (18)

[0162] Then, the TLS responder can send a key exchange request to the server and send the fixed public key P A of the TLS initiator and the ephemeral public key R A . After the server receives the fixed public key P A and the ephemeral public key R A , it can determine the key shard V 2 . Specifically, the specific method for the server to determine the second key shard V 2 can be seen in the following formula (19):

[0163] V 2 = [d B2 (P A + R A ) (19)

[0164] Furthermore, when the TLS responder receives the key shard V 2 returned by the server, it can determine the shared key V based on the key shard V 1 and the key shard V 2 , and derive the session key between the TLS initiator and the TLS responder based on the shared key V. Among them, the specific method for the TLS responder to determine the shared key V can be seen in the following formula (20):

[0165] V = V 1 + V 2 = [d B1 + d B2 + r B (P A + R A ) (20)

[0166] Since the key exchange protocol is that two communicating parties (i.e., the TLS initiator and the TLS responder) pass the information interactively, use their respective private keys and the public keys of the other party to agree on a secret key known only to themselves. Based on this, the TLS responder also needs to send the fixed public key P B and the ephemeral public key R B to the TLS initiator., so that the TLS initiator can determine the shared key U, and derive the session key between the TLS initiator and the TLS responder according to the shared key U. The specific method for the TLS initiator to determine the shared key U can be seen in the following formula (21):

[0167] U = [d A + r A (P B + R B ) (21)

[0168] It can be seen that in the embodiment of the present application, without relying on hardware devices, the private key of the SM2 encryption certificate is stored separately in the first communication party (i.e., the TLS responder) and the server in fragments. Therefore, an attacker cannot recover the complete private key by obtaining only one end of the private key, which can effectively ensure the security of the private key storage. During the key exchange calculation process, the complete private key does not appear at any end. The first communication party and the server calculate through their respective fixed private key fragments, enabling the first communication party to obtain the secret complete elliptic curve point V, thereby effectively ensuring the security of the private key during use.

[0169] Furthermore, the embodiment of the present application also provides a two-party collaborative SM2 key exchange software password module. This module can include a TLS initiator, a TLS responder, and a server to implement the function of SM2 key exchange, thereby effectively ensuring the security of the private key during storage and use. The main usage scenario of this module can be the scenario of using the ECDHE-SM4-SM3 algorithm suite for key exchange in national secret TLS communication.

[0170] For ease of understanding, please refer to Figure 6 , Figure 6 which is a collaborative schematic diagram for key exchange in the national secret TLS scenario provided by the embodiment of the present application. As Figure 6 shown, the TLS initiator here can be the above-mentioned second communication party; the TLS responder can be the above-mentioned first communication party, which is a client having a collaborative relationship with the server.

[0171] It can be understood that the TLS protocol is mainly divided into two layers. The bottom layer is the TLS record protocol, which is mainly responsible for encrypting messages using symmetric cryptography; the upper layer is the TLS handshake protocol, which is mainly divided into 4 parts: the handshake protocol, the cipher spec change protocol, the alert protocol, and the application data protocol. Among them, the handshake protocol is mainly responsible for negotiating the cipher algorithm and the shared key, including certificate authentication; the cipher spec change protocol is responsible for conveying the signal of changing the cipher method to the communication party; the alert protocol is responsible for conveying the error to the other party when an error occurs; the application data protocol is responsible for conveying the application data carried by TLS to the communication party.

[0172] As shown Figure 6 in the figure, the TLS initiator may send a first message (e.g., ClientHello message) to the TLS responder, and the first message may include the client protocol version number, cipher suite, current time, session identifier, etc.

[0173] After receiving the first message, the TLS responder will return a series of messages to the TLS initiator, which may specifically include a second message (e.g., ServerHello message), a third message (e.g., ServerCertificate message), a fourth message (e.g., ServerKeyExchange message), a fifth message (e.g., CertificateRequest message), and an end message (e.g., ServerHelloDone message). Among them, the second message generally may include determining the protocol version number, cipher suite, current time, session identifier, etc.; the third message may include the fixed public key of the TLS responder; the fourth message may include the ephemeral public key of the TLS responder; the fifth message may be used to request the TLS initiator to send a public key certificate; the end message may be an identifier for the end of this message, used to inform the TLS initiator that its message has ended.

[0174] At this time, the TLS initiator may obtain the fixed public key of the TLS responder and the ephemeral public key of the TLS responder, and then may determine the shared key U and derive the session key based on the fixed private key of the TLS initiator, the fixed public key of the TLS responder, and the ephemeral public key of the TLS responder.

[0175] Then, the TLS initiator needs to send a series of messages to the TLS responder, which may specifically include a sixth message (e.g., ClientCertificate message), a digital signature message (e.g., CertificateVerify message), a seventh message (e.g., ClientKeyExchange message), an eighth message (e.g., ChangeCipherSpec message), and a handshake protocol end message (e.g., finished message). Among them, the sixth message may include the fixed public key of the TLS initiator; the digital signature message means that the TLS initiator proves to the TLS responder that it is the holder of the certificate; the seventh message may include the ephemeral public key of the TLS initiator; the eighth message is an identifier for preparing to switch the cipher, which is a message of the cipher spec change protocol, used to indicate that the subsequent messages will be encrypted with the previously negotiated key; the handshake protocol end message means that the TLS initiator tells the TLS responder that the handshake protocol has ended.

[0176] The TLS responder can obtain the static public key of the TLS initiator and the ephemeral public key of the TLS initiator, and then, referring to the above formulas (13)-(15), based on the static private key shard held by the TLS responder (e.g., static private key shard d B1 ), the static public key of the TLS initiator, and the ephemeral public key of the TLS initiator, determine the first key shard. Further, the TLS responder can send the static public key of the TLS initiator and the ephemeral public key of the TLS initiator to the server, so that the server can refer to the above formula (16) and, based on the static private key shard corresponding to the TLS responder held by the server itself (e.g., static private key shard d B2 ), and the two received public keys, determine the second key shard. The server can send this second key to the TLS responder.

[0177] When the TLS responder receives this second key shard, it can refer to the above formula (17) to determine the shared key V and derive the session key. Then, the TLS responder can send the ninth message (e.g., ChangeCipherSpec message) and the handshake protocol end message to the TLS initiator. Among them, this ninth message is the same as the above eighth message, both are identifiers for preparing to switch the cipher, and are messages of the cipher spec change protocol, used to indicate that the subsequent messages will be encrypted with the previously negotiated key; the handshake protocol end message means that the TLS responder tells the TLS initiator that the handshake protocol has ended. This means switching to the application data protocol.

[0178] At this time, both the TLS initiator and the TLS responder can encrypt the application messages to be transmitted according to the session keys they derived, thus effectively ensuring the security of data transmission.

[0179] In another alternative embodiment, the second communication party here can also be a client having a cooperative relationship with the server. For the sake of distinction, the embodiment of the present application can refer to the server having a cooperative relationship with the second communication party as the second server, and the server having a cooperative relationship with the first communication party as the first server. Among them, the first server and the second server here can be the same or different, and no limitation will be made here.

[0180] When the first server and the second server are the same (e.g., both are the server 100 shown in Figure 1 ), both the second communication party and the first communication party belong to the N clients corresponding to the server 100; when the first server and the second server are different, the first communication party is any one of the N clients corresponding to the first server, and the second communication party is any one of the M clients corresponding to the second server, where N and M here are both positive integers.

[0181] For ease of understanding, please refer to Figure 7 , Figure 7 which is an interaction diagram of a key exchange method provided by an embodiment of the present application Figure 2 . As Figure 7 shown, this method can be jointly executed by a first communication party, a second communication party, a first server, and a second server. Among them, the first server here can hold fixed private key shards corresponding to N communication parties respectively. These N communication parties include the first communication party, and the first communication party holds a first fixed private key shard; while the second server can hold fixed private key shards corresponding to M communication parties respectively, and these M communication parties include the second communication party, and the second communication party holds a third fixed private key shard. This method can at least include steps S701 - S714:

[0182] Step S701, the second communication party sends a first fixed public key and a first temporary public key to the first communication party.

[0183] Among them, when the second communication party is client A, the first fixed public key here can be represented by the fixed public key P A , and the first temporary public key can be represented by the temporary public key R A . This temporary public key R A is generated based on a temporary private key generated by a random number generator (for example, the random number r A ).

[0184] Step S702, the first communication party generates a first key shard based on the first fixed public key, the first temporary public key, and the first fixed private key shard.

[0185] Among them, the first fixed private key shard here can be represented by the fixed private key shard d B1 , and the first key shard here can be an elliptic curve point shard determined by the first communication party based on the above formula (13) (for example, the elliptic curve point shard V 1 ).

[0186] Step S703, the first communication party sends a first key exchange parameter to the first server.

[0187] Among them, the first key exchange parameter here can include the first fixed public key, the first temporary public key, and a first index identifier (for example, the index identifier B). This index identifier B is used to indicate the correspondence between the fixed private key shard d B1 and the fixed private key shard d B2 held by the first server. Optionally, in order to save the computing resources of the first server, the first key exchange parameter here can also include a combined temporary public key K A and the first index identifier, and this will not be limited here.

[0188] Step S704, the first server determines the second fixed private key shard corresponding to the first fixed private key shard from the N fixed private key shards.

[0189] Wherein, the second fixed private key shard here refers to another part of the fixed private key shard of the first communication party held by the first server (for example, the fixed private key shard d B2 ).

[0190] Step S705, the first server generates a second key shard based on the second fixed private key shard and the first key exchange parameter.

[0191] Wherein, the second key shard can be the elliptic curve point shard determined by the first server based on the above formula (16) (for example, the elliptic curve point shard V 2 ).

[0192] Step S706, the first server sends the second key shard to the first communication party.

[0193] Step S707, the first communication party determines the first shared key based on the first key shard and the second key shard.

[0194] Wherein, the first shared key can be the complete elliptic curve point determined by the first communication party based on the above formula (17) (for example, the elliptic curve point V).

[0195] Wherein, for the specific implementation manners of steps S701 - S707, reference can be made to the descriptions of steps S401 - S407 in the corresponding embodiments above, which will not be elaborated here. Figure 4 The descriptions of steps S401 - S407 in the corresponding embodiments above, which will not be elaborated here.

[0196] Step S708, the first communication party sends the second fixed public key and the second ephemeral public key to the second communication party.

[0197] Wherein, when the first communication party is client B, the first fixed public key here can be represented by the fixed public key P B , and the first ephemeral public key can be represented by the ephemeral public key R B , and the ephemeral public key R B is generated based on the ephemeral private key generated by the random number generator (for example, the random number r B ).

[0198] It can be understood that the second fixed public key here is generated after the first communication party collaborates with the server. For example, the second fixed public key participates in the above formula (4), and is based on the second random number (for example, a 2 ), the fourth random number (for example, a 1 ), the first random public key (for example, B 1 ) and the second random public key (for example, B2 ) determined, the first random public key is determined by the first random number (e.g., b 1 ), the first random number and the fourth random number are generated by the first communication party, the second random public key and the second random number are both sent by the first server, and the second random formula is determined by the third random number (e.g., b 2 ).

[0199] Step S709, the second communication party generates a third key shard based on the second fixed public key, the second temporary public key, and the third fixed private key shard.

[0200] Among them, the third fixed private key shard here refers to the fixed private key shard held by the second communication party (e.g., fixed private key shard d A1 ), and the third key shard can be the elliptic curve point shard (e.g., elliptic curve point shard V 3 ) determined by the second communication party based on the above formulas (13)-(15).

[0201] Step S710, the second communication party sends the second key exchange parameter to the second server.

[0202] Among them, the second key exchange parameter here can include the second fixed public key, the second temporary public key, and the second index identifier (e.g., index identifier A). The index identifier A is used to indicate the correspondence between the fixed private key shard d A1 and the fixed private key shard d A2 held by the second server. Optionally, in order to save the computing resources of the second server, the second key exchange parameter here can also include the combined temporary public key K B and the second index identifier, which will not be limited here.

[0203] Step S711, the second server determines the fourth fixed private key shard corresponding to the third fixed private key shard from the M fixed private key shards.

[0204] Among them, the fourth fixed private key shard refers to another part of the fixed private key shard of the second communication party held by the second server (e.g., fixed private key shard d A2 ).

[0205] Step S712, the second server generates a fourth key shard based on the fourth fixed private key shard and the second key exchange parameter.

[0206] Among them, the fourth key shard can be the elliptic curve point shard (e.g., elliptic curve point shard V 4 ) determined by the second server based on the above formula (16).

[0207] Step S713: The second server sends the fourth key fragment to the second communication party.

[0208] Step S714: The second communication party determines the second shared key based on the third key fragment and the fourth key fragment.

[0209] Here, the second shared key can be the complete elliptic curve point (e.g., elliptic curve point U) determined by the second communication party based on the above formula (17).

[0210] For the specific implementation manners of steps S708 - S714, reference can also be made to the description of steps S401 - S407 in the corresponding embodiments above, which will not be elaborated here. Figure 4 It can be understood that in the embodiments of the present application, the ECDHE algorithm in the national secret TLS algorithm suite ECDHE - SM4 - SM3 can be replaced with a key exchange algorithm to enhance the protection of the private key in the national secret encryption and decryption certificate. It can not only protect the fixed private key of the first communication party (e.g., TLS responder), but also protect the fixed private key of the second communication party (e.g., TLS initiator), thereby effectively improving security.

[0211] Next, from the perspective of a single network device, the method provided in the embodiments of the present application will be introduced with reference to the accompanying drawings.

[0212] Please refer to

[0213] which Figure 8 , Figure 8 is a schematic flowchart of a key exchange method provided in the embodiments of the present application. Figure 1 As Figure 8 shown, this method can be executed by the first communication party (initiator or responder). The first communication party holds the first fixed private key fragment, and the server having a collaborative relationship with the first communication party holds the second fixed private key fragment. The first fixed private key fragment and the second fixed private key fragment together form the fixed private key of the first communication party. This method may at least include steps S801 - S805:

[0214] Step S801: The first communication party receives the first fixed public key and the first ephemeral public key sent by the second communication party.

[0215] Here, the first communication party and the second communication party can communicate through the Transport Layer Security (TLS) protocol.

[0216] Step S802: The first communication party generates the first key fragment based on the first fixed public key, the first ephemeral public key, and the first fixed private key fragment.

[0217] Here, the first fixed private key fragment refers to the fixed private key fragment held by the first communication party (e.g., fixed private key fragment d B1), where the first key shard can be an elliptic curve point shard determined by the first communication party based on the above formula (13) (for example, the elliptic curve point shard V 1 ).

[0218] It can be understood that, in order to effectively ensure the security of private key storage, the embodiments of the present application can split the fixed private key of the SM2 encryption certificate into two parts and store them separately in the first communication party and the server, that is, the first communication party holds the first fixed private key shard, and the server holds the second fixed private key shard. Among them, the first fixed private key shard here is determined by the first random number and the second random number, and the second fixed private key shard is determined by the third random number and the fourth random number. Both the first random number and the fourth random number are generated by the first communication party, while the second random number and the third random number are generated by the server. Exemplarily, in the key generation stage, the first random number can be represented by b 1 and the second random number can be represented by a 2 , the third random number can be b 2 , and the fourth random number can be represented by a 1 .

[0219] Among them, the first communication party can send the third random number to the server, and the server can send the second random number to the first communication party. When the first communication party receives the second random number sent by the server, it can generate the first fixed private key shard based on the first random number and the second random number. For example, the first communication party can refer to the above formula (3) and perform a scalar multiplication operation on the second random number sent by the server and the first random number generated by the first communication party to generate the first fixed private key shard.

[0220] Similarly, when the server receives the fourth random number sent by the first communication party, it can also generate the second fixed private key shard based on the third random number and the fourth random number. For example, the server can refer to the above formula (5) and perform a scalar multiplication operation on the fourth random number sent by the first communication party and the third random number generated by the server to generate the second fixed private key shard.

[0221] In addition, the first communication party can also refer to the above formula (1) and perform a scalar dot multiplication operation on the first random number and the base point parameter in the SM2 system parameters to obtain the first random public key (for example, B 1 ), and send the first random public key and the third random number to the server; the server can refer to the above formula (2) and perform a scalar dot multiplication operation on the fourth random number and the base point parameter in the SM2 system parameters to obtain the second random public key (for example, B 2 ), and send the second random number and the second random public key to the first communication party.

[0222] Further, the first communicating party can refer to the above formula (4) to add the first result (i.e., the result of scalar dot product of the fourth random number and the second random public key) and the second result (i.e., the result of scalar dot product of the second random number and the first random public key) to generate the fixed public key of the communicating party (i.e., the second fixed public key).

[0223] Similarly, the server can refer to the above formula (6) to add the first result (i.e., the result of scalar dot product of the fourth random number and the second random public key) and the second result (i.e., the result of scalar dot product of the second random number and the first random public key) to generate the fixed public key of the first communicating party (i.e., the second fixed public key).

[0224] Step S803: The first communicating party sends key exchange parameters to the server.

[0225] Among them, the key exchange parameters are related to the first fixed public key and the first temporary public key. In the embodiments of the present application, N can be used to represent the number of fixed private key shards held by the server. When N = 1, the key exchange parameters here can be the first fixed public key and the first temporary public key. Of course, in order to save the computing resources of the server, the key exchange parameters can also be the combined temporary public key, which is determined by the first communicating party referring to the above formulas (13)-(14); when N is a positive integer greater than 1, the key exchange parameters here can be the first fixed public key, the first temporary public key, and the index identifier, or the combined temporary public key and the index identifier. The key exchange parameters will not be limited here. The index identifier can be used to indicate the correspondence between the first fixed private key shard and the fixed private key shard of the first communicating party held by the server (i.e., the second fixed private key shard).

[0226] Step S804: The first communicating party receives the second key shard sent by the server.

[0227] Among them, the second key shard here can be the elliptic curve point shard determined by the server referring to the above formula (16) based on the second fixed private key shard and the exchange parameters (for example, the elliptic curve point shard V 2 ). Among them, the second fixed private key shard refers to another part of the fixed private key shard of the first communicating party held by the server (the fixed private key shard d B2 ).

[0228] Step S805: Generate a shared key based on the first key shard and the second key shard.

[0229] Among them, the shared key can be the complete elliptic curve point determined by the first communicating party based on the above formula (17) (for example, the elliptic curve point V), and the shared key is used to derive the session key for communication between the first communicating party and the second communicating party.

[0230] Among them, for the specific implementation manners of steps S801 - S805, reference can be made to the descriptions of steps S401 - S407 in the corresponding embodiments above, which will not be elaborated here. Figure 4

[0231] Furthermore, please refer to Figure 9 , Figure 9 which is a schematic flow for key exchange provided by an embodiment of the present application. Figure 2 As shown in Figure 9 , this method can be executed by a server. The server holds fixed private key shards corresponding to N communication parties respectively, where N is a positive integer. The N communication parties include a first communication party, and the first communication party holds a first fixed private key shard. This method may at least include steps S901 - S904:

[0232] Step S901, the server receives key exchange parameters sent by the first communication party.

[0233] Among them, the key exchange parameters are related to the first fixed public key and the first temporary public key. For example, the key exchange parameters include the first temporary public key and the first fixed public key, or the key exchange parameters include a combined temporary public key, which is generated based on the first temporary public key and the first fixed public key. In addition, the key exchange parameters further include an index identifier, which is used to indicate the correspondence between the first fixed private key shard and the second fixed private key shard. Both the first fixed public key and the first temporary public key are held by a second communication party.

[0234] Step S902, the server determines the second fixed private key shard corresponding to the first fixed private key shard from the N fixed private key shards.

[0235] Among them, the first fixed private key shard and the second fixed private key shard form the fixed private key of the first communication party. That is, the second fixed private key shard here refers to the other part of the fixed private key shard of the first communication party held by the server (for example, the fixed private key shard d B2 ). The second fixed private key shard here is determined by the server referring to the above formula (2) based on the fourth random number (for example, a 1 ) and the third random number (for example, b 2 ). The fourth random number is sent by the first communication party, and the third random number is generated by the server.

[0236] Step S903, the server generates a second key shard based on the second fixed private key shard and the exchange parameters.

[0237] Among them, the second key shard can be an elliptic curve point shard (for example, the elliptic curve point shard V 2 ) determined by the server based on the above formula (16).

[0238] Step S904: The server sends the second key fragment to the first communication party.

[0239] Among them, for the specific implementation manners of steps S901 - S904, reference can be made to the descriptions of steps S403 - S406 in the corresponding embodiments above, which will not be elaborated here. Figure 4 For the corresponding description of steps S403 - S406 in the corresponding embodiments above, which will not be elaborated here.

[0240] Furthermore, please refer to Figure 10 , Figure 10 which is a schematic structural diagram of a key exchange device provided by an embodiment of the present application. Figure 1 As Figure 10 shown, the key exchange device 1 may include at least one of a transceiver module 1001 and a processing module 1002. These modules may execute the response functions of each device in the above - mentioned method embodiments.

[0241] In a possible implementation manner, the key exchange device 1 may be used to implement the functions of the first communication party.

[0242] Specifically, the transceiver module 1001 is configured to receive the first fixed public key and the first temporary public key sent by the second communication party. The first communication party holds the first fixed private key fragment, and the server having a cooperative relationship with the first communication party holds the second fixed private key fragment. The processing module 1002 is configured to generate, for the first communication party, a first key fragment based on the first fixed public key, the first temporary public key, and the first fixed private key fragment. The transceiver module 1001 is further configured to send, by the first communication party, key exchange parameters related to the first fixed public key and the first temporary public key to the server. The transceiver module 1001 is further configured to receive the second key fragment sent by the server, where the second key fragment is generated based on the key exchange parameters and the second fixed private key fragment. The processing module 1002 is further configured to generate a shared key based on the first key fragment and the second key fragment, and the shared key is used to derive the session key for communication between the first communication party and the second communication party.

[0243] In one implementation manner, the processing module 1002 is further configured to generate a first random number. The transceiver module 1001 is further configured to receive the second random number sent by the server. The processing module 1002 is further configured to generate the first fixed private key fragment based on the first random number and the second random number.

[0244] In one implementation, the processing module 1002 is used by the first communication party to generate a first key fragment based on the first fixed public key, the first temporary public key and the first fixed private key fragment, specifically including: the processing module 1002 is also used to generate a combined temporary private key based on the first fixed private key fragment and the second temporary public key, the second temporary public key is generated based on the target temporary private key generated by a random number generator; the processing module 1002 is also used to verify the first temporary public key; the processing module 1002 is also used to determine that the verification is successful, and generate a combined temporary public key based on the first temporary public key and the first fixed public key; the processing module 1002 is also used to generate the first key fragment based on the combined temporary public key and the combined temporary private key.

[0245] In one implementation, the key exchange parameters include the first temporary public key and the first fixed public key, or the key exchange parameters include a combined temporary public key, which is generated based on the first temporary public key and the first fixed public key.

[0246] In one implementation, the key exchange parameter further includes an index identifier, where the index identifier is used to indicate a corresponding relationship between the first fixed private key fragment and the second fixed private key fragment.

[0247] In one implementation, the first communication party and the second communication party communicate with each other via a Transport Layer Security (TLS) protocol.

[0248] In one implementation, the first fixed private key fragment and the second fixed private key fragment constitute the fixed private key of the first communication party.

[0249] The specific implementation of the transceiver module 1001 and the processing module 1002 can be found in the above Figure 8 The description of steps S801 to S805 in the corresponding embodiment will not be repeated here. In addition, the description of the beneficial effects of the same method will not be repeated here either.

[0250] For further information, see Figure 11 , Figure 11 This is a schematic diagram of the structure of a key exchange device provided in an embodiment of the present application. Figure 2 .like Figure 11 As shown, the key exchange device 2 may include at least one of a transceiver module 1101, a determination module 1102 and a generation module 1103. These modules may execute the response functions of each device in the above method embodiment.

[0251] In a possible implementation, the key exchange device 2 can be used to implement the functions of the server.

[0252] A transceiver module 1101 is configured to receive key exchange parameters sent by a first communication party. The key exchange parameters are related to a first fixed public key and a first temporary public key. The server holds N fixed private key shards corresponding to N communication parties respectively, where N is a positive integer. The N communication parties include the first communication party, and the first communication party holds a first fixed private key shard. A determination module 1102 is configured to determine, from the N fixed private key shards, a second fixed private key shard corresponding to the first fixed private key shard. A generation module 1103 is configured to generate a second key shard based on the second fixed private key shard and the key exchange parameters. The transceiver module 1101 is further configured to send the second key shard from the server to the first communication party.

[0253] In one implementation, the generation module 1103 is further configured to generate a third random number. The transceiver module 1101 is further configured to receive a fourth random number sent by the first communication party. The generation module 1103 is further configured to generate the second fixed private key shard at the server based on the third random number and the fourth random number.

[0254] In one implementation, the key exchange parameters include the first temporary public key and the first fixed public key, or the key exchange parameters include a combined temporary public key, and the combined temporary public key is generated based on the first temporary public key and the first fixed public key.

[0255] In one implementation, the key exchange parameters further include an index identifier, and the index identifier is used to indicate the correspondence between the first fixed private key shard and the second fixed private key shard.

[0256] In one implementation, the second fixed private key shard and the first fixed private key shard form the fixed private key of the first communication party.

[0257] Among them, the specific implementation manners of the transceiver module 1101, the determination module 1102, and the generation module 1103 can refer to the descriptions of steps S901 - S904 in the corresponding embodiments above, and will not be elaborated here. In addition, the beneficial effects of using the same method will not be elaborated either. Figure 9

[0258] Among them, the above modules in the above key exchange device 1 or the above modules in the key exchange device 2 can be implemented by software or can be implemented by hardware. Exemplarily, next, taking the transceiver module 1001 as an example, the implementation manner of the transceiver module 1001 is introduced. Similarly, the implementation manners of the processing module 1002, the transceiver module 1101, the determination module 1102, and the generation module 1103 can refer to the implementation manner of the transceiver module 1001.

[0259] As an example of a software functional unit, the transceiver module 1001 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Further, the computing instance may be one or more. For example, the transceiver module 1001 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers for running the code may be distributed in the same region or in different regions. Further, the multiple hosts / virtual machines / containers for running the code may be distributed in the same availability zone (AZ) or in different AZs, and each AZ includes one data center or multiple geographically proximate data centers. Usually, one region may include multiple AZs.

[0260] Similarly, the multiple hosts / virtual machines / containers for running the code may be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Usually, one VPC is set up within one region. For cross-region communication between two VPCs within the same region and between VPCs in different regions, a communication gateway needs to be set up in each VPC, and the interconnection between VPCs is achieved through the communication gateway.

[0261] As an example of a hardware functional unit, the transceiver module 1001 may include at least one computing device, such as a server. Alternatively, the transceiver module 1001 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be implemented using a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0262] The multiple computing devices included in the transceiver module 1001 can be distributed in the same region or in different regions. The multiple computing devices included in the transceiver module 1001 can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the transceiver module 1001 can be distributed in the same VPC or in multiple VPCs. Among them, the multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0263] It should be noted that the transceiver module 1001 can be used to execute Figure 8 any step in the key exchange method shown. The processing module 1002 can be used to execute any step in the above key exchange method. The steps to be implemented by the transceiver module 1001 and the processing module 1002 can be specified as needed. The entire function of the key exchange device 1 is realized by implementing different steps in the key exchange method through the transceiver module 1001 and the processing module 1002 respectively.

[0264] Alternatively, in other embodiments, the transceiver module 1101 can be used to execute Figure 9 any step in the key exchange method shown. The determination module 1102 can be used to execute any step in the above key exchange method. The generation module 1103 can be used to execute any step in the above key exchange method. The steps to be implemented by the transceiver module 1101, the determination module 1102, and the generation module 1102 can be specified as needed. The entire function of the key exchange device 2 is realized by implementing different steps in the key exchange method through the transceiver module 1001, the determination module 1102, and the generation module 1102 respectively.

[0265] Furthermore, please refer to Figure 12 , Figure 12 which is a schematic structural diagram of a key exchange system provided by an embodiment of the present application. As Figure 12 shown, it includes a key exchange device 1 and a key exchange device 2. Among them, the key exchange device 1 is used to implement the above Figure 8 shown key exchange method, and the key exchange device 2 is used to implement the above Figure 9 shown key exchange method.

[0266] Both the key exchange device 1 and the key exchange device 2 can be implemented by software or can be implemented by hardware. Exemplarily, the implementation manner of the key exchange device 1 is introduced next. Similarly, the implementation manner of the key exchange device 2 can refer to the implementation manner of the key exchange device 1.

[0267] As an example of a software functional unit, the key exchange device 1 may include code running on a computing instance. The computing instance may be at least one of computing devices such as a physical host (computing device), a virtual machine, a container, etc. Further, the above computing devices may be one or more. For example, the key exchange device 1 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers for running the application may be distributed in the same region or in different regions. The multiple hosts / virtual machines / containers for running the code may be distributed in the same AZ or in different AZs, and each AZ includes one data center or multiple geographically proximate data centers. Usually, one region may include multiple AZs.

[0268] Similarly, the multiple hosts / virtual machines / containers for running the code may be distributed in the same VPC or in multiple VPCs. Usually, one VPC is set within one region. For cross-region communication between two VPCs within the same region and between VPCs in different regions, a communication gateway needs to be set in each VPC, and the interconnection between VPCs is achieved through the communication gateway.

[0269] As an example of a hardware functional unit, the key exchange device 1 may include at least one computing device, such as a server, etc. Or, the key exchange device 1 may also be a device implemented by ASIC or PLD, etc. Among them, the above PLD may be implemented by CPLD, FPGA, GAL or any combination thereof.

[0270] The multiple computing devices included in the key exchange device 1 may be distributed in the same region or in different regions. The multiple computing devices included in the key exchange device 1 may be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the key exchange device 1 may be distributed in the same VPC or in multiple VPCs. Among them, the multiple computing devices may be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0271] Further, please refer to Figure 13 , Figure 13 which is a schematic structural diagram of a computing device provided by an embodiment of the present application. As shown in Figure 13As shown, the computing device 1300 includes: a bus 1302, a processor 1304, a memory 1306, and a communication interface 1308. The processor 1304, the memory 1306, and the communication interface 1308 communicate with each other via the bus 1302. The computing device 1300 can be a server or a terminal device. It should be understood that the present application does not limit the number of processors and memories in the computing device 1300.

[0272] The bus 1302 can be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of simplicity in representation, Figure 13 only one line is used to represent it in the figure, but it does not mean that there is only one bus or one type of bus. The bus 1302 can include a path for transmitting information between various components of the computing device 1300 (for example, the memory 1306, the processor 1304, and the communication interface 1308).

[0273] The processor 1304 can include any one or more of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP), etc.

[0274] The memory 1306 can include volatile memory, such as random access memory (RAM). The memory 1306 can also include non-volatile memory, such as read-only memory (ROM), flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

[0275] The memory 1306 stores executable program code, and the processor 1304 executes the executable program code to respectively implement the functions of the aforementioned transceiver module 1001 and processing module 1002 in the key exchange device 1, thereby implementing Figure 8 the key exchange method shown. That is, the memory 1306 stores instructions for executing the key exchange method.

[0276] Alternatively, in other embodiments, executable program code is stored in the memory 1306, and the processor 1304 executes the executable program code to implement the functions of the foregoing transceiver module 1101, determination module 1102, and generation module 1103 in the key exchange device 2 respectively, so as to implement Figure 9 the key exchange method shown. That is, instructions for executing the foregoing key exchange method are stored on the memory 1306.

[0277] The communication interface 1308 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 1300 and other devices or communication networks.

[0278] The embodiment of the present application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device may be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device may also be a terminal device such as a desktop computer, a laptop computer, or a smart phone.

[0279] Further, please refer to Figure 14 , Figure 14 which is a schematic structural diagram of a computing device cluster provided by the embodiment of the present application. As Figure 14 shown, the computing device cluster includes at least one computing device 1400. Instructions for executing the key exchange method may be stored in the memory 1406 of one or more computing devices 1400 in the computing device cluster.

[0280] In some possible implementation manners, partial instructions for executing the key exchange method may also be stored in the memory 1406 of one or more computing devices 1400 in the computing device cluster respectively. In other words, a combination of one or more computing devices 1400 may jointly execute the instructions for executing the key exchange method.

[0281] It should be noted that the memories 1406 in different computing devices 1400 in the computing device cluster may store different instructions, which are respectively used to execute partial functions of the key exchange device 1. That is, the instructions stored in the memories 1406 of different computing devices 1400 may implement the functions of one or more of the foregoing transceiver module 1001 and processing module 1002 in the key exchange device 1.

[0282] Alternatively, in other embodiments, the memories 1406 in different computing devices 1400 in a computing device cluster may store different instructions for respectively performing partial functions of the key exchange device 2. That is, the instructions stored in the memories 1006 in different computing devices 1000 may implement the functions of one or more of the foregoing transceiver module 1101, determination module 1102, and generation module 1103 in the key exchange device 2.

[0283] In some possible implementation manners, one or more computing devices in a computing device cluster may be connected via a network. Among them, the network may be a wide area network, a local area network, or the like.

[0284] Further, please refer to Figure 15 , Figure 15 which is a schematic structural diagram of a connection via a network between computing devices provided by this application. As Figure 15 shown, two computing devices 1400A and 1400B are connected via a network. Specifically, they are connected to the network through the communication interfaces in each computing device. In this type of possible implementation manners, the memory 1406 in the computing device 1400A stores instructions for performing the function of the foregoing transceiver module 1001 in the key exchange device 1. At the same time, the memory 1406 in the computing device 1400B stores instructions for performing the function of the processing module 1002 in the key exchange device 1.

[0285] Alternatively, in other embodiments, the memory 1406 in the computing device 1400A stores instructions for performing the function of the foregoing transceiver module 1101 in the key exchange device 2. At the same time, the memory 1406 in the computing device 1400B stores instructions for performing the functions of the determination module 1102 and the generation module 1103 in the key exchange device 2.

[0286] It should be understood that Figure 15 the functions of the computing device 1400A shown in

[0287] may also be completed by multiple computing devices 1400. Similarly, the functions of the computing device 1400B may also be completed by multiple computing devices 1400. Figure 13 and Figure 14 The connection manner of the computing device cluster. The difference is that the memories 1406 in one or more computing devices 1400 in this computing device cluster may store the same instructions for performing the key exchange method.

[0288] In some possible implementations, the memory 1406 of one or more computing devices 1400 in the computing device cluster may also store some instructions for executing the key exchange method respectively. In other words, the combination of one or more computing devices 1400 may jointly execute the instructions for executing the key exchange method.

[0289] It should be noted that the memories 1406 in different computing devices 1400 in the computing device cluster may store different instructions for executing some functions of the key exchange system. That is, the instructions stored in the memories 1406 of different computing devices 1400 may implement the functions of one or more modules in the key exchange device 1 and the key exchange device 2.

[0290] The embodiment of the present application also provides a computer program product including instructions. The computer program product may be software or a program product including instructions that can run on a computing device or be stored in any available medium. When the computer program product runs on at least one computing device, it causes at least one computing device to execute the key exchange method in the foregoing embodiments, or the key exchange method.

[0291] The embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium may be any available medium that a computing device can store or a data storage device such as a data center including one or more available media. The available medium may be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid-state drive), etc. The computer-readable storage medium includes instructions that instruct the computing device to execute the key exchange method in the foregoing embodiments, or the key exchange method.

[0292] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, and are not intended to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the protection scope of the technical solutions of the embodiments of the present application.

Claims

1. A key exchange method, characterized in that: Applied to a first communication party, the first communication party holds a first fixed private key shard, and a service end having a collaborative relationship with the first communication party holds a second fixed private key shard, the method comprising: The first communication party receives a first fixed public key and a first temporary public key sent by the second communication party; The first communication party generates a first key fragment based on the first fixed public key, the first temporary public key and the first fixed private key fragment; The first communication direction sends a key exchange parameter to the server, where the key exchange parameter is related to the first fixed public key and the first temporary public key; The first communication party receives a second key fragment sent by the server, where the second key fragment is generated based on the key exchange parameter and the second fixed private key fragment; The first communication party generates a shared key based on the first key fragment and the second key fragment, and the shared key is used to derive a session key for communication between the first communication party and the second communication party.

2. The method according to claim 1, characterized in that The method further comprises: The first communication party generates a first random number; The first communication party receives a second random number sent by the server; The first communication party generates the first fixed private key fragment based on the first random number and the second random number.

3. The method according to claim 1 or 2, characterized in that: The first communication party generates a first key fragment based on the first fixed public key, the first temporary public key and the first fixed private key fragment, including: The first communication party generates a combined temporary private key based on the first fixed private key fragment and the second temporary public key, where the second temporary public key is generated based on a target temporary private key generated by a random number generator; The first communication party verifies the first temporary public key; The first communication party determines that the verification is successful, and generates a combined temporary public key based on the first temporary public key and the first fixed public key; The first communicating party generates the first key fragment based on the combined temporary public key and the combined temporary private key.

4. The method according to any one of claims 1 to 3, characterized in that: The key exchange parameters include the first temporary public key and the first fixed public key, or the key exchange parameters include a combined temporary public key, where the combined temporary public key is generated based on the first temporary public key and the first fixed public key.

5. The method according to claim 4, characterized in that The key exchange parameter also includes an index identifier, and the index identifier is used to indicate the corresponding relationship between the first fixed private key fragment and the second fixed private key fragment.

6. The method according to any one of claims 1 to 5, characterized in that: The first communication party and the second communication party communicate with each other via the Transport Layer Security (TLS) protocol.

7. The method according to any one of claims 1 to 6, characterized in that: The first fixed private key fragment and the second fixed private key fragment constitute the fixed private key of the first communicating party.

8. A key exchange method, characterized in that: Applied to a server, the server holds fixed private key fragments corresponding to N communication parties, N is a positive integer, the N communication parties include a first communication party, the first communication party holds a first fixed private key fragment, and the method includes: The server receives a key exchange parameter sent by the first communication party, where the key exchange parameter is related to the first fixed public key and the first temporary public key; The server determines, from the N fixed private key shards, a second fixed private key shard corresponding to the first fixed private key shard; The server generates a second key fragment based on the second fixed private key fragment and the key exchange parameter; The server sends the second key fragment to the first communication party.

9. The method according to claim 8, characterized in that The method further comprises: The server generates a third random number; The server receives a fourth random number sent by the first communication party; The server generates the second fixed private key fragment based on the third random number and the fourth random number.

10. The method according to claim 8 or 9, characterized in that: The key exchange parameters include the first temporary public key and the first fixed public key, or the key exchange parameters include a combined temporary public key, where the combined temporary public key is generated based on the first temporary public key and the first fixed public key.

11. The method according to claim 10, characterized in that The key exchange parameter also includes an index identifier, and the index identifier is used to indicate the corresponding relationship between the first fixed private key fragment and the second fixed private key fragment.

12. The method according to any one of claims 8 to 11, characterized in that: The second fixed private key fragment and the first fixed private key fragment constitute the fixed private key of the first communicating party.

13. A key exchange device, characterized in that: include: A transceiver module, configured to receive a first fixed public key and a first temporary public key sent by a second communication party, wherein the first fixed private key fragment is held by the first communication party, and a service end having a collaborative relationship with the first communication party holds the second fixed private key fragment; A processing module, configured for the first communication party to generate a first key fragment based on the first fixed public key, the first temporary public key and the first fixed private key fragment; The transceiver module is further configured to send a key exchange parameter to the server in the first communication direction, wherein the key exchange parameter is related to the first fixed public key and the first temporary public key; The transceiver module is further used to receive a second key fragment sent by the server, where the second key fragment is generated based on the key exchange parameter and the second fixed private key fragment; The processing module is further used to generate a shared key based on the first key fragment and the second key fragment, and the shared key is used to derive a session key for communication between the first communication party and the second communication party.

14. A key exchange device, characterized in that: include: a transceiver module, configured to receive a key exchange parameter sent by the first communication party, wherein the key exchange parameter is related to a first fixed public key and a first temporary public key, the server holds fixed private key fragments corresponding to N communication parties, N is a positive integer, the N communication parties include the first communication party, and the first communication party holds the first fixed private key fragment; A determination module, configured to determine, from the N fixed private key shards, a second fixed private key shard corresponding to the first fixed private key shard; A generating module, configured to generate a second key fragment based on the second fixed private key fragment and the key exchange parameter; The transceiver module is also used for the server to send the second key fragment to the first communication party.

15. A computing device cluster, characterized in that: comprising at least one computing device, each computing device comprising a processor and a memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method according to any one of claims 1 to 7 or the method according to any one of claims 8 to 12.

16. A computer program product comprising instructions, characterized in that When the instructions are executed by a computing device cluster, the computing device cluster executes the method according to any one of claims 1 to 7 or the method according to any one of claims 8 to 12.

17. A computer-readable storage medium, characterized in that: The method comprises computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster performs the method according to any one of claims 1 to 7 or the method according to any one of claims 8 to 12.

Images