Key exchange method and apparatus

Abstract

The present application relates to the field of cloud computing, and discloses a key exchange method and apparatus. The method is applied to a first communication party, the first communication party holds a first fixed private key fragment, and a server having a cooperative relationship with the first communication party holds a second fixed private key fragment. The method comprises: receiving a first fixed public key and a first ephemeral public key sent by a second communication party; generating a first key fragment on the basis of the first fixed public key, the first ephemeral public key and the first fixed private key fragment; sending a key exchange parameter to the server, wherein the key exchange parameter is related to the first fixed public key and the first ephemeral public key; receiving a second key fragment sent by the server, wherein the second key fragment is generated on the basis of the key exchange parameter and the second fixed private key fragment; and generating a shared key on the basis of the first key fragment and the second key fragment, wherein the shared key is used for deriving a session key for communication between the first communication party and the second communication party. The present application is used for effectively protecting private keys, thereby improving safety.

Description

Key exchange method and device

[0001] This application claims priority to Chinese Patent Application No. 202311704027.4, filed with the State Intellectual Property Office of China on December 12, 2023, entitled “A Method, Apparatus, and Other Devices for Data Processing,” the entire contents of which are hereby incorporated by reference into this application. Furthermore, this application claims priority to Chinese Patent Application No. 202410244667.X, filed with the State Intellectual Property Office of China on March 4, 2024, entitled “A Method and Apparatus for Key Exchange,” the entire contents of which are hereby incorporated by reference into this application. Technical Field

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

[0003] Domestic cryptographic algorithms recognized by the National Cryptography Administration (i.e., national cryptography) primarily include SM2, SM3, SM4, and SM9. The SM2 algorithm is an elliptic curve public key algorithm. The SM2 algorithm's key exchange protocol and process can be used in commercial cryptographic applications to ensure that communicating parties obtain a shared secret key (session key) jointly determined by both parties after two or, optionally, three information transfers.

[0004] During key exchange, the fixed private key of the initiator (or responder) will participate in the calculation of the key exchange. Once it is controlled by an attacker, the attacker can crack the session messages, which poses a huge risk. Therefore, how to securely store and use the private key is a very important issue.

[0005] Summary of the Invention

[0006] The present application provides a key exchange method and device for effectively protecting private keys and improving security.

[0007] In order to achieve the above objectives, this application adopts the following technical solutions.

[0008] In a first aspect, an embodiment of the present application provides a key exchange method, which is applied to a first communication party, the first communication party holds a first fixed private key fragment, and a server having a collaborative relationship with the first communication party holds a second fixed private key fragment, 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 party sends a key exchange parameter to the server, 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, 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.

[0009] In the above method, the fixed private key of the first communication party is not stored in a separate device, but is split into two parts, a first fixed private key fragment and a second fixed private key fragment. Among them, the first fixed private key fragment is held by the first communication party, and the second fixed private key fragment is held by the server. Even if an attacker attacks the first communication party or one of the server parties, 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 fragment based on the first fixed private key fragment held by itself, and receives a second key fragment generated by the server based on the second fixed private key fragment. This means that when the first communication party determines the shared key, it does not need to expose the complete private key, but generates a complete shared key through collaboration with the server. During the entire process, neither party can obtain the other party's fixed private key fragment, and when the fixed private key fragment is involved in the calculation, the complete private key will not appear on either party, thereby effectively ensuring the security of the private key during use. It can be seen that the key exchange method provided in the embodiment of the present application can effectively protect the private key and improve security.

[0010] 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; and the first communication party generates a first fixed private key fragment based on the first random number and the second random number.

[0011] In the above implementation, the first fixed private key shard of the first communication party is generated through collaboration 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. This private key generation method is more random and more difficult to be restored by other illegal users, thereby more effectively ensuring the security of the first fixed private key shard.

[0012] In one implementation, 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, and the second temporary public key is generated based on the 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 communication party generates the first key fragment based on the combined temporary public key and the combined temporary private key.

[0013] The above implementation method more clearly describes how to generate the first key shard. The entire process only requires the use of the first fixed private key shard held by itself. There is no need to expose the complete fixed private key of the first communication party, nor is there any need to obtain another part of the fixed private key shard of the first communication party held by the server, thereby effectively ensuring the security of the private key during use.

[0014] 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 generated based on the first temporary public key and the first fixed public key.

[0015] In the above implementation, there are two situations for key exchange parameters: In the first situation, when the first communication party receives the first temporary 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 fragment, but can directly send the first temporary public key and the first fixed public key to the server, so that the server and the first communication party can calculate the two key fragments in parallel, which greatly saves the generation time of the key fragments and improves the generation efficiency of the shared key. In the second situation, when the first communication party receives the first key fragment determined by the second communication party, it needs to calculate the first temporary public key and the first fixed public key to obtain a combined temporary public key. This combined temporary public key is also the parameter required by the server to generate the second key fragment. Therefore, the first communication party can directly send the calculated combined temporary public key to the server, without the need for the server to repeat the calculation, saving the server's computing resources.

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

[0017] In the above implementation, when the server holds an excessive number of fixed private key shards, it can quickly and accurately find the second fixed private key shard corresponding to the first fixed private key shard through the index identifier.

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

[0019] The above implementation means that the key exchange method of the embodiment of the present application can be used in the TLS protocol, thereby effectively ensuring the security of the fixed private key of the first communicating party in the TLS scenario.

[0020] 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.

[0021] In the above implementation, 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 of using private key shards to protect the private key does not rely on hardware equipment, is easier to deploy, and does not require excessive costs.

[0022] In the second aspect, an embodiment of the present application provides a key exchange method, which is applied to a server, and the server holds fixed private key shards corresponding to N communication parties, N is a positive integer, and 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 key exchange parameters sent by the first communication party, and the key exchange parameters are related to the first fixed public key and the first temporary public key; the server determines the 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 parameters; the server sends the second key shard to the first communication party.

[0023] In the above implementation, the server can hold fixed private key shards corresponding to each of the N communicating parties. This means that the fixed private keys of the N communicating parties are not stored on separate devices, effectively ensuring the fixed private keys of multiple communicating parties and further enhancing security. Taking the first of the N communicating parties as an example, the first party's fixed private key is split into two parts: a first fixed private key shard and a second fixed private key shard. The first fixed private key shard is held by the first communicating party, while the second fixed private key shard is held by the server. Even if an attacker attacks either the first communicating party or the server, it is difficult to recover the complete fixed private key, thus greatly ensuring the security of the storage of the first party's fixed private key. Furthermore, during the key exchange process, the server generates the second fixed private key shard based on the second fixed private key shard and the received key exchange parameters. This entire process does not expose the complete private key and does not require the first fixed private key shard held by the first communicating party. The complete private key is never revealed to either party, effectively ensuring the security of the private key during use. It can be seen that the key exchange method provided in the embodiment of the present application can effectively protect private keys and improve security.

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

[0025] In the above implementation, the second fixed private key shard is generated by the server through collaboration 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. This private key generation method is more random and more difficult to be restored by other illegal users, thereby more effectively ensuring the security of the second fixed private key shard.

[0026] 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 generated based on the first temporary public key and the first fixed public key.

[0027] In the above implementation, there are two situations for key exchange parameters: In the first situation, when the key exchange parameters include a first temporary public key and a 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, there is no need to wait 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 time for generating the key shards and thereby improving the efficiency of generating the second key shard. In the second situation, when the key exchange parameters include a 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 computing resources on the server.

