Key exchange method, system, electronic device, and storage medium
By constructing and decrypting the pre-master key in TLS 1.3 key exchange using the SM2 elliptic curve public key encryption algorithm, the problem of high complexity of Chinese cryptographic algorithms in TLS 1.3 is solved, and an efficient key exchange process is achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- CHINA FINANCIAL CERTIFICATION AUTHORITY
- Filing Date
- 2022-10-31
- Publication Date
- 2026-05-15
AI Technical Summary
In existing technologies, the TLS 1.3 key exchange method is highly complex when using Chinese cryptographic algorithms, requiring the generation of two temporary key pairs on both the client and server sides, resulting in cumbersome and complicated implementation.
The SM2 elliptic curve public key encryption algorithm is used. Through message exchange between the client and the server, a pre-master key is constructed based on random numbers and public key parameters, and then encrypted and decrypted to avoid modifying the KeyShare extension structure.
While ensuring security, the complexity of key exchange has been reduced, the support efficiency of national cryptographic algorithms has been improved, and the key exchange process has been simplified.
Smart Images
Figure CN115695003B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of network security technology, and in particular to key exchange methods, systems, electronic devices and storage media. Background Technology
[0002] The Chinese National Cryptographic Algorithm (CNCA) is a commercially used cryptographic algorithm prevalent in my country, encompassing SM2, SM3, and SM4. SM2 is an elliptic curve-based asymmetric encryption algorithm, SM3 is a data digest algorithm, and SM4 is a symmetric block encryption algorithm using 16-byte blocks. The public release of the CNCA provides a standard for the secure application of commercial cryptographic algorithms in China.
[0003] Transport Layer Security (TLS) is a widely used security protocol on the Internet, used to provide confidentiality and data integrity between two communicating applications. It is a standard for transport layer security. TLS has two layers: the TLS record protocol and the TLS handshake protocol. TLS 1.3 is one version of TLS 1.3, an update to the earlier TLS 1.2. Differences from TLS 1.2 include: the authentication and key exchange mechanisms in TLS 1.3 have been separated from the key suite, etc.
[0004] The complete TLS 1.3 protocol is defined in RFC 8446. A complete TLS 1.3 handshake uses the KeyShare extension to calculate the shared key. However, RFC 8446 does not define how to calculate the shared key based on Chinese cryptographic algorithms. While RFC 8998 defines a method for TLS 1.3 handshake negotiation based on Chinese cryptographic algorithms, it actually uses the ECDHE key exchange algorithm to calculate the shared key, not the Chinese cryptographic algorithm itself. In existing technologies, modifying the KeyShare extension structure and using the algorithm of the key exchange protocol defined by Chinese cryptographic algorithms to calculate the shared key requires generating two temporary key pairs on both the client and server sides, which is cumbersome and complex to implement.
[0005] In view of this, there is an urgent need to provide a TLS 1.3 key exchange method that supports Chinese national cryptographic algorithms, so as to reduce the complexity of key exchange while ensuring security. Summary of the Invention
[0006] To overcome the problems existing in related technologies, this application provides a key exchange method, system, electronic device and storage medium. The key exchange method can support national cryptographic algorithms, efficiently negotiate and obtain a pre-master key while ensuring security, and reduce the complexity of key exchange.
[0007] The first aspect of this application provides a key exchange method, including:
[0008] Receive the ClientHello message sent by the client. The ClientHello message contains the target curve that matches the national cryptographic algorithm, as well as the public key parameter in the key negotiation parameters corresponding to the target curve.
[0009] The pre-master key is constructed based on random numbers;
[0010] The pre-master key is encrypted based on the public key parameters and the target curve to obtain the pre-master key ciphertext.
[0011] A ServerHello message is sent back to the client, which contains the pre-master key ciphertext.
[0012] In one implementation, the target curve is an SM2 elliptic curve;
[0013] Encrypting the pre-master key based on public key parameters and the target curve includes:
[0014] The pre-master key is encrypted using the SM2 elliptic curve public key encryption algorithm with public key parameters;
[0015] Among them, the SM2 elliptic curve public key encryption algorithm is an encryption algorithm with the SM2 elliptic curve as its algorithm structure.
[0016] In one implementation, the pre-master key is constructed based on random numbers, including:
[0017] The pre-master key is constructed based on 48 bytes of random numbers.
[0018] A second aspect of this application provides a key exchange method, comprising:
[0019] The key negotiation parameters corresponding to at least one curve are determined based on at least one curve in the support curve list; wherein, the support curve list contains target curves that match the national cryptographic algorithm; and at least one key negotiation parameter contains public key parameters and private key parameters.
[0020] Generate a ClientHello message based on the list of supported curves and the public key parameter in at least one key negotiation parameter;
[0021] Send the ClientHello message to the server;
[0022] Receive the pre-master key ciphertext from the server;
[0023] The pre-master key ciphertext is decrypted based on the private key parameters to obtain the pre-master key plaintext.
[0024] In one implementation, a ClientHello message is generated based on a list of supported curves and a public key parameter from at least one key negotiation parameter, including:
[0025] An extension type identifier and extension type information are formed based on the list of supported curves and the public key parameter in at least one key negotiation parameter;
[0026] The ClientHello message is generated based on the extended type identifier and extended type information.
[0027] In one implementation, key negotiation parameters corresponding to at least one curve are determined based on at least one curve in a support curve list, wherein determining the key negotiation parameters corresponding to a target curve includes:
[0028] Determine the base point on the target curve;
[0029] Set the private key parameters;
[0030] The public key parameters are determined based on the base point and the private key parameters.
[0031] A third aspect of this application provides a key exchange system, comprising: a server and a client;
[0032] The server is used to execute the key exchange method as described in any one of the first aspects;
[0033] The client is used to perform the key exchange method as described in any of the second aspects.
[0034] The fourth aspect of this application provides an electronic device, including a processor and a memory storing a computer program, characterized in that the processor executes the computer program to implement the steps of the key exchange method described in any one of the first aspects, or to implement the steps of the key exchange method described in any one of the second aspects.
[0035] The fifth aspect of this application provides a non-transitory machine-readable storage medium having executable code stored thereon, which, when executed by a processor of an electronic device, implements the steps of the key exchange method described in any one of the first aspects, or implements the steps of the key exchange method described in any one of the second aspects.
[0036] The technical solution provided in this application may include the following beneficial effects:
[0037] The server receives a ClientHello message from the client. This message contains a target curve matching the national cryptographic algorithm and the public key parameter in the key negotiation parameters corresponding to the target curve. The server then constructs a pre-master key based on a random number and encrypts it using the public key parameter and the target curve to obtain the pre-master key ciphertext. The server sends a ServerHello message containing the pre-master key ciphertext back to the client. When the client receives the ServerHello message, it decrypts the pre-master key ciphertext using its private key parameter. This allows for efficient negotiation of the plaintext pre-master key without modifying the KeyShare extension structure or generating two temporary key pairs on both the client and server sides. This adds support for the national cryptographic algorithm while maintaining security and reducing the complexity of key exchange.
[0038] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description
[0039] The above and other objects, features, and advantages of exemplary embodiments of this application will become readily understood by reading the following detailed description with reference to the accompanying drawings. Several embodiments of this application are illustrated in the drawings by way of example and not limitation, and the same or corresponding reference numerals denote the same or corresponding parts.
[0040] Figure 1 This is a schematic flowchart illustrating the key exchange method in an embodiment of this application;
[0041] Figure 2 This is another schematic flowchart illustrating the key exchange method shown in the embodiments of this application;
[0042] Figure 3 This is a schematic diagram of the key exchange system shown in the embodiments of this application;
[0043] Figure 4 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application. Detailed Implementation
[0044] Embodiments will now be described with reference to the accompanying drawings. It should be understood that, for the sake of simplicity and clarity, reference numerals may be repeated in the drawings to indicate corresponding or similar elements where deemed appropriate. Furthermore, numerous specific details are set forth herein to provide a thorough understanding of the embodiments described herein. However, those skilled in the art will understand that the embodiments described herein can be practiced without these specific details. In other instances, well-known methods, processes, and components have not been described in detail so as not to obscure the embodiments described herein. Moreover, this description should not be construed as limiting the scope of the embodiments described herein.
[0045] The complete TLS 1.3 protocol is defined in RFC 8446. A complete TLS 1.3 handshake uses the KeyShare extension to calculate the shared key. However, RFC 8446 does not define how to calculate the shared key based on Chinese cryptographic algorithms. While RFC 8998 defines a method for TLS 1.3 handshake negotiation based on Chinese cryptographic algorithms, it actually uses the ECDHE key exchange algorithm to calculate the shared key, not the Chinese cryptographic algorithm itself. In existing technologies, modifying the KeyShare extension structure and using the algorithm of the key exchange protocol defined by Chinese cryptographic algorithms to calculate the shared key requires generating two pairs of temporary key pairs on both the client and server sides, which is cumbersome and complex. Therefore, there is an urgent need to provide a TLS 1.3 key exchange method that supports Chinese cryptographic algorithms to reduce the complexity of key exchange while ensuring security.
[0046] To address the aforementioned issues, this application provides a key exchange method that supports national cryptographic algorithms, efficiently negotiates and obtains a pre-master key while ensuring security, and reduces the complexity of key exchange.
[0047] The technical solutions of the embodiments of this application are described in detail below with reference to the accompanying drawings.
[0048] Figure 1 This is a flowchart illustrating the key exchange method shown in an embodiment of this application, used to explain the execution steps on the server side. Please refer to... Figure 1 The key exchange method illustrated in the embodiments of this application may include:
[0049] In step 101, the ClientHello message sent by the client is received.
[0050] The ClientHello message is a message sent by the client to the server in the TLS 1.3 handshake protocol to initiate a handshake request. The ClientHello message contains a target curve that matches the Chinese national cryptographic algorithm, and the public key parameter in the key negotiation parameters corresponding to the target curve. In this embodiment, the target curve that matches the Chinese national cryptographic algorithm is the SM2 elliptic curve. The SM2 elliptic curve public key encryption algorithm is an encryption algorithm based on the SM2 elliptic curve. Therefore, the key exchange method shown in this embodiment can support the SM2 elliptic curve public key encryption algorithm. SM2 is an asymmetric encryption algorithm based on elliptic curves in the Chinese national cryptographic algorithm.
[0051] In step 102, a pre-master key is constructed based on random numbers.
[0052] In this embodiment of the application, the random number can be a 48-byte random number. In actual application, it needs to be determined according to the actual application situation, and no unique limitation is made here.
[0053] For example, the data structure of the pre-master key can be as follows:
[0054] struct{
[0055] opaque random
[48] ;
[0056] PreMasterSecret;
[0057] Here, random is the random number, and PreMasterSecret is the premaster secret.
[0058] In step 103, the pre-master key is encrypted based on the public key parameters and the target curve.
[0059] In this embodiment, the pre-master key is encrypted using the SM2 elliptic curve public-key encryption algorithm with public key parameters to obtain the pre-master key ciphertext. For example, the encryption structure for encrypting the pre-master key using the SM2 elliptic curve public-key encryption algorithm with public key parameters can be as follows:
[0060] struct{
[0061] opaque SM2EncryptedPreMasterSecret<0..2^16-1>;
[0062] }SM2CipherEntry;
[0063] In this context, SM2EncryptedPreMasterSecret represents the premaster key ciphertext obtained by encrypting the premaster key using the public key parameters through the SM2 elliptic curve public key encryption algorithm, and SM2CipherEntry represents this encryption structure.
[0064] The ASN.1 definition of the data format encrypted by the SM2 algorithm is as follows:
[0065]
[0066] ASN.1 stands for Abstract Syntax Notation dotone, which is a standard for defining abstract data type forms and describing general data structures.
[0067] For details of the SM2 encryption algorithm, please refer to "GB / T 32918.4-2016 Information Security Technology SM2 Elliptic Curve Public Key Cryptography Algorithm: Public Key Encryption Algorithm".
[0068] In step 104, a ServerHello message is sent back to the client. The ServerHello message contains the pre-master key ciphertext.
[0069] In this embodiment of the application, the "extension_type" field of the ServerHello message is an extension of the "key_share" type, and the "extension_data" field contains the KeyShareServerHello value. When the server selects the target curve, i.e., the public key parameter corresponding to the SM2 elliptic curve, from the client_shares in the ClientHello message, the custom structure of KeyShareServerHello can be as follows:
[0070] struct{
[0071] SM2CipherEntry server_share<1..2^16-1>;
[0072] }KeyShareServerHello;
[0073] Figure 2 This is a flowchart illustrating the key exchange method shown in an embodiment of this application, used to explain the execution steps of the client. Please refer to... Figure 2 The key exchange method illustrated in the embodiments of this application may include:
[0074] In step 201, key negotiation parameters corresponding to at least one curve are determined based on at least one curve in the support curve list.
[0075] The curves described in this application's embodiments are generally elliptic curves because TLS 1.3 uses ECDHE to calculate the shared key. ECDHE stands for Elliptic Curve Diffie-Hellman Key Exchange. Under this protocol, the two parties use the Diffie-Hellman key exchange algorithm, employing a public and private key established by elliptic curve encryption, to establish secure shared encrypted data over an insecure channel. Therefore, the supported curve list carries elliptic curves that support key exchange. In particular, in this application's embodiments, the supported curve list includes target curves matching the national cryptographic algorithm, namely the SM2 elliptic curve.
[0076] At least one key negotiation parameter includes a public key parameter and a private key parameter. Taking the key negotiation parameter corresponding to the target curve, i.e., the SM2 elliptic curve, as an example, we can first select a point on the SM2 elliptic curve as a base point, denoted by G. Then, the client sets a private key parameter, denoted by k. Next, based on the base point G and the private key parameter k, we determine the public key parameter, denoted by P, where P = kG. It is understandable that in an elliptic curve, given k and G, calculating P using the addition rule is easy, but given P and G, calculating k is difficult.
[0077] In step 202, a ClientHello message is generated based on the list of supported curves and the public key parameter in at least one key negotiation parameter.
[0078] In this embodiment, an extension type identifier and extension type information are first formed based on the support curve list and the public key parameter in at least one key negotiation parameter. The extension type identifier includes Supported groups extension and Key Share extension.
[0079] Supported groups are extended to named groups of elliptic curves that support key exchange in the client, arranged from the most preferred elliptic curve to the least preferred elliptic curve. The "extension_data" field of the Supported groups extension contains the value "NamedGroupList". In this embodiment, the SM2 elliptic curve and its parameter value 0x0029 need to be added to NamedGroupList. For example, the structure of the Supported groups extension can be as follows:
[0080]
[0081]
[0082] Among them, SM2 Curve Groups are SM2 elliptic curves.
[0083] Additionally, the Key Share extension is used to carry at least one public key parameter corresponding to the curve. For example, the structure of the Key Share extension can be as follows:
[0084]
[0085] Wherein, group is the naming group of the elliptic curve used. Assuming that the elliptic curve used is the SM2 elliptic curve, its naming group uses the parameter value 0x0029; Key_exchange represents the key exchange message. The content of the Key_exchange field is determined by the specified naming group and its corresponding definition.
[0086] Furthermore, the "extension_data" field in the Key Share extension contains the value "KeyShareClientHello". In this embodiment, for example, the field structure of KeyShareClientHello can be as follows:
[0087] struct{
[0088] KeyShareEntry client_shares<1..2^16-1>;
[0089] }KeyShareClientHello;
[0090] Here, `client_shares` is a list of KeyShareEntry values provided in descending order according to client preferences. Each KeyShareEntry value must correspond to each named group provided in the Supported groups extension and must be presented in the same order to achieve a one-to-one correspondence. However, these KeyShareEntry values can be non-contiguous subsets of the Supportedgroups extension. Clients can provide any number of KeyShareEntry values to form the KeyShareEntry value list. Each KeyShareEntry value represents a set of key exchange parameters, which can be understood as public key parameters. The `key_exchange` value in each KeyShareEntry value must be generated independently, and clients may not provide multiple KeyShareEntry values for the same named group. In this embodiment, `client_shares`, i.e., the list of KeyShareEntry values, must contain KeyShareEntry values corresponding to the SM2 elliptic curve, i.e., public key parameters corresponding to the SM2 elliptic curve.
[0091] It is understood that the extension type information may include, but is not limited to, the "extension_data" field of the Supported groups extension and the "extension_data" field of the Key Share extension. Furthermore, a ClientHello message is generated based on the extension type identifier and the extension type information. The extension structure in the ClientHello message is composed of the extension type identifier and the extension type information. For example, the extension structure of the ClientHello message can be as follows:
[0092]
[0093]
[0094] Among them, extension_type is the extension type identifier, and extension_data is the extension type information.
[0095] In step 203, the ClientHello message is sent to the server.
[0096] In step 204, the pre-master key ciphertext is received from the server.
[0097] In step 205, the pre-master key ciphertext is decrypted based on the private key parameters.
[0098] By decrypting the pre-master key ciphertext using the private key parameters, the plaintext of the pre-master key can be obtained, thus enabling the negotiation of the pre-master key, which is the shared key. The pre-master key is the source of the master key calculation.
[0099] The server receives ClientHello messages from the client. These messages contain a target curve matching the national cryptographic algorithm and the public key parameter from the key negotiation parameters corresponding to the target curve. The server then constructs a pre-master key based on a random number and encrypts it using the public key parameter and the target curve to obtain the pre-master key ciphertext. The server sends a ServerHello message containing the pre-master key ciphertext back to the client. Upon receiving the ServerHello message, the client decrypts the pre-master key ciphertext using its private key parameter. This allows for efficient negotiation of the plaintext pre-master key without modifying the KeyShare extension structure or generating two temporary key pairs on both the client and server sides. This adds support for the national cryptographic algorithm while maintaining security and reducing the complexity of key exchange.
[0100] Corresponding to the aforementioned application function implementation method embodiments, this application also provides a key exchange system and corresponding embodiments.
[0101] Figure 3 This is a schematic diagram of the key exchange system shown in the embodiments of this application. Please refer to [link / reference]. Figure 3 The key exchange system shown in this application embodiment may include: server 301 and client 302.
[0102] The server 301 is configured to: receive a ClientHello message sent by the client, which contains a target curve matching the national cryptographic algorithm and the public key parameter in the key negotiation parameters corresponding to the target curve; construct a pre-master key based on a random number; encrypt the pre-master key based on the public key parameter and the target curve to obtain the pre-master key ciphertext; and send a ServerHello message to the client, which contains the pre-master key ciphertext.
[0103] In some embodiments, the target curve is an SM2 elliptic curve, and the server 301 can be configured to encrypt the pre-master key using the public key parameters through the SM2 elliptic curve public key encryption algorithm; wherein, the SM2 elliptic curve public key encryption algorithm is an encryption algorithm with the SM2 elliptic curve as its algorithm structure.
[0104] In some embodiments, server 301 can be configured to construct a pre-master key based on a 48-byte random number.
[0105] Additionally, the client 302 is configured to: determine key negotiation parameters corresponding to at least one curve based on at least one curve in the supported curve list; wherein, the supported curve list contains target curves that match the national cryptographic algorithm; each of the at least one key negotiation parameter contains a public key parameter and a private key parameter; generate a ClientHello message based on the supported curve list and the public key parameter in the at least one key negotiation parameter; send the ClientHello message to the server; receive the pre-master key ciphertext fed back by the server; and decrypt the pre-master key ciphertext based on the private key parameter to obtain the pre-master key plaintext.
[0106] In some embodiments, client 302 may be configured to: form an extension type identifier and extension type information based on the supported curve list and the public key parameter in at least one key negotiation parameter; and generate a ClientHello message based on the extension type identifier and extension type information.
[0107] In some embodiments, client 302 may be configured to: determine a base point on the target curve; set private key parameters; and determine public key parameters based on the base point and the private key parameters.
[0108] The server receives ClientHello messages from the client. These messages contain a target curve matching the national cryptographic algorithm and the public key parameter from the key negotiation parameters corresponding to the target curve. The server then constructs a pre-master key based on a random number and encrypts it using the public key parameter and the target curve to obtain the pre-master key ciphertext. The server sends a ServerHello message containing the pre-master key ciphertext back to the client. Upon receiving the ServerHello message, the client decrypts the pre-master key ciphertext using its private key parameter. This allows for efficient negotiation of the plaintext pre-master key without modifying the KeyShare extension structure or generating two temporary key pairs on both the client and server sides. This adds support for the national cryptographic algorithm while maintaining security and reducing the complexity of key exchange.
[0109] Regarding the system in the above embodiments, the specific methods by which the server and client perform operations have been described in detail in the embodiments related to the method, and will not be elaborated further here.
[0110] Corresponding to the aforementioned application function implementation method embodiments, this application also provides an electronic device for performing a key exchange method and corresponding embodiments.
[0111] Figure 4 A block diagram illustrating the hardware configuration of an electronic device 800 capable of implementing the key exchange method of embodiments of this application is shown. Figure 4 As shown, the electronic device 800 may include a processor 810 and a memory 820. Figure 4 In the electronic device 800, only the components relevant to this embodiment are shown. Therefore, it will be apparent to those skilled in the art that the electronic device 800 may also include components related to... Figure 4 The following are common components with different constituent elements, such as fixed-point arithmetic units.
[0112] Electronic device 800 can correspond to a computing device with various processing functions, such as functions for generating neural networks, training or learning neural networks, quantizing floating-point neural networks into fixed-point neural networks, or retraining neural networks. For example, electronic device 800 can be implemented as various types of devices, such as personal computers (PCs), server devices, mobile devices, etc.
[0113] The processor 810 controls all functions of the electronic device 800. For example, the processor 810 controls all functions of the electronic device 800 by executing programs stored in the memory 820 on the electronic device 800. The processor 810 can be implemented by a central processing unit (CPU), graphics processing unit (GPU), application processor (AP), artificial intelligence processor chip (IPU), etc., provided in the electronic device 800. However, this application is not limited to this.
[0114] In some embodiments, processor 810 may include an input / output (I / O) unit 811 and a computing unit 812. I / O unit 811 may be used to receive various types of data, such as a ClientHello message sent by a client and received by the server. Exemplarily, computing unit 812 may be used to encrypt a pre-master key using the public key parameter in the ClientHello message received via I / O unit 811 to determine the pre-master key ciphertext. This pre-master key ciphertext may, for example, be output by I / O unit 811. The output data may be provided to memory 820 for use by other devices (not shown), such as client devices, or may be directly provided to other devices, such as client devices.
[0115] Memory 820 is hardware used to store various data processed in electronic device 800. For example, memory 820 can store processed data and data to be processed in electronic device 800. Memory 820 can store data involved in the key exchange method process that has been processed or is to be processed by processor 810. In addition, memory 820 can store applications, drivers, etc. to be driven by electronic device 800. For example, memory 820 can store various programs related to the key exchange method to be executed by processor 810. Memory 820 can be DRAM, but this application is not limited to it. Memory 820 can include at least one of volatile memory or non-volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, phase-change RAM (PRAM), magnetic RAM (MRAM), resistive RAM (RRAM), ferroelectric RAM (FRAM), etc. Volatile memory may include dynamic RAM (DRAM), static RAM (SRAM), synchronous DRAM (SDRAM), PRAM, MRAM, RRAM, ferroelectric RAM (FeRAM), etc. In an embodiment, memory 820 may include at least one of hard disk drive (HDD), solid-state drive (SSD), high-density flash memory (CF), secure digital card (SD), micro-secure digital card (Micro-SD), mini-secure digital card (Mini-SD), extreme digital card (xD), cache, or memory stick.
[0116] In summary, the specific functions implemented by the memory 820 and processor 810 of the electronic device 800 provided in the embodiments of this specification can be explained in comparison with the foregoing embodiments in this specification, and can achieve the technical effects of the foregoing embodiments. Therefore, they will not be repeated here.
[0117] In this embodiment, the processor 810 can be implemented in any suitable manner. For example, the processor 810 can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) that can be executed by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers, etc.
[0118] It should be understood that the possible terms "first" or "second," etc., in the claims, specification, and drawings disclosed in this application are used to distinguish different objects, rather than to describe a specific order. The terms "comprising" and "including" used in the specification and claims disclosed in this application indicate the presence of the described features, integrals, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof.
[0119] It should also be understood that the terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to limit the scope of this disclosure. As used in this disclosure and claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this disclosure and claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes such combinations.
[0120] Although the embodiments of this application are described above, the content is merely an example adopted for the purpose of facilitating understanding of this application and is not intended to limit the scope and application scenarios of this application. Any person skilled in the art described in this application may make any modifications and changes in the form and details of the implementation without departing from the spirit and scope disclosed in this application, but the scope of patent protection of this application shall still be determined by the scope defined in the appended claims.
[0121] It should also be understood that any module, unit, component, server, computer, terminal, or device that executes the instructions executorized herein may include or otherwise access computer-readable media, such as storage media, computer storage media, or data storage devices (removable) and / or non-removable) such as disks, optical discs, or magnetic tapes. Computer storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable instructions, data structures, program modules, or other data.
Claims
1. A key exchange method, characterized in that, include: Server-side execution: Receive a ClientHello message sent by the client, the ClientHello message containing a target curve that matches the national cryptographic algorithm, and the public key parameter in the key negotiation parameters corresponding to the target curve; The pre-master key is constructed based on random numbers; The pre-master key is encrypted based on the public key parameters and the target curve to obtain the pre-master key ciphertext. A ServerHello message is sent back to the client, the ServerHello message containing the pre-master key ciphertext; Client execution: The key negotiation parameters corresponding to at least one curve are determined based on at least one curve in the support curve list; wherein, the support curve list contains target curves that match the national cryptographic algorithm; and the at least one key negotiation parameter includes public key parameters and private key parameters. Generate a ClientHello message based on the list of supported curves and the public key parameter in at least one key negotiation parameter; Send the ClientHello message to the server; Receive the pre-master key ciphertext fed back by the server; The pre-master key ciphertext is decrypted based on the private key parameters to obtain the pre-master key plaintext.
2. The key exchange method according to claim 1, characterized in that, The target curve being executed on the server side is an SM2 elliptic curve; The encryption of the pre-master key based on the public key parameters and the target curve includes: The pre-master key is encrypted using the SM2 elliptic curve public key encryption algorithm with the public key parameters. The SM2 elliptic curve public key encryption algorithm is an encryption algorithm based on the SM2 elliptic curve as its algorithm structure.
3. The key exchange method according to claim 1, characterized in that, The process of constructing a pre-master key based on random numbers during server-side execution includes: The pre-master key is constructed based on a 48-byte random number.
4. The key exchange method according to claim 1, characterized in that, The client execution generates a ClientHello message based on the supported curve list and at least one public key parameter in the key negotiation parameters, including: Based on the list of supported curves and the public key parameter in at least one key negotiation parameter, an extension type identifier and extension type information are formed; The ClientHello message is generated based on the extended type identifier and the extended type information.
5. The key exchange method according to claim 4, characterized in that, The client execution of determining key negotiation parameters corresponding to at least one curve based on at least one curve in the supported curve list, wherein determining the key negotiation parameters corresponding to the target curve includes: Determine a base point on the target curve; Set the private key parameters; The public key parameters are determined based on the base point and the private key parameters.
6. An electronic device comprising a processor and a memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the key exchange method according to any one of claims 1 to 5.
7. A non-transitory machine-readable storage medium having executable code stored thereon, which, when executed by a processor of an electronic device, implements the steps of the key exchange method according to any one of claims 1 to 5.