[0028] 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.

[0029] In the above implementation, when the server holds an excessive number of fixed private key shards, it can quickly and accurately find the second fixed private key shard corresponding to the first fixed private key shard through the index identifier.

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

[0031] In the above implementation, 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 of using private key shards to protect the private key does not rely on hardware equipment, is easier to deploy, and does not require excessive costs.

[0032] In the third aspect, an embodiment of the present application provides a key exchange device for implementing a method as described in the first aspect or any one of the implementation methods of the first aspect. Specifically, the device includes: a transceiver module for receiving a first fixed public key and a first temporary public key sent by the second communication party, the first fixed private key fragment is held by the first communication party, and the server having a collaborative relationship with the first communication party holds the second fixed private key fragment; a processing module 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 also used for the first communication party to send key exchange parameters to the server, the key exchange parameters are related to the first fixed public key and the first temporary public key; the transceiver module is also used to receive the second key fragment sent by the server, the second key fragment is generated based on the key exchange parameters and the second fixed private key fragment; the processing module is also used to generate a shared key based on the first key fragment and the second key fragment, the shared key is used to derive a session key for communication between the first communication party and the second communication party.

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

[0034] In one implementation, a processing module is used by a first communicating party to generate a first key fragment based on a first fixed public key, a first temporary public key, and a first fixed private key fragment, specifically including: the processing module is also used to generate a combined temporary private key based on the first fixed private key fragment and a second temporary public key, the second temporary public key is generated based on a target temporary private key generated by a random number generator; the processing module is also used to verify the first temporary public key; the processing module 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 is also used to generate the first key fragment based on the combined temporary public key and the combined temporary private key.

[0035] 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 generated based on the first temporary public key and the first fixed public key.

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

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

[0038] 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.

[0039] In a fourth aspect, an embodiment of the present application provides a key exchange device for implementing a method as described in the second aspect or any one of the implementation methods of the second aspect. Specifically, the device includes: a transceiver module for receiving 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 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 for determining the second fixed private key fragment corresponding to the first fixed private key fragment from the N fixed private key fragments; a generation module for generating a second key fragment based on the second fixed private key fragment and the key exchange parameters; and a transceiver module for the server to send the second key fragment to the first communication party.

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

[0041] 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 generated based on the first temporary public key and the first fixed public key.

[0042] 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.

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

[0044] In a fifth aspect, embodiments of the present application provide a computing device cluster, comprising at least one computing device, each computing device including 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 performs the key exchange method of the first aspect or any possible implementation of the first aspect.

[0045] In a sixth aspect, an embodiment of the present application provides a computer program product comprising instructions, which, when executed by a computing device cluster, enables the computing device cluster to execute the key exchange method in the first aspect or any possible implementation of the first aspect.

[0046] In a seventh aspect, an embodiment of the present application provides a computer-readable storage medium comprising 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 of the first aspect.

[0047] In an eighth aspect, embodiments of the present application provide a computing device cluster, 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 performs the key exchange method of the second aspect or any possible implementation of the second aspect.

[0048] In a ninth aspect, an embodiment of the present application provides a computer program product comprising instructions, which, when executed by a computing device cluster, enables the computing device cluster to execute the key exchange method in the second aspect or any possible implementation of the second aspect.

[0049] In a tenth aspect, an embodiment of the present application provides a computer-readable storage medium comprising 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 of the second aspect.

[0050] The technical effects produced by any implementation method in the above-mentioned second to tenth aspects and each aspect can refer to the above-mentioned first aspect and the corresponding implementation method in the first aspect, and the repetitions will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] FIG1 is a schematic diagram of a network architecture provided in an embodiment of the present application;

[0052] FIG2 is a schematic diagram of a method for collaborative key generation provided in an embodiment of the present application;

[0053] FIG3 is a schematic diagram of a key exchange method provided in an embodiment of the present application;

[0054] FIG4 is a first interactive diagram of a key exchange method provided in an embodiment of the present application;

[0055] FIG5 is a schematic diagram of a scenario of key exchange based on national secret TLS provided in an embodiment of the present application;

[0056] FIG6 is a schematic diagram of a collaborative key exchange in a national secret TLS scenario provided by an embodiment of the present application;

[0057] FIG7 is a second interactive diagram of a key exchange method provided in an embodiment of the present application;

[0058] FIG8 is a schematic diagram of a first process for performing key exchange according to an embodiment of the present application;

[0059] FIG9 is a second schematic diagram of a process for performing key exchange according to an embodiment of the present application;

[0060] FIG10 is a structural diagram of a key exchange device according to an embodiment of the present application;

[0061] FIG11 is a second structural diagram of a key exchange device provided in an embodiment of the present application;

[0062] FIG12 is a schematic structural diagram of a key exchange system provided in an embodiment of the present application;

[0063] FIG13 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0064] FIG14 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application;

[0065] FIG15 is a schematic diagram of a structure of a network connection between computing devices provided by the present application. DETAILED DESCRIPTION

[0066] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application. In order to facilitate the clear description of the technical solutions in the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" are used to distinguish between identical or similar items with substantially the same functions and effects. Those skilled in the art will understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit differences. 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 described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or design solutions. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a concrete way for easy understanding.

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

[0068] Where p is a finite field The order of a, b is the elliptic curve E:y 2 =x 3+ax+b parameters; n is the elliptic curve E in the finite field The number of midpoints; G is The base point, the horizontal coordinate is x G , the vertical coordinate is y G .

[0069] The operation symbols used in the description of the solution in this application are as follows:

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

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

[0072] (3) In this application, the four arithmetic operations on integers all represent operations modulo n, such as a+b represents a+b mod n, and a*b represents a*b mod n; the symbol || represents the concatenation of two strings;

[0073] To facilitate understanding of the technical solutions provided by the embodiments of the present application, a brief introduction to the relevant technologies of the embodiments of the present application is given.

[0074] In current technical solutions, the traditional method is to store the private key of the communicating party in dedicated key hardware, such as a hardware cryptographic module. However, dedicated hardware cryptographic modules are relatively expensive and difficult to deploy. This makes it impossible for the communicating party to rely on hardware cryptographic modules to store the private key and use it for key exchange during encrypted communication in many cases. One solution is to use a software cryptographic module to store the communicating party's private key in a permanent storage medium of a local computing device (e.g., a personal computer's hard drive or the built-in storage of a mobile communication terminal). The private key is protected by a key used for identity verification (e.g., a PIN code). When the communicating party needs to use the private key for key exchange, the software cryptographic module can retrieve the private key from the communicating party's permanent storage medium. However, this solution still carries the risk of key leakage. For example, an attacker can steal the private key from the permanent storage medium of the signer's local computing device by implanting a Trojan horse program. In addition, because the private key is stored in plaintext in memory during the key exchange process, an attacker may be able to steal the private key in memory through certain attacks, which also leads to the risk of private key leakage when the private key is used. Therefore, how to securely store and use private keys without using hardware cryptographic modules is a problem that needs to be solved.

[0075] In order to solve the above problems, an embodiment of the present application provides a new key exchange method, which can be applied to a first communication party (for example, an initiator or a responder), the first communication party holds a first fixed private key fragment, and the server having a collaborative relationship with the first communication party holds a second fixed private key fragment. In this method, the first communication party is able to receive the first fixed public key and the first temporary public key sent by the second communication party, and generate a first key fragment based on the first fixed public key, the first temporary public key and the first fixed private key fragment. Furthermore, the first communication party can send key exchange parameters to the server and receive the second key fragment returned by the server (generated based on the key exchange parameters and the second fixed private key fragment). The key exchange parameters here are related to the first fixed public key and the first temporary public key. Then, the first communication party can generate a shared key based on the first key fragment and the second key fragment. Among them, the shared key here can be used to derive a session key for communication between the first communication party and the second communication party.

[0076] In an embodiment of the present application, the fixed private key of the first communication party is not stored in a separate device, but is split into two parts, a first fixed private key fragment and a second fixed private key fragment. Among them, the first fixed private key fragment is held by the first communication party, and the second fixed private key fragment is held by the server. Even if an attacker attacks the first communication party or one of the server parties, 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 fragment based on the first fixed private key fragment held by itself, and receives the second key fragment calculated by the server based on the second fixed private key fragment. This means that when the first communication party determines the shared key, it does not need to expose the complete private key, but calculates the complete shared key through collaboration with the server. During the entire process, neither party can obtain the other party's fixed private key fragment, and when the fixed private key fragment is involved in the calculation, the complete private key will not appear on either 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 improve security.

[0077] The following describes the network architecture for applying the key exchange method provided in the embodiments of the present application:

[0078] Please refer to Figure 1, which is a structural diagram of a network architecture provided by an embodiment of the present application. As shown in Figure 1, 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 shown in Figure 1, the client cluster may specifically include client A, client B, client C, ..., client N. As shown in Figure 1, client A, client B, client C, ..., client N can respectively establish a network connection with the above-mentioned server 100, so that each client can interact with the server 100 through the network connection. Among them, the network connection here does not limit the connection method, and 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, and the present application does not impose any restrictions on this.

[0079] Among them, each client in the client cluster can have a collaborative relationship with the server 100, and each client here can include: smart phones, tablets, laptops, desktop computers, smart speakers, smart watches, car terminals, smart TVs and other smart terminals with data processing functions.

[0080] As shown in Figure 1, the server 100 in the embodiment of the present application can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. In particular, the embodiment of the present application does not limit the number of server terminals.

[0081] It should be understood that in order to effectively ensure the security of private key storage, the embodiment of the present application can split the fixed private key of the SM2 encryption certificate into two parts, which are stored on the client and server sides of the cryptographic module respectively. Only by collaborating with each other can the elliptic curve point shards (i.e., key shards) be calculated separately. In this process, neither party can obtain the other party's private key shards.

[0082] For ease of understanding, further reference is made to FIG2 , which is a schematic diagram of a method for collaborative key generation provided in an embodiment of the present application. The method may be performed jointly by a client and a server, wherein the client may be any one of the client clusters shown in FIG1 (e.g., client A), and the server may be the server 100 shown in FIG1 . The method may specifically include steps S11-S15 performed by the server, and steps S21-S25 performed by the client:

[0083] As shown in Figure 2, the client can execute steps S21-S22 to generate random numbers a1 and b1, and calculate the elliptic curve point B1 based on the random number b1. n .

[0084] Specifically, the specific method for the client to calculate the elliptic curve point B1 can be referred to the following formula (1): B1=[b1]G (1)

[0085] Similarly, the server can also execute steps S11-S12 to generate random numbers a2 and b2, and calculate the elliptic curve point B2 based on the random number b2. n Specifically, the specific method for the server to calculate the elliptic curve point B2 can be referred to the following formula (2): B2=[b2]G (2)

[0086] Among them, Z n Refers to the set of non-negative integers smaller than n, that is, Z n ={0,1,…,(n-1)}.

[0087] Furthermore, for the client, after the server calculates the elliptic curve point B2, the client can execute step S23 to receive the random number a2 and the elliptic curve point B2 sent by the server. Further, the client can execute steps S24-S25 to determine the private key shard d1 based on the random number a2 and the random number b1 generated by itself, and determine the public key P based on the random number a1, the random number a2, the elliptic curve point B1 and the elliptic curve point B2.

[0088] Specifically, the specific method for the client to determine the private key shard d1 can be referred to the following formula (3): d1=a2b1 (3)

[0089] The specific method for the client to determine the public key P can be found in the following formula (4): P = [a1] B2 + [a2] B1 (4)

[0090] Similarly, for the server, after the client calculates the elliptic curve point B1, the server can execute step S13 to receive the random number a1 and the elliptic curve point B1 sent by the client. Further, the server can execute steps S14-S15 to determine the private key shard d2 based on the random number a1 and the random number b2 generated by itself, and determine the public key P based on the random number a1, the random number a2, the elliptic curve point B1 and the elliptic curve point B2.

[0091] Specifically, the specific method for the server to determine the private key shard d2 can be referred to the following formula (5): d2=a1b2 (5)

[0092] The specific method for the server to determine the public key P can be found in the following formula (6): P = [a1] B2 + [a2] B1 (6)

[0093] In this embodiment of the present application, the private key d and the public key P may be referred to as a complete key pair. The specific formula of the private key d can be found in the following formula (7), and the public key P can be found in the following formula (8): d = d1 + d2 = a2b1 + a1b2 (7) P = [d]G = [a1]B2 + [a2]B1 = [a2b1 + a1b2]G (8)

[0094] In other words, the private key fragment d1 and the private key fragment d2 here can constitute the fixed private key of the client shown in Figure 2 (for example, the fixed private key of the SM2 certificate). The embodiment of the present application can apply the key generation method shown in Figure 2 to a communication scenario, wherein the communication scenario here can be a scenario of communicating through various protocols, for example, a scenario of communicating through the Transport Layer Security (TLS) protocol (also known as a TLS communication scenario).

[0095] It is understandable that, in a communication scenario, since the private key file of a general SM2 certificate does not have an extension item, in order to facilitate the subsequent rapid implementation of key exchange, the embodiment of the present application can add an extension field to the private key of the encryption certificate of the national secret dual certificate, for example, using the SM2 private key in the PKCS8 format. Among them, the extension field here can be an index identifier corresponding to the private key shard, and the index identifier can be used for the correspondence between the private key shards held by a client and the server after collaboration. For example, the index identifier of the private key file corresponding to the private key shard d1 held by the client and the index identifier of the private key file corresponding to the private key shard d2 held by the server are the same identifier.

[0096] In the key exchange scenario, the embodiment of the present application may refer to the private key shard generated by the collaboration between the server and the client as a fixed private key shard, and the public key generated by the collaboration between the server and the client as a fixed public key. Since each client in the client cluster shown in Figure 1 above has a collaborative relationship with the server 100, 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. For ease of understanding, please refer to Table 1, which is a relationship mapping table associated with fixed private key shards provided in an embodiment of the present application. As shown in Table 1:

[0097] Table 1

[0098] Among them, the public key P A It can be used to represent the fixed public key generated when client A collaborates with server 100. When other clients communicate with client A, the public key P A Able to participate in key exchange calculations; private key shard dA2 It can be used to indicate a portion of the fixed private key fragment held by the server 100 after coordinating with the client A, and the index identifier A can be used to indicate the private key fragment d A2 and another fixed private key shard held by client A (e.g. private key shard d A1 ) between them.

[0099] Similarly, the public key P B It 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, the public key P B Able to participate in key exchange calculations; private key shard d B2 It can be used to indicate a portion of the fixed private key fragment held by the server 100 after coordinating with the client B, and the index identifier B can be used to indicate the private key fragment d B2 and another fixed private key shard held by client B (for example, private key shard d B1 ) between them.

[0100] By analogy, it should be noted that the items shown in Table 1 are only a form of expression for reference. In actual business scenarios, other items (such as the terminal identification of the client, etc.) can be established according to needs. The embodiment of this application does not limit the specific form of Table 1.

[0101] For ease of understanding, further reference is made to FIG3 , which is a schematic diagram of a key exchange method provided by an embodiment of the present application. As shown in FIG3 , the method can be jointly performed by an initiator, a responder, and a server, wherein the responder here can be any client (e.g., client B) shown in FIG1 above, the initiator can be another client (e.g., client A) communicating with client B, and the server can be the server 100 shown in FIG1 above. The method can specifically include steps S301-S312:

[0102] As shown in Figure 3, client A can generate a random number r locally based on a random number generator. A The random number generator here can be a random number generator approved by the State Cryptography Administration. For the sake of convenience, the embodiment of the present application can refer to the random number generated by the random number generator during the key exchange process as a temporary private key. Then, the client A can execute steps S301-S302, based on the random number r A , determine the temporary public key R A , and send the temporary public key R to client B A With a fixed public key P A , where when client A and client B communicate via TLS protocol, the fixed public key PA Can refer to the public key of the SM2 encryption certificate.

[0103] Specifically, client A determines the temporary public key R A The specific method can be found in the following formula (9): A =[r A ]G=(x1,y1) (9)

[0104] Among them, r A ∈Z n , G is the base point of the SM2 elliptic curve system parameters.

[0105] It is understandable that the client B here holds a fixed public key P B and fixed private key shard d B1 , and the server holds another fixed private key shard corresponding to client B (for example, fixed private key shard d B2 ).

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

[0107] Specifically, client B determines the combined temporary private key t B The specific method can be found in the following formulas (10)-(12): B =[r B ]G=(x2,y2) (10)

[0108] Among them, R B It means that client B is based on the random number r B The determined temporary public key, r B ∈Z n ; x2 refers to the temporary public key R B The extracted domain elements; Refers to the element obtained by converting the data type of the domain element x2 into an integer (i.e., the temporary public key R B corresponding integer domain element); d B1 It is the fixed private key shard held by client B.

[0109] Furthermore, client B receives the temporary public key R sent by client A. A With a fixed public key P A Afterwards, step S305 may be executed to verify the temporary public key R A Whether the curve equation is satisfied. If the temporary public key RA If the curve equation is not satisfied, the negotiation fails. A If the curve equation is satisfied, the verification is successful. At this time, client B can execute steps S306-S308, that is, first based on the temporary public key R A and a fixed public key P A , determine the combined temporary public key K A , then based on the combined temporary private key t B and the combined temporary public key K A , determine the elliptic curve point shard V 1， And send key exchange parameters to the server. Among them, the key exchange parameters here can include the combined temporary public key K A , or the key exchange parameters include the temporary public key R A With a fixed public key P A .

[0110] Specifically, the specific method for client B to determine the elliptic curve point shard V1 can be referred to the following formulas (13)-(15):

[0111] Among them, x1 refers to the temporary public key R A The extracted domain elements; Refers to the element obtained by converting the data type of the domain element x1 into an integer (i.e., the temporary public key R A corresponding integer field element); h is the cofactor of the SM2 elliptic curve system parameter (e.g., 1).

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

[0113] Specifically, the specific method for the server to determine the elliptic curve point shard V2 can be referred to the following formula (16):

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

[0115] Specifically, the specific method for client B to determine the complete elliptic curve point can be referred to the following formula (17): V = V1 + V2 = (x v ,y v ) (17)

[0116] Thus, in order to effectively ensure the security of the private key, in the embodiment of the present application, the fixed private key of the SM2 encryption certificate can be split into two parts, which are stored separately on the client B and the server of the cryptographic module. Only by collaborating with each other can the elliptic curve point shards (i.e., key shards) be calculated. In this process, neither party can obtain the other party's private key shard information.

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

[0118] Step S401: A first communication party receives a first fixed public key and a first temporary public key sent by a second communication party.

[0119] Among them, the first communication party in the embodiment of the present application can be the initiator or the responder. For the sake of convenience, the first communication party can be taken as the responder as an example, and the second communication party can be taken as the initiator as an example. When the second communication party is the initiator shown in Figure 3 (for example, client A), the first fixed public key here can be the fixed public key P A Indicates that the first temporary public key can be used with the temporary public key R A Indicates that the temporary public key R A It is a temporary private key generated based on a random number generator (for example, a random number r A ) generated.

[0120] When a first communication party and a second communication party communicate with each other through the Transport Layer Security (TLS) protocol, the first communication party may be referred to as a TLS responder, and the second communication party may be referred to as a TLS initiator.

[0121] It should be understood that before initiating the connection, the second communication party has prepared a fixed public-private key pair consisting of the first fixed public key. If the second communication party is also a client with a collaborative relationship with the server, the fixed public-private key pair here can be generated using the key generation method shown in Figure 2 above. 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 using other key generation methods, which will not be limited here.

[0122] For example, when the second communication party wants to communicate with the first communication party, the second communication party may use a random number generator to generate a random number r A In this embodiment, the random number r generated by the second communication party during the key exchange process can be A It is called the first temporary private key. Furthermore, the second communication party can refer to the above formula (9) and perform a scalar point multiplication operation on the first temporary private key and the base point of the SM2 elliptic curve system parameter 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 to send the fixed public key P to the first communication party. A and the temporary public key R A .

[0123] Step S402: 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.

[0124] When the first communication party is the responder (eg, client B) shown in FIG3 , the first fixed private key fragment is replaced by the fixed private key fragment d B1 Indicates. 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, and the second temporary public key is generated based on the target temporary private key generated by the random number generator. Furthermore, 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. The first communication party determines that the verification is successful (that is, the first temporary public key satisfies the curve equation), and can generate a combined temporary public key based on the first temporary public key and the first fixed public key, and then can generate a first key shard based on the combined temporary public key and the combined temporary private key.

[0125] For example, the first communication party may use a random number generator to generate a random number r B In this embodiment, the random number r generated by the first communication party during the key exchange process can be B It 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) and perform a scalar point multiplication operation on the second temporary private key and the base point of the SM2 elliptic curve system parameter 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), extract the first domain element (for example, x2) from the second temporary public key, and convert the data type of the first domain element to an integer to obtain the integer domain element corresponding to the second temporary public key. Further, the first communication party can refer to the above formula (12), determine the scalar multiplication result of the integer domain element corresponding to the second temporary public key and the second temporary private key, and multiply the scalar multiplication result with the first fixed private key fragment (for example, fixed private key fragment d B1 ) are added to obtain the combined temporary private key (for example, the combined temporary private key t B ).

[0126] The first communication party determines a first temporary public key (for example, a temporary public key R A ) satisfies the curve equation, the first communication party can refer to the above formula (13), extract the second domain element (for example, x1) from the first temporary public key, and convert the data type of the second domain element to an integer to obtain the integer domain 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 domain element corresponding to the first temporary public key and the first temporary public key, and then can multiply the scalar point multiplication result with the first fixed public key (for example, the fixed public key P A ) are added to obtain the combined temporary public key (for example, the combined temporary public key K A ). Furthermore, the first communication 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 parameter, and then generate the first key shard (for example, the above elliptic curve point shard V1) based on the scalar multiplication result and the combined temporary public key.

[0127] Step S403: The first communication direction sends key exchange parameters to the server.

[0128] Among them, the server here can hold fixed private key fragments corresponding to N communication parties, and these N communication parties include the first communication party, and N is a positive integer. When N is 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 a combined temporary public key, which is determined by the first communication party with reference 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 here can be used to indicate the corresponding relationship between the first fixed private key fragment and the fixed private key fragment corresponding to the first communication party held by the server (i.e., the second fixed private key fragment).

[0129] The index identifier here may be included in the private key file corresponding to the first fixed private key fragment. For example, the private key file corresponding to the first fixed private key fragment includes an extension field, and the extension field here includes the index identifier. It is understandable that because the fixed private key of the first communication party is split into two parts, when the first communication party determines the session key with the second communication party, it is necessary to send key exchange parameters for collaboration to the server to enable the server to generate the second key fragment.

[0130] In step S404, the server determines the second fixed private key shard corresponding to the first fixed private key shard from the N fixed private key shards.

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

[0132] It is understandable that the private key file corresponding to the second fixed private key fragment may also include an extension field, and the extension field includes an index identifier. For example, when the first communication party is client B, the first fixed private key fragment held by the first communication party (for example, fixed private key fragment d B1 ) corresponding to the index identifier, and the second fixed private key fragment held by the server (for example, fixed private key fragment d B2 ) are the same, that is, they can all be the index identifier B shown in Table 1 above.

[0133] Step S405: The server generates a second key fragment based on the second fixed private key fragment and the key exchange parameters.

[0134] Specifically, if the key exchange parameters received by the server include the first fixed public key and the first temporary public key, the server can refer to the above formula (16), first extract the second domain element (for example, x1) from the first temporary public key, and convert the data type of the second domain element to an integer to obtain the integer domain element corresponding to the first temporary public key. Then, the server can determine the scalar point multiplication result of the integer domain element corresponding to the first temporary public key and the first temporary public key, and then can multiply the scalar point multiplication result with the first fixed public key (for example, the fixed public key P A ) are added to obtain the combined temporary public key (for example, 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 parameter, and then generate a second key shard (e.g., elliptic curve point shard V2) based on the scalar multiplication result and the combined temporary public key.

[0135] Optionally, if the key exchange parameters received by the server include a 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. This 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 facilitate subsequent faster determination of the shared key.

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

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

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

[0139] It can be understood that the embodiment 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-mentioned key exchange algorithm, thereby enhancing the protection of the private key in the national secret encryption and decryption certificate, thereby effectively improving security.

[0140] The following uses the TLS server as an example to illustrate the collaborative national secret TLS solution, wherein, for a TLS connection, since the cofactors and integer domain elements of the SM2 elliptic curve system parameters are fixed constants, the cofactors and integer domain elements are omitted in the embodiment of the present application for the convenience of explanation. For ease of understanding, further, please refer to Figure 5, which is a schematic diagram of a scenario of key exchange based on national secret TLS provided by the embodiment of the present application. As shown in Figure 5, the TLS initiator here (taking client B as an example) 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 the fixed private key fragment d B1 (i.e. the first fixed private key shard) and the fixed public key P B (i.e., the second fixed public key); the server can hold the fixed private key fragment d corresponding to the TLS responder B2 (i.e. the second fixed private key shard).

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

[0142] When the TLS initiator communicates with the TLS responder TLS, the TLS initiator can send a fixed public key P to the TLS responder. A and the temporary public key R A , so that the TLS responder can determine the shared key V through collaboration with the server.

[0143] It is understandable that the TLS responder receives the fixed public key P sent by the TLS initiator. A and the temporary public key R A Specifically, the specific method for the TLS responder (for example, client B) to determine the key fragment V1 can refer to the following formula (18): V1 = [d B1 ·r B ](P A +R A ) (18)

[0144] The TLS responder can then send a key exchange request to the server and send it the TLS initiator's fixed public key P A and the temporary public key R A The server receives the fixed public key P A and the temporary public key R A After that, the key fragment V2 can be determined. Specifically, the specific method for the server to determine the second key fragment V2 can refer to the following formula (19): V2 = [d B2 ](P A +R A ) (19)

[0145] Furthermore, when the TLS responder receives the key fragment V2 returned by the server, it can determine the shared key V based on the key fragment V1 and the key fragment V2, and derive the session key between the TLS initiator and the TLS responder based on the shared key V. The specific method for the TLS responder to determine the shared key V can be found in the following formula (20): V = V1 + V2 = [d B1 +d B2 +r B ](P A +R A ) (20)

[0146] Since the key exchange protocol is a process where two communicating parties (i.e. TLS initiator and TLS responder) use their own private keys and each other's public keys to agree on a secret key known only to them through interactive information transmission, the TLS responder also needs to send a fixed public key P to the TLS initiator. B and the temporary public key R B , so that the TLS initiator determines the shared key U, and derives the session key between the TLS initiator and the TLS responder based on the shared key U. The specific method for the TLS initiator to determine the shared key U can be referred to the following formula (21): U=[d A +r A ](P B +R B ) (twenty one)

[0147] It can be seen that the embodiment of the present application stores the private key fragments of the SM2 encryption certificate separately on the first communication party (i.e., the TLS responder) and the server without relying on hardware devices. Therefore, an attacker who only obtains the private key of one end cannot recover the complete private key, which effectively ensures the security of the private key storage. During the key exchange calculation process, the complete private key does not appear on either end. The first communication party and the server perform calculations using the fixed private key fragments they each hold, allowing the first communication party to obtain the secret complete elliptic curve point V, thereby effectively ensuring the security of the private key during use.

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

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

[0150] It's understandable that the TLS protocol is primarily divided into two layers: the bottom layer, the TLS Record Protocol, which is primarily responsible for encrypting messages using symmetric cryptography; and the upper layer, the TLS Handshake Protocol, which is primarily divided into four parts: the Handshake Protocol, the Cipher Specification Change Protocol, the Alert Protocol, and the Application Data Protocol. The Handshake Protocol is primarily responsible for agreeing on the cryptographic algorithm and shared secret key, including certificate authentication; the Cipher Specification Change Protocol is responsible for signaling a change in cryptographic methods to the communicating parties; the Alert Protocol is responsible for communicating errors to the other party; and the Application Data Protocol is responsible for conveying application data carried by TLS to the communicating parties.

[0151] As shown in FIG6 , the TLS initiator may send a first message (eg, a ClientHello message) to the TLS responder. The first message may include a client protocol version number, a cryptographic algorithm suite, a current time, a session identifier, and the like.

[0152] After receiving the first message, the TLS responder will return a series of messages to the TLS initiator, which may 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). The second message may generally include the protocol version number, the cipher suite, the current time, the session identifier, etc.; the third message may include the fixed public key of the TLS responder; the fourth message may include the temporary public key of the TLS responder; the fifth message may be used to request the TLS initiator to send a public key certificate; and the end message may be an identifier for the end of this message, used to inform the TLS initiator that its own message has ended.

[0153] At this point, the TLS initiator can obtain the TLS responder's fixed public key and the TLS responder's temporary public key, and then determine the shared key U based on the TLS initiator's fixed private key, the TLS responder's fixed public key and the TLS responder's temporary public key, and derive the session key.

[0154] Then, the TLS initiator needs to send a series of messages to the TLS responder, which may 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). The sixth message may contain 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 contain the temporary public key of the TLS initiator; the eighth message is an indicator of preparing to switch ciphers, which is a message of the cipher specification change protocol, used to indicate that 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 is over.

[0155] The TLS responder can obtain the fixed public key and the temporary public key of the TLS initiator, and then refer to the above formulas (13)-(15), based on the fixed private key fragment held by the TLS responder (for example, the fixed private key fragment d B1 ), the fixed public key of the TLS initiator and the fixed public key of the TLS initiator, to determine the first key fragment. Further, the TLS responder can send the fixed public key of the TLS initiator and the temporary public key of the TLS initiator to the server, so that the server can refer to the above formula (16) based on the fixed private key fragment corresponding to the TLS responder held by the server itself (for example, the fixed private key fragment d B2 ), and the two received public keys, to determine the second key fragment. The server can send the second key to the TLS responder.

[0156] When the TLS responder receives the second key fragment, 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 a ninth message (e.g., a ChangeCipherSpec message) and a handshake protocol end message to the TLS initiator. The ninth message is the same as the eighth message above, both of which are indicators of preparing to switch ciphers. It is a message of the cipher specification change protocol, which is used to indicate that 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.

[0157] At this point, both the TLS initiator and the TLS responder can encrypt the application messages to be transmitted based on their own derived session keys, thereby effectively ensuring the security of data transmission.

[0158] In another optional embodiment, the second communication party may also be a client in a collaborative relationship with the server. For ease of distinction, in this embodiment of the application, the server in a collaborative relationship with the second communication party may be referred to as the second server, and the server in a collaborative relationship with the first communication party may be referred to as the first server. The first server and the second server may be the same or different, and are not limited here.

[0159] When the first server and the second server are the same (for example, both are the server 100 shown in Figure 1), the second communication party and the first communication party both 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 are both positive integers.

[0160] For ease of understanding, please refer to Figure 7, which is a second interactive diagram of a key exchange method provided by an embodiment of the present application. As shown in Figure 7, the method can be jointly executed by the first communication party, the second communication party, the first server and the second server, wherein the first server here can hold fixed private key fragments corresponding to N communication parties, and these N communication parties include the first communication party, and the first communication party holds the first fixed private key fragment; and the second server can hold fixed private key fragments corresponding to M communication parties, and these M communication parties include the second communication party, and the second communication party holds the third fixed private key fragment. The method may at least include steps S701-S714:

[0161] Step S701: The second communication party sends a first fixed public key and a first temporary public key to the first communication party.

[0162] Among them, when the second communication party is client A, the first fixed public key here can be fixed public key P A Indicates that the first temporary public key can be used with the temporary public key R A Indicates that the temporary public key R A It is a temporary private key generated based on a random number generator (for example, a random number r A ) generated.

[0163] Step S702: 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.

[0164] Among them, the first fixed private key shard here can be fixed private key shard d B1It indicates that the first key shard here can be the elliptic curve point shard (for example, elliptic curve point shard V1) determined by the first communicating party based on the above formula (13).

[0165] Step S703: The first communication direction sends a first key exchange parameter to the first server.

[0166] The first key exchange parameter here may include a first fixed public key, a first temporary public key and a first index identifier (eg, index identifier B). The index identifier B is used to indicate the fixed private key fragment d B1 The fixed private key shard d held by the first server B2 Optionally, in order to save computing resources of the first server, the first key exchange parameter here may also include a combined temporary public key K A and the first index identifier, which will not be limited here.

[0167] Step S704: The first server determines a second fixed private key shard corresponding to the first fixed private key shard from the N fixed private key shards.

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

[0169] Step S705: The first server generates a second key fragment based on the second fixed private key fragment and the first key exchange parameter.

[0170] The second key shard may be an elliptic curve point shard (eg, elliptic curve point shard V2) determined by the first server based on the above formula (16).

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

[0172] Step S707: The first communication party determines a first shared key based on the first key fragment and the second key fragment.

[0173] The first shared key may be a complete elliptic curve point (eg, elliptic curve point V) determined by the first communicating party based on the above formula (17).

[0174] The specific implementation of steps S701-S707 can be found in the description of steps S401-S407 in the embodiment corresponding to FIG4 , and will not be repeated here.

[0175] Step S708: The first communication party sends the second fixed public key and the second temporary public key to the second communication party.

[0176] Among them, when the first communication party is client B, the first fixed public key here can be fixed public key P B Indicates that the first temporary public key can be used with the temporary public key R B Indicates that the temporary public key R B It is a temporary private key generated based on a random number generator (for example, a random number r B ) generated.

[0177] It is understandable that the second fixed public key here is generated by the first communication party in collaboration with the server. For example, the second fixed public key is determined by the above formula (4) based on the second random number (e.g., a2), the fourth random number (e.g., a1), the first random public key (e.g., B1), and the second random public key (e.g., B2). The first random public key is determined by the first random number (e.g., b1), 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., b2).

[0178] Step S709: The second communication party generates a third key fragment based on the second fixed public key, the second temporary public key, and the third fixed private key fragment.

[0179] The third fixed private key fragment here refers to the fixed private key fragment held by the second communication party (for example, fixed private key fragment d A1 ), the third key shard may be an elliptic curve point shard (e.g., elliptic curve point shard V3) determined by the second communicating party based on the above formulas (13)-(15).

[0180] Step S710: The second communication direction sends a second key exchange parameter to the second server.

[0181] The second key exchange parameter here may include a second fixed public key, a second temporary public key and a second index identifier (eg, index identifier A). The index identifier A is used to indicate the fixed private key fragment d A1 The fixed private key shard d held by the second server A2 Optionally, in order to save computing resources of the second server, the second key exchange parameter here may also include a combined temporary public key K B and a second index identifier, which will not be limited here.

[0182] In step S711, the second server determines a fourth fixed private key shard corresponding to the third fixed private key shard from the M fixed private key shards.

[0183] The fourth fixed private key fragment refers to another part of the fixed private key fragment of the second communication party held by the second server (for example, fixed private key fragment d A2 ).

[0184] Step S712: The second server generates a fourth key fragment based on the fourth fixed private key fragment and the second key exchange parameter.

[0185] The fourth key shard may be an elliptic curve point shard (eg, elliptic curve point shard V4) determined by the second server based on the above formula (16).

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

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

[0188] The second shared key here may be a complete elliptic curve point (eg, elliptic curve point U) determined by the second communication party based on the above formula (17).

[0189] The specific implementation of steps S708-S714 can also refer to the description of steps S401-S407 in the embodiment corresponding to FIG4 above, and will not be repeated here.

[0190] It can be understood that the embodiment of the present application can replace the ECDHE algorithm in the national secret TLS algorithm suite ECDHE-SM4-SM3 with a key exchange algorithm, thereby enhancing 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 (for example, the TLS responder), but also protect the fixed private key of the second communication party (for example, the TLS initiator), thereby effectively improving security.

[0191] The following describes the method provided in the embodiment of the present application from the perspective of a single network device in conjunction with the accompanying drawings.

[0192] Please refer to Figure 8, which is a flowchart of a key exchange process provided by an embodiment of the present application. As shown in Figure 8, the method can be executed by a first communication party (initiator or responder), the first communication party holds a first fixed private key fragment, and a service end having a collaborative relationship with the first communication party holds a second fixed private key fragment. The first fixed private key fragment and the second fixed private key fragment constitute the fixed private key of the first communication party. The method may at least include steps S801-S805:

[0193] Step S801: A first communication party receives a first fixed public key and a first temporary public key sent by a second communication party.

[0194] The first communication party and the second communication party may communicate via the Transport Layer Security (TLS) protocol.

[0195] Step S802: 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.

[0196] The first fixed private key fragment here refers to the fixed private key fragment held by the first communication party (for example, the fixed private key fragment d B1 ), where the first key shard can be the elliptic curve point shard (e.g., elliptic curve point shard V1) determined by the first communicating party based on the above formula (13).

[0197] It is understandable that in order to effectively ensure the security of private key storage, the embodiment of the present application can split the fixed private key of the SM2 encryption certificate into two parts, which are stored separately for the first communication party and the server, that is, the first communication party holds the first fixed private key fragment, and the server holds the second fixed private key fragment. Among them, the first fixed private key fragment here is determined by the first random number and the second random number, and the second fixed private key fragment is determined by the third random number and the fourth random number. The first random number and the fourth random number are both generated by the first communication party, and the second random number and the third random number are generated by the server. For example, in the key generation stage, the first random number can be represented by b1, the second random number can be represented by a2, the third random number can be represented by b2, and the fourth random number can be represented by a1.

[0198] The first communication party may send a third random number to the server, and the server may send a second random number to the first communication party. Upon receiving the second random number sent by the server, the first communication party may generate a first fixed private key fragment based on the first random number and the second random number. For example, the first communication party may 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 fragment.

[0199] Similarly, when the server receives the fourth random number sent by the first communication party, it can also generate the second fixed private key fragment 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 fragment.

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

[0201] Furthermore, the first communication party can refer to the above formula (4) and add the first result (i.e., the result of scalar point multiplication of the fourth random number and the second random public key) to the second result (i.e., the result of scalar point multiplication of the second random number and the first random public key) to generate a fixed public key of the communication party (i.e., the second fixed public key).

[0202] Similarly, the server can refer to the above formula (6) and add the first result (i.e., the result of scalar dot product of the fourth random number and the second random public key) to 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 communication party (i.e., the second fixed public key).

[0203] Step S803: The first communication direction sends key exchange parameters to the server.

[0204] Among them, the key exchange parameter is related to the first fixed public key and the first temporary public key. In the embodiment of the present application, N can be used to represent the number of fixed private key fragments held by the server. When N is 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 a combined temporary public key. The combined temporary public key is determined by the first communication party with reference 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 it can be a 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 corresponding relationship between the first fixed private key fragment and the fixed private key fragment corresponding to the first communication party held by the server (i.e., the second fixed private key fragment).

[0205] Step S804: The first communication party receives the second key fragment sent by the server.

[0206] The second key shard here can be the elliptic curve point shard (e.g., elliptic curve point shard V2) determined by the server based on the second fixed private key shard and the exchange parameters, as shown in the above formula (16). The second fixed private key shard refers to another part of the fixed private key shard of the first communication party held by the server (fixed private key shard d B2 ).

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

[0208] The shared key may be a complete elliptic curve point (e.g., elliptic curve point V) determined by the first communication party based on the above formula (17), and the shared key is used to derive a session key for communication between the first communication party and the second communication party.

[0209] The specific implementation of steps S801-S805 can be found in the description of steps S401-S407 in the embodiment corresponding to FIG4 , and will not be repeated here.

[0210] Further, please refer to Figure 9, which is a second flow diagram of a key exchange process provided by an embodiment of the present application. As shown in Figure 9, the method can be executed by a server, which holds fixed private key shards corresponding to N communication parties, where N is a positive integer, and the N communication parties include a first communication party, which holds a first fixed private key shard. The method can include at least steps S901-S904:

[0211] Step S901: The server receives key exchange parameters sent by the first communication party.

[0212] 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, where the combined temporary public key is generated based on the first temporary public key and the first fixed public key. In addition, the key exchange parameters also include an index identifier, which is used to indicate the corresponding relationship between the first fixed private key fragment and the second fixed private key fragment. Both the first fixed public key and the first temporary public key are held by the second communication party.

[0213] In step S902, the server determines a second fixed private key shard corresponding to the first fixed private key shard from the N fixed private key shards.

[0214] The first fixed private key fragment and the second fixed private key fragment constitute the fixed private key of the first communication party, that is, the second fixed private key fragment here refers to another part of the fixed private key fragment of the first communication party held by the server (for example, fixed private key fragment d B2 The second fixed private key fragment is determined by the server based on the fourth random number (e.g., a1) and the third random number (e.g., b2) with reference to the above formula (2). The fourth random number is sent by the first communication party, and the third random number is generated by the server.

[0215] Step S903: The server generates a second key fragment based on the second fixed private key fragment and the exchange parameters.

[0216] The second key shard may be an elliptic curve point shard (eg, elliptic curve point shard V2) determined by the server based on the above formula (16).

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

[0218] The specific implementation of steps S901-S904 can be found in the description of steps S403-S406 in the embodiment corresponding to FIG4 , and will not be repeated here.

[0219] Further, referring to Figure 10, Figure 10 is a schematic diagram of the structure of a key exchange device provided in an embodiment of the present application. As shown in Figure 10, the key exchange device 1 may include at least one of a transceiver module 1001 and a processing module 1002. These modules can perform the response functions of each device in the above method embodiment.

[0220] In a possible implementation, the key exchange device 1 can be used to implement the function of the first communication party.

[0221] Specifically, the transceiver module 1001 is used to receive the first fixed public key and the first temporary public key sent by the second communication party, the first fixed private key fragment is held by the first communication party, and the server end having a collaborative relationship with the first communication party holds the second fixed private key fragment; the processing module 1002 is used 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 1001 is also used to send key exchange parameters from the first communication direction to the server end, and the key exchange parameters are related to the first fixed public key and the first temporary public key; the transceiver module 1001 is also used to receive the second key fragment sent by the server end, and the second key fragment is generated based on the key exchange parameters and the second fixed private key fragment; the processing module 1002 is also 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.

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

[0223] In one implementation, the processing module 1002 is used by the first communicating 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 the 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.

[0224] 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 generated based on the first temporary public key and the first fixed public key.

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

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

[0227] 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.

[0228] The specific implementation of the transceiver module 1001 and the processing module 1002 can be found in the description of steps S801 to S805 in the embodiment corresponding to FIG8 , which will not be described in detail here.

[0229] Further, referring to Figure 11, Figure 11 is a second structural diagram of a key exchange device provided in an embodiment of the present application. As shown in Figure 11, 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 perform the response functions of the various devices in the above-described method embodiments.

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

[0231] The transceiver module 1101 is used to receive the key exchange parameters sent by the first communication party, where the key exchange parameters are related to the first fixed public key and the first temporary public key. The server holds fixed private key fragments corresponding to N communication parties, where 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; the determination module 1102 is used to determine the second fixed private key fragment corresponding to the first fixed private key fragment from the N fixed private key fragments; the generation module 1103 is used to generate a second key fragment based on the second fixed private key fragment and the key exchange parameters; the transceiver module 1101 is also used by the server to send the second key fragment to the first communication party.

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

[0233] 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 generated based on the first temporary public key and the first fixed public key.

[0234] 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.

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

[0236] The specific implementation of the transceiver module 1101, the determination module 1102, and the generation module 1103 can be found in the description of steps S901 to S904 in the embodiment corresponding to FIG9 , and will not be further described here. In addition, the description of the beneficial effects of adopting the same method will not be repeated.

[0237] The modules in the key exchange device 1 or the modules in the key exchange device 2 can be implemented via software or hardware. For example, the implementation of the transceiver module 1001 will be described below using the transceiver module 1001 as an example. Similarly, the implementation of the processing module 1002, the transceiver module 1101, the determination module 1102, and the generation module 1103 can refer to the implementation of the transceiver module 1001.

[0238] 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. Furthermore, 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 used to run the code may be distributed in the same region or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple geographically close data centers. Typically, a region may include multiple AZs.

[0239] Similarly, multiple hosts / virtual machines / containers running the code can be distributed within the same virtual private cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Cross-region communication between two VPCs within the same region, or between VPCs in different regions, requires a communication gateway within each VPC to interconnect the VPCs.

[0240] 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 be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0241] 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. The multiple computing devices can be any combination of servers, ASICs, PLDs, CPLDs, FPGAs, GALs, and other computing devices.

[0242] It should be noted that the transceiver module 1001 can be used to execute any step in the key exchange method shown in Figure 8, and the processing module 1002 can be used to execute any step in the above-mentioned key exchange method. The steps that the transceiver module 1001 and the processing module 1002 are responsible for implementing can be specified as needed. The full functions of the key exchange device 1 are realized by respectively implementing different steps in the key exchange method through the transceiver module 1001 and the processing module 1002.

[0243] Alternatively, in other embodiments, the transceiver module 1101 can be used to execute any step in the key exchange method shown in Figure 9, the determination module 1102 can be used to execute any step in the above-mentioned key exchange method, and the generation module 1103 can be used to execute any step in the above-mentioned key exchange method. The steps that the transceiver module 1101, the determination module 1102 and the generation module 1102 are responsible for implementing can be specified as needed. The full functions of the key exchange device 2 are realized by respectively implementing different steps in the key exchange method through the transceiver module 1001, the determination module 1102 and the generation module 1102.

[0244] Further, referring to Figure 12, Figure 12 is a schematic diagram of the structure of a key exchange system provided in an embodiment of the present application. As shown in Figure 12, the system includes a key exchange device 1 and a key exchange device 2, wherein the key exchange device 1 is used to implement the key exchange method shown in Figure 8 above, and the key exchange device 2 is used to implement the key exchange method shown in Figure 9 above.

[0245] The key exchange device 1 and the key exchange device 2 can be implemented by software or hardware. As an example, the implementation of the key exchange device 1 is described below. Similarly, the implementation of the key exchange device 2 can refer to the implementation of the key exchange device 1.

[0246] As an example of a software functional unit, a module, the key exchange device 1 may include code running on a computing instance. The computing instance may be at least one of a physical host (computing device), a virtual machine, a container and other computing devices. Furthermore, the above-mentioned computing device 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 used to run the application may be distributed in the same region or in different regions. The multiple hosts / virtual machines / containers used to run the code may be distributed in the same AZ or in different AZs, and each AZ includes a data center or multiple data centers with close geographical locations. Generally, a region may include multiple AZs.

[0247] Similarly, the multiple hosts / virtual machines / containers running the code can be distributed within the same VPC or across multiple VPCs. Typically, a VPC is located within a region. Cross-region communication between two VPCs within the same region, or between VPCs in different regions, requires a communication gateway within each VPC to interconnect the VPCs.

[0248] As an example of a hardware functional unit, the key exchange device 1 may include at least one computing device, such as a server. Alternatively, the key exchange device 1 may be implemented using an ASIC or a PLD. The PLD may be implemented using a CPLD, FPGA, GAL, or any combination thereof.

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

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

[0251] Bus 1302 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, among others. Buses may be classified as address buses, data buses, control buses, and the like. For ease of illustration, FIG13 shows a single line, but this does not imply a single bus or type of bus. Bus 1302 may include a path for transmitting information between various components of computing device 1300 (e.g., memory 1306, processor 1304, and communication interface 1308).

[0252] The processor 1304 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

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

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

[0255] Alternatively, in other embodiments, the memory 1306 stores executable program code, and the processor 1304 executes the executable program code to respectively implement the functions of the transceiver module 1101, the determination module 1102, and the generation module 1103 in the key exchange device 2, thereby implementing the key exchange method shown in FIG9 . That is, the memory 1306 stores instructions for executing the key exchange method.

[0256] 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 a communication network.

[0257] Embodiments of the present application also provide a computing device cluster. The computing device cluster includes at least one computing device. The computing device can 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 can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0258] Further, referring to Figure 14 , which is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application, as shown in Figure 14 , the computing device cluster includes at least one computing device 1400. The memory 1406 of one or more computing devices 1400 in the computing device cluster may store the same instructions for executing the key exchange method.

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

[0260] It should be noted that the memory 1406 in different computing devices 1400 in the computing device cluster can store different instructions, each used to execute part of the functions of the key exchange device 1. In other words, the instructions stored in the memory 1406 in different computing devices 1400 can implement the functions of one or more modules of the aforementioned transceiver module 1001 and processing module 1002 in the key exchange device 1.

[0261] Alternatively, in other embodiments, the memories 1406 in different computing devices 1400 in the computing device cluster may store different instructions, each for executing a portion of the functions of the key exchange apparatus 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 transceiver module 1101, determination module 1102, and generation module 1103 in the aforementioned key exchange apparatus 2.

[0262] In some possible implementations, one or more computing devices in a computing device cluster may be connected via a network, which may be a wide area network or a local area network.

[0263] Further, please refer to Figure 15, which is a schematic diagram of a structure of a network connection between computing devices provided by the present application. As shown in Figure 15, two computing devices 1400A and 1400B are connected via a network. Specifically, the connection to the network is made through the communication interface in each computing device. In this type of possible implementation, the memory 1406 in the computing device 1400A stores instructions for executing the functions of the above-mentioned transceiver module 1001 in the aforementioned key exchange device 1. At the same time, the memory 1406 in the computing device 1400B stores instructions for executing the functions of the processing module 1002 in the key exchange device 1.

[0264] Alternatively, in other embodiments, the memory 1406 of the computing device 1400A stores instructions for executing the functions of the aforementioned transceiver module 1101 in the key exchange apparatus 2. Simultaneously, the memory 1406 of the computing device 1400B stores instructions for executing the functions of the determination module 1102 and the generation module 1103 in the key exchange apparatus 2.

[0265] It should be understood that the functionality of the computing device 1400A shown in FIG15 may also be implemented by multiple computing devices 1400. Similarly, the functionality of the computing device 1400B may also be implemented by multiple computing devices 1400.

[0266] The present application also provides another computing device cluster. The connection relationship between the computing devices in this computing device cluster can be similar to the connection methods of the computing device clusters shown in Figures 13 and 14 . However, the memory 1406 in one or more computing devices 1400 in this computing device cluster can store the same instructions for executing the key exchange method.

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

[0268] It should be noted that the memory 1406 in different computing devices 1400 in the computing device cluster can store different instructions for executing partial functions of the key exchange system. In other words, the instructions stored in the memory 1406 in different computing devices 1400 can implement the functions of one or more modules in key exchange device 1 and key exchange device 2.

[0269] 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 be run on a computing device or stored on any available medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to execute the key exchange method or key exchange method described in the above embodiments.

[0270] The embodiments of the present application also provide a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center that contains one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the key exchange method or key exchange method in the above embodiment.

[0271] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions 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, and 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 shards 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 shard, 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, and 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