Method, device and readable storage medium for processing a national secret handshake request

Abstract

Embodiments of the present application provide a kind of national secret handshake request processing method, equipment and readable storage medium, after node server receives the national secret handshake request from terminal device, when needing to use private key in the process of executing handshake procedure for national secret handshake request, suspend handshake procedure and send the request message carrying to-be-processed data to private key server.Private key server processes to-be-processed data using private key to obtain target data, constructs response message according to target data and sends to node server.Node server recovers handshake procedure according to target data, and with terminal device continues the handshake procedure of following down.Using this kind of scheme, without customer providing the private key corresponding to national secret certificate, national secret handshake request processing can also be completed without sensing, improve the application scope of national secret HTTPS protocol, improve business security.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method, device and readable storage medium for processing Chinese cryptographic handshake requests. Background Technology

[0002] With the rapid development of internet technology, users have placed higher demands on the security of network communication. Therefore, Hypertext Transfer Protocol Secure (HTTPS) has been adopted by an increasing number of websites.

[0003] HTTPS is a Hypertext Transfer Protocol (HTTP) designed for security. It achieves data encryption, integrity verification, and tamper protection by adding Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocols to HTTP. The protocols used in internationally adopted HTTPS are called international protocols, and the encryption algorithms used are called international algorithms. my country's HTTPS uses the national standard SSL (GMSSL) and domestically developed commercial cryptographic algorithms, often simply referred to as national standard algorithms. When using national standard HTTPS, after the client and server establish a TCP connection, they negotiate and establish a secure connection, such as an SSL or TLS connection, through a handshake. Afterward, the client and server can use this secure connection to exchange data.

[0004] Typically, a private key is required during the handshake process. However, some customers are unwilling to disclose their sensitive private keys, leading to handshake failures and the inability to establish a secure connection, which in turn prevents business operations from taking place. Summary of the Invention

[0005] This application provides a method, device, and readable storage medium for processing national cryptographic handshake requests. By providing a solution that eliminates the need for private key interaction between the client and the node server, the national cryptographic handshake request can be processed seamlessly even if the client does not provide the private key corresponding to the national cryptographic certificate. This improves the applicability of national cryptographic HTTPS and enhances business security.

[0006] In a first aspect, embodiments of this application provide a method for processing Chinese cryptographic handshake requests, applied to a node server, the method comprising:

[0007] Receive a national cryptographic handshake request from the terminal device;

[0008] When a private key is required to perform the handshake process in response to the national cryptographic handshake request, the handshake process is suspended.

[0009] Send a request message carrying the data to be processed to the private key server, so that the private key server can use the private key to process the data to be processed and obtain the target data;

[0010] Receive a response message from the private key server carrying the target data;

[0011] The handshake process is restored based on the target data.

[0012] Secondly, embodiments of this application provide a method for processing national cryptographic handshake requests, applied to a private key server, the method comprising:

[0013] Receive a request message from the node server carrying data to be processed. The request message is sent by the node server after suspending the handshake process when it needs to use a private key to perform the handshake process in response to the national cryptographic handshake request.

[0014] The data to be processed is processed using a private key to obtain the target data;

[0015] Send a response message carrying the target data to the node server.

[0016] Thirdly, embodiments of this application provide a processing apparatus for Chinese cryptographic handshake requests, said apparatus being integrated on a node server, the apparatus comprising:

[0017] The receiving module is used to receive national cryptographic handshake requests from terminal devices;

[0018] The processing module is used to suspend the handshake process when the handshake process for the national cryptographic handshake request requires the use of a private key;

[0019] The sending module is used to send a request message carrying the data to be processed to the private key server, so that the private key server can use the private key to process the data to be processed and obtain the target data.

[0020] The receiving module is further configured to receive a response message carrying the target data from the private key server;

[0021] The processing module is used to recover the handshake process based on the target data.

[0022] Fourthly, embodiments of this application provide a processing device for a national cryptographic handshake request, integrated on a private key server, the device comprising:

[0023] The receiving module is used to receive a request message from the node server carrying data to be processed. The request message is sent by the node server after suspending the handshake process when it needs to use a private key to perform the handshake process in response to the national cryptographic handshake request.

[0024] The processing module is used to process the data to be processed using a private key to obtain the target data;

[0025] The sending module is used to send a response message carrying the target data to the node server.

[0026] Fifthly, embodiments of this application provide an electronic device, including: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it causes the electronic device to implement the method described in the first aspect or various possible implementations of the first aspect.

[0027] In a sixth aspect, embodiments of this application provide an electronic device, including: a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the electronic device implements the method described in the second aspect above or various possible implementations of the second aspect.

[0028] In a seventh aspect, embodiments of this application provide a computer-readable storage medium storing computer instructions that, when executed by a processor, are used to implement the method described in the first aspect or various possible implementations of the first aspect.

[0029] Eighthly, embodiments of this application provide a computer-readable storage medium storing computer instructions that, when executed by a processor, are used to implement the method described in the second aspect above or various possible implementations of the second aspect.

[0030] Ninthly, embodiments of this application provide a computer program product comprising a computing program, wherein when the computer program is executed by a processor, it implements the method described in the first aspect or various possible implementations of the first aspect.

[0031] In a tenth aspect, embodiments of this application provide a computer program product comprising a computing program, wherein when the computer program is executed by a processor, it implements the method described in the second aspect above or various possible implementations of the second aspect.

[0032] The method, apparatus, and readable storage medium for processing Chinese cryptographic handshake requests provided in this application embodiment allow a node server to receive a Chinese cryptographic handshake request from a terminal device. During the handshake process, when a private key is required, the node server suspends the handshake process and sends a request message carrying data to be processed to a private key server. The private key server processes the data to be processed using its private key to obtain target data, constructs a response message based on the target data, and sends it to the node server. The node server then resumes the handshake process based on the target data and continues the subsequent handshake process with the terminal device. This approach eliminates the need for the customer to provide the private key corresponding to the Chinese cryptographic certificate, enabling seamless processing of Chinese cryptographic handshake requests, expanding the applicability of the Chinese cryptographic HTTPS protocol, and enhancing business security. Furthermore, regardless of whether the customer provides a private key, the CPU-intensive private key processing in the handshake process is transferred to the private key server, thereby increasing the concurrency of Chinese cryptographic handshake requests and the overall throughput of the machine, reducing the CPU and other resource consumption of the node server, and not affecting concurrent requests for Chinese cryptographic protocols or international protocols. Attached Figure Description

[0033] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0034] Figure 1 This is a schematic diagram of the network architecture of a method for processing Chinese cryptographic handshake requests provided in an embodiment of this application;

[0035] Figure 2 This is a flowchart of a method for processing national cryptographic handshake requests provided in an embodiment of this application;

[0036] Figure 3 This is another flowchart of the method for processing national cryptographic handshake requests provided in the embodiments of this application;

[0037] Figure 4 This is another flowchart of the method for processing the national cryptographic handshake request provided in the embodiments of this application;

[0038] Figure 5 This is a functional block diagram of the node server in the method for processing national cryptographic handshake requests provided in the embodiments of this application;

[0039] Figure 6 This is a schematic diagram of a network architecture to which the national cryptographic handshake request processing method provided in this application embodiment applies;

[0040] Figure 7A schematic diagram of a processing device for a national cryptographic handshake request provided in an embodiment of this application;

[0041] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0043] Currently, based on the protocols and algorithms used in HTTPS transmission, HTTPS transmission can be divided into international HTTPS transmission and Chinese national cryptographic (CN) HTTPS transmission. International HTTPS transmission uses international protocols and algorithms, while CN HTTPS transmission uses CN cryptographic protocols and algorithms. International protocols refer to standard protocols such as TLS and SSL, and international algorithms include algorithms such as RSA. CN cryptographic protocols are identified by GMSSL and employ a dual-certificate TLS protocol. The dual-certificate TLS protocol mainly introduces encryption and signing certificates in the SSL handshake process and makes some modifications to the TLSv1.1 handshake process to accommodate the dual-certificate structure. CN cryptographic algorithms include the SM series of algorithms.

[0044] Because Chinese cryptographic algorithms are often considered more secure, many websites in my country use HTTPS with Chinese cryptographic protocols and algorithms. When using HTTPS with Chinese cryptographic protocols, the client and server establish a Transmission Control Protocol (TCP) connection through a three-way handshake. They then negotiate and establish a secure connection, also known as an encrypted connection, such as an SSL or TLS connection. Afterward, the client and server can exchange data using this secure connection.

[0045] When using the Chinese national cryptographic standard (CNAS) for HTTPS, the CNAS protocol requires a dual-certificate system. The dual certificates include a signing certificate and an encryption certificate, along with the private keys for both certificates. During the handshake process, the private key corresponding to the signing certificate is used for signing, and the private key corresponding to the encryption certificate is used for decryption. The private keys corresponding to the signing and encryption certificates are collectively referred to as the private key information corresponding to the CNAS certificate. Some customers are sensitive to this private key information and are unwilling to provide it to distributed cluster vendors. This prevents the client and the node servers of the distributed cluster from completing the handshake process, thus preventing these customers from using CNAS for HTTPS data transmission, resulting in poor data security and low efficiency. Distributed clusters can be used in edge scheduling systems, such as CDN networks, where the node servers are CDN nodes within the CDN network.

[0046] Furthermore, some clients, lacking sensitivity to private key information, will provide it to the distributed cluster. In this case, during the handshake process, the node servers in the distributed cluster use the private key corresponding to the signing certificate to sign the data and the private key corresponding to the encryption certificate to decrypt the data. However, these operations consume significant CPU and other resources of the node servers, resulting in high resource overhead and severely impacting concurrent requests for international or national cryptographic protocols, potentially even causing the node servers to crash.

[0047] Based on this, embodiments of this application provide a method, device, and readable storage medium for processing national cryptographic handshake requests. By providing a solution for non-private key interaction between terminal devices and node servers, the processing of national cryptographic handshake requests can be completed seamlessly without the customer providing the private key corresponding to the national cryptographic certificate, thereby improving the applicability of the national cryptographic HTTPS protocol and enhancing business security.

[0048] Figure 1 This is a network architecture diagram illustrating a method for processing Chinese cryptographic handshake requests provided in an embodiment of this application. Please refer to... Figure 1 The network architecture includes: node server 11, terminal device 12, private key server 131, private key server 132, and origin server 14. Node server 11 establishes a network connection with terminal device 12, and also establishes network connections with each private key server and origin server 14. Each private key server and origin server 14 are collectively referred to as a backend server. When node server 11 interacts with terminal device 12, terminal device 12 acts as the client, and node server 11 acts as the server. When node server 11 interacts with either the private key server or origin server 14, node server 11 acts as the client, and the private key server and origin server 14 act as the server. In other words, node server 11 combines the dual roles of client and server.

[0049] Node server 11 is, for example, a node built based on NGINX with OpenSSL or NGINX with Boring. Additionally, the solution provided in this application embodiment can also be applied to gateways, such as gateways built based on NGINX with OpenSSL or NGINX with Boring.

[0050] Private key servers 131 and 132 are deployed in different networks. For example, private key server 131 and node server 11 are deployed in the same network, and are nodes in the distributed cluster that are not directly exposed to the outside world. They are deployed near node server 11 to share the computing power of node server 11. In this case, some clients who are not sensitive to private key information provide private key information to node server 11. Node server 11 can obtain the private key information, but some operations using the private key in the handshake process do not need to be performed by node server 11. Instead, they are performed by private key server 131, which is deployed near node server 11. This reduces the consumption of CPU and other resources of node server 11, increases the throughput of national cryptographic handshake requests, and does not affect the concurrent requests of non-national cryptographic protocols.

[0051] Private key server 132 and node server 11 are deployed on different networks, with private key server 132 often located on the customer's own network. For example, customers such as banks are sensitive to private key information, so they deploy their private key information on private key server 132 within their own network. During the handshake process, when the private key is needed, node server 11 sends the data to be processed to private key server 132 on the customer's network, and private key server 132 uses the private key to process the data.

[0052] After terminal device 12 and node server 11 successfully establish a secure connection through a handshake, they can exchange data using this secure connection. Because node server 11 caches resources on origin server 14 and is located very close to terminal device 12, terminal device 12 can quickly obtain resources through the secure connection. These resources include web pages, images, audio, and video. When resources stored on origin server 14 are refreshed, node server 11 also refreshes its resources to ensure that it stores the latest available resources.

[0053] Please refer to Figure 1 In this embodiment of the application, the node server 11 provides a framework for custom protocol interaction with the private key server. Based on this framework, the node server 11 has functions such as constructing request messages, parsing response messages, connection management, DNS resolution, retry and timeout mechanisms.

[0054] It should be understood that, Figure 1 The number of node servers 11, terminal devices 12, private key servers 131, private key servers 132, and source servers 14 shown in the diagram is merely illustrative. In actual implementation, any number of node servers 11, terminal devices 12, private key servers 131, private key servers 132, and source servers 14 can be deployed according to actual needs.

[0055] Below, based on Figure 1The network architecture shown illustrates the detailed method for processing national cryptographic handshake requests provided in this application embodiment. For example, please refer to... Figure 2 . Figure 2 This is a flowchart illustrating a method for processing a national cryptographic handshake request provided in this application embodiment. This embodiment describes the process from the perspective of interaction between a terminal device, a node server, and a private key server. This embodiment includes:

[0056] 201. Receive the national cryptographic handshake request from the terminal device.

[0057] To implement the use of HTTPS (China's national standard for cryptography), after the terminal device and the node server establish a TCP connection through a three-way handshake, the terminal device does not immediately send requests for specific resources through the TCP connection. Instead, the terminal device and the node server negotiate to establish a secure connection through a handshake, also known as an encrypted connection, SSL connection, or TLS connection. Only after the handshake successfully establishes a secure connection can the terminal device and the node server exchange data through the secure connection.

[0058] In this step, after the terminal device and the node server establish a TCP connection, the terminal device sends a Chinese cryptographic handshake request to the node server to initiate the handshake process. This Chinese cryptographic handshake request can be, for example, a client hello message.

[0059] 202. When the handshake process for the national cryptographic handshake request requires the use of a private key, the handshake process is suspended.

[0060] After receiving the complete client hello message, the node server executes the subsequent actions of the handshake process. When the private key is needed, the node server suspends the current handshake process, that is, it temporarily suspends the handshake process.

[0061] 203. Send a request message carrying the data to be processed to the private key server.

[0062] When the private key is needed, the node server constructs a request message based on the data to be processed. After suspending the handshake process, the node server sends the request message to the private key server. The private key server then receives the request message.

[0063] 204. Use the private key to process the data to be processed to obtain the target data.

[0064] In this embodiment of the application, the national cryptographic protocol uses a dual certificate system, which includes a signature certificate and an encryption certificate, as well as the private key of the signature certificate and the private key of the encryption certificate.

[0065] Private key servers pre-store private keys, such as those for signing certificates and encryption certificates. For example, within a distributed cluster network, operations personnel might deploy customer-provided, insensitive private keys on these servers, rather than on node servers. Alternatively, the private key server might be located within a customer's network. The customer may be unwilling to provide their private keys to the distributed cluster, so they deploy sensitive private keys on their own network's private key server, rather than on node servers or the distributed cluster's private key server.

[0066] When the private key server receives the request message, it uses the private key to process the data to be processed in order to obtain the target data.

[0067] 205. Send a response message carrying the target data to the node server.

[0068] After obtaining the target data, the private key server constructs a response message using the target data and sends it to the node server. Correspondingly, the node server receives the response message from the private key server.

[0069] 206. Restore the handshake process based on the target data.

[0070] After receiving the response message, the node server sets the target data into the current handshake state and resumes the handshake process.

[0071] As can be seen from the above, the private key-free interaction process of the Chinese cryptographic standard is an asynchronous process. When the private key is needed, the handshake process is suspended, which does not affect or block other requests.

[0072] The method for processing Chinese cryptographic handshake requests provided in this application embodiment involves a node server receiving a Chinese cryptographic handshake request from a terminal device. During the handshake process, when a private key is required, the handshake process is suspended, and a request message carrying data to be processed is sent to the private key server. The private key server processes the data to be processed using its private key to obtain the target data, constructs a response message based on the target data, and sends it to the node server. The node server resumes the handshake process based on the target data and continues the subsequent handshake process with the terminal device. This approach eliminates the need for the client to provide the private key corresponding to the Chinese cryptographic certificate, enabling seamless processing of Chinese cryptographic handshake requests, expanding the applicability of the Chinese cryptographic HTTPS protocol, and enhancing business security. Furthermore, regardless of whether the client provides a private key, the CPU-intensive private key processing in the handshake process is transferred to the private key server, thereby increasing the concurrency of Chinese cryptographic handshake requests and the overall throughput of the machine, reducing the CPU and other resource consumption of the node server, and not affecting concurrent requests for Chinese cryptographic protocols or international protocols.

[0073] In this embodiment, the Chinese cryptographic protocol uses a dual-certificate system, comprising a signature certificate and an encryption certificate, along with the private keys of the signature certificate and the encryption certificate. Specifically, during the server key exchange phase of the handshake process, the private key of the signature certificate is used to sign the data. During the client key exchange phase of the handshake process, the private key of the encryption certificate is used to decrypt the pre-masterkey. For clarity, the private key corresponding to the signature certificate will be referred to as the first private key, and the private key corresponding to the encryption certificate will be referred to as the second private key.

[0074] Table 1 illustrates two common national cryptographic software packages.

[0075] Table 1

[0076]

[0077] Please refer to Table 1. Each national cryptographic suite has a corresponding suite name, value, key exchange algorithm, authentication method, symmetric encryption algorithm, and hash algorithm. In Table 1, the national cryptographic suite RSA-SM4-CBC-SM3 requires two RSA certificates: a signing certificate and an encryption certificate. Similarly, the national cryptographic suite ECC-SM4-CBC-SM3 requires both an SM2 signing certificate and an SM2 encryption certificate. Additionally, each signing certificate has a private key, and each encryption certificate also has a private key.

[0078] For example, the following is a set of national cryptographic certificates:

[0079] gmssl_sign_crt sm2_sign.crt (signing certificate)

[0080] gmssl_sign_crt_key sm2_sign.key (private key of the signing certificate)

[0081] gmssl_enc_crt sm2_enc.crt (encryption certificate)

[0082] gmssl_enc_crt_key sm2_enc.key (private key of the encryption certificate)

[0083] The following describes in detail the method for processing national cryptographic handshake requests as described in the embodiments of this application, using the national cryptographic suite ECC-SM4-CBC-SM3 or the national cryptographic suite RSA-SM4-CBC-SM3 as examples. For example, please refer to... Figure 3 , Figure 3 This is another flowchart of the method for processing national cryptographic handshake requests provided in this application embodiment. This embodiment includes:

[0084] 301. The terminal device sends a client hello message to the node server.

[0085] Correspondingly, the node server receives a client hello message from the terminal device. Receiving a client hello message using the national cryptographic standard (CNFS) is equivalent to receiving a CNFS handshake request. The terminal device then sends a CNFS handshake request to the node server to initiate the handshake process.

[0086] The client hello message is transmitted in plaintext and includes the protocol version supported by the client on the terminal device, the cipher suite, the compression algorithm, the client-generated random number R1, and extended fields.

[0087] 302. The node server sends a server hello message to the terminal device.

[0088] For example, after receiving a client hello, the node server responds by sending a server hello message. The server hello message is transmitted in plaintext and includes confirmation of the protocol version used, a random number R2 generated by the node server, confirmation of the cipher suite used, and confirmation of the compression method used.

[0089] 303. The node server sends a certificate to the terminal device.

[0090] After sending the server hello message, the node server sends its public key certificate to the client on the terminal device.

[0091] 304. Determine the parameters of the key exchange algorithm, perform a hash operation on the parameters to obtain the data to be processed, and construct the request message based on the data to be processed.

[0092] In this step, the node server performs hash operations and other processing on the parameters of the encryption algorithm to obtain the data to be signed, and then constructs a request message carrying the data to be processed.

[0093] The parameters that have not undergone hashing are shown in the following code:

[0094]

[0095] 305. Node server suspends handshake process.

[0096] After the node server sends the certificate to the terminal device, the next step is to enter the server key exchange phase in the handshake process. This phase requires signing using the first private key corresponding to the signing certificate. Therefore, the node server suspends the handshake process, that is, it does not send the server key exchange message to the terminal device, but constructs the request message and then executes step 306.

[0097] 306. The node server sends a request message to the private key server.

[0098] This application does not limit the communication protocol between the node server and the private key server. For example, the node server and the private key server may communicate using the Chinese national cryptographic HTTPS protocol, the international HTTPS protocol, or other custom protocols.

[0099] 307. The private key server uses the first private key to sign the data to be processed and obtain the signed data.

[0100] For example, a first private key is pre-deployed on the private key server. The private key server uses the first private key to sign the data to be processed to obtain signed data, which is the target data.

[0101] 308. The private key server sends a response message carrying signature data to the node server.

[0102] 309. The node server parses the response message to obtain the signature data.

[0103] 310. The node server resumes the handshake process.

[0104] For example, the node server sets the target data into the current handshake state and resumes the handshake process.

[0105] 311. The node server sends a Server key exchange message to the terminal device.

[0106] The Server key exchange message carries the target data.

[0107] 312. The node server sends a "Server hello done" message to the terminal device.

[0108] In steps 304-310 above, the node server suspends the handshake process and transfers the processing of signing the data with the first private key corresponding to the signing certificate to the private key server. This avoids the client from providing sensitive data and reduces the CPU and other resource consumption of the node server.

[0109] After receiving the "Server hello done" message, the terminal device verifies the certificate sent by the node server to check its validity and authenticity. If the verification fails, the verification result is output. If the verification succeeds, the terminal device generates a random number and encrypts it using the node server's public key to obtain the encrypted pre-master key.

[0110] 313. The terminal device sends a client key exchange message to the node server.

[0111] Client key exchange messages carry encrypted pre-master keys.

[0112] 314. The node server constructs the request message based on the data to be processed.

[0113] The data to be processed includes encrypted pre-master keys, etc.

[0114] 315. Node server suspension handshake process.

[0115] Steps 314 and 315 can be understood as the process by which the node server processes the Client key exchange, i.e., process CKE.

[0116] 316. The node server sends a request message carrying the data to be processed to the private key server.

[0117] The request message carries the data to be processed, namely the pre-master key to be decrypted.

[0118] 317. The private key server uses the second private key to decrypt the data to be processed to obtain the pre-master key.

[0119] The decrypted pre-master key is the target data mentioned above.

[0120] 318. The private key server sends a response message carrying the pre-master key to the node server.

[0121] 319. The node server parses the response message to obtain the pre-master key.

[0122] 320. The node server resumes the handshake process.

[0123] For example, the node server sets the pre-master key into the current handshake state and resumes the handshake process.

[0124] In steps 315-319 above, the node server suspends the handshake process and transfers the decryption of the pre-master key using the second private key corresponding to the encryption certificate to the private key server. This avoids the client from providing sensitive data and reduces the CPU and other resource consumption of the node server.

[0125] 321. The terminal device sends a Change cipher spec message to the node server.

[0126] 322. The terminal device sends a Finished message to the node server.

[0127] It should be noted that the Client key exchange message in step 313, the Changecipher spec message in step 321, and the Finished message in step 322 can be sent simultaneously or separately. When sent separately, step 321 does not necessarily have to be executed after step 320, but can be executed after step 313. That is to say, after the node server completes step 320, it may have already completed step 321 or step 322, or it may not have completed step 321 or step 322 yet.

[0128] 323. The node server sends a Change cipher spec message to the terminal device.

[0129] 324. The node server sends a Finished message to the terminal device.

[0130] 325. Data interaction between node servers and terminal devices.

[0131] For example, after step 324 is completed, a secure connection is established between the terminal device and the node server, and data interaction is performed based on the secure connection.

[0132] As can be seen from the above, during the interaction of private keys in Chinese cryptography, the node server needs to return to the private key server twice for processing: once for signing and once for decryption.

[0133] It should be noted that in this embodiment, the first private key corresponding to the signing certificate and the second private key corresponding to the encryption certificate may not be the same. Therefore, it is necessary to provide the corresponding public key information or other key information to the private key server for appropriate operations.

[0134] It should also be noted that although the above mainly describes the keyless handshake process of the national cryptographic suites ECC-SM4-CBC-SM3 and RSA-SM4-CBC-SM3, the embodiments of this application are not limited thereto. In other feasible implementations, the above-mentioned national cryptographic handshake request can also be used for the keyless handshake process of other national cryptographic suites.

[0135] Figure 4 This is another flowchart of the method for processing national cryptographic handshake requests provided in this application embodiment. This embodiment is described from the perspective of the node server, and includes:

[0136] 401. Receive a national cryptographic handshake request from the terminal device.

[0137] Chinese cryptographic handshake requests include, for example, SSL requests.

[0138] 402. Initialize connection-related operations.

[0139] 403. Suspend the handshake process.

[0140] This step includes the following sub-steps:

[0141] 4031. Proceed to the handshake process.

[0142] 4032. Prepare the data to be processed.

[0143] The data to be processed is, for example, data to be signed or data to be decrypted.

[0144] 4033. Construct a request message based on the data to be processed.

[0145] The request message is also known as a private key-free request, etc.

[0146] 4034. Suspend the current handshake process and interact with the private key server.

[0147] 404. Return to main process.

[0148] At this time, the node server continues to receive Change cipher spec messages from the terminal devices.

[0149] 405. The node server determines whether it has received an abnormal event from the terminal device. If no abnormal event is received, proceed to step 406. If an abnormal event is received, proceed to step 410.

[0150] 406. The node server determines whether it has received a response message from the private key server. If a response message is received, proceed to step 407; if no response message is received, proceed to step 411.

[0151] For example, the node server determines whether a response message has been received within a preset time period, such as 30 seconds, which is not limited in this embodiment. If a response message is received and carries target data, step 407 is executed. If no response message is received within the preset time period, or even if a response message is received within the preset time period but does not carry target data, i.e., the response message is equivalent to a negative response, the self-moving device executes step 411.

[0152] 407. Set the target data to the current handshake state.

[0153] 408. Resume the handshake process.

[0154] 409. Perform other procedures.

[0155] For example, after a handshake is completed and a secure connection is successfully established, the terminal device and the node server exchange data based on the secure connection.

[0156] 410. End the currently processing private key request.

[0157] In this step, the node server and the private key server no longer exchange data.

[0158] 411. Resume the handshake process.

[0159] 412. Close the TCP connection.

[0160] A TCP connection is established before the terminal device and the node server handshake. In this step, the node server closes the TCP connection between the terminal device and the node server.

[0161] As described above, when private key processing is required, the node server first prepares the request message, then suspends the current handshake process and sends the request message to the private key server. The processing is asynchronous and does not block the current thread, meaning it does not affect other requests. Once the node server receives the response message, it applies the processed data to the current handshake process and resumes the handshake process, ultimately completing the entire handshake process.

[0162] Figure 5 This is a functional block diagram of the node server in the method for processing national cryptographic handshake requests provided in this application embodiment. Please refer to... Figure 5 In this embodiment of the application, in addition to the functions of constructing request messages and parsing response messages described above, the node server may optionally also have Domain Name System (DNS) resolution functions, retry and timeout mechanisms, backend long connection maintenance functions, or disaster recovery functions. These functions will be described in detail below.

[0163] First, the domain name resolution function.

[0164] When the private key server and node servers are deployed within the same cluster network, multiple private key servers can be deployed within the cluster network. For an example, please refer to... Figure 6 , Figure 6 This is a schematic diagram of a network architecture to which the national cryptographic handshake request processing method provided in this application applies. Please refer to... Figure 6 In this network architecture, the candidate set includes private key servers 1 to n. Node servers establish network connections with terminal devices, node servers establish network connections with source servers, etc., and node servers establish network connections with each private key server in the candidate cluster.

[0165] A configuration file is pre-stored on the node server, containing the mapping between domain names and private key servers. When a node server sends a request message carrying data to be processed to a private key server, it first determines the domain name. Then, it queries the configuration file based on the domain name to determine the target private key server from the candidate set, and sends the request message carrying the data to be processed to the target private key server.

[0166] For example, when a terminal device sends a client hello message to a node server, it includes the domain name in the message. The node server can then determine the domain name upon receiving the client hello message. Alternatively, the client hello message can omit the domain name; in this case, the terminal device will access the default domain name by default. After determining the domain name, the node server queries its configuration file to identify the target private key server. Then, the node server constructs a request message and sends it to the target private key server.

[0167] Alternatively, a scheduling algorithm can be pre-configured on the node server to send request messages to an idle private key server.

[0168] If hardware supporting the national cryptographic algorithm becomes available in the future, it can be deployed on the private key server to offload the CPU load of the node server through hardware computing power.

[0169] This approach reduces the resource consumption of node servers by transferring computations requiring private keys to idle private key servers, while making full use of idle private key servers, resulting in high resource utilization and fast response speed.

[0170] Secondly, disaster recovery functionality.

[0171] Please refer to the following: Figure 6Optionally, when the private key server and the node server are located on the same network, i.e., when the client is not sensitive to the private key information and is willing to provide it, the private key required for the handshake process is deployed locally on the node server. This includes the private key corresponding to the signature certificate and the private key corresponding to the encryption certificate of the dual certificates of the national cryptographic protocol. In this way, when the private key server malfunctions, such as through power outages or failures, the node server can use its local private key to process the data to be processed to obtain the target data.

[0172] This approach provides local disaster recovery, allowing the local private key to complete the handshake process when the remote private key server malfunctions, thus enhancing system robustness.

[0173] Secondly, the backend long-connection maintenance function.

[0174] The connection between the node server and the private key server is also known as the backend connection. Multiple long-lived connections are pre-established between the node server and the private key server. When the node server constructs a request message and sends it to the private key server, it selects a target long-lived connection from the multiple long-lived connections contained in the connection pool, and then sends a request message carrying the data to be processed to the private key server through the target long-lived connection.

[0175] For example, the node server and the private key server employ mutual authentication to prevent hijacking that could lead to information tampering or eavesdropping. This application does not limit the communication protocol between the node server and the private key server. When the node server and the private key server interact using HTTPS, long-lived connections can be used after mutual authentication to reduce the overhead of the interaction process. For instance, the node server and the backend private key server can pre-establish 100 long-lived connections, all of which are available. When a new national cryptographic handshake request is suspended, the node server randomly selects a target long-lived connection from the 100 connections or uses a certain algorithm, and sends a request message through the target long-lived connection. In this way, there is no need for the node server and the private key server to establish a connection, reducing the overhead of the interaction process through long-lived connections while ensuring the security of transmitted information.

[0176] Finally, retry and timeout mechanisms are included.

[0177] After a node server sends a request message to the private key server, if it does not receive a response message within a preset time period, it resends the request message to the private key server. The preset time period is, for example, 30 seconds, 20 seconds, etc., and is not limited in this embodiment.

[0178] It should be noted that the above Figure 5The framework shown can be extended to other TCP-based custom protocol interactions, including message construction, parsing, management of TCP connections to private key servers, timeouts and retries, and provides DNS configuration options for resolving to different private key servers.

[0179] In addition to the functions mentioned above, when the private key server and the node server are deployed on different networks, i.e., on the customer's network, it corresponds to scenarios where the customer does not wish to provide sensitive private key information. In this case, because the node server and the private key server are far apart, the node server performs link optimization through methods such as probing to optimize and accelerate the interaction between the terminal device and the private key server.

[0180] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0181] Figure 7 This is a schematic diagram of a processing device for a Chinese cryptographic handshake request, provided in an embodiment of this application. The processing device 700 includes a receiving module 71, a processing module 72, and a sending module 73. The processing device 700 can be integrated on a node server or a private key server. When the processing device 700 is integrated on a node server, the functions of each module are as follows:

[0182] Receiver module 71 is used to receive a national cryptographic handshake request from the terminal device;

[0183] Processing module 72 is used to suspend the handshake process when a private key is required to perform the handshake process for the national cryptographic handshake request.

[0184] The sending module 73 is used to send a request message carrying data to be processed to the private key server, so that the private key server can use the private key to process the data to be processed and obtain the target data.

[0185] The receiving module 71 is further configured to receive a response message from the private key server carrying the target data;

[0186] Processing module 72 is used to recover the handshake process based on the target data.

[0187] In one feasible implementation, before suspending the handshake process, the processing module 72 is further configured to determine the parameters of the key exchange algorithm when the private key required to perform the handshake process for the national cryptographic handshake request is the first private key corresponding to the signature certificate; perform a hash operation on the parameters to obtain the data to be processed; and construct the request message based on the data to be processed.

[0188] In one feasible implementation, before suspending the handshake process, the processing module 72 is further configured to determine the data to be processed based on the pre-master key encrypted by the terminal device when the private key required to perform the handshake process for the national cryptographic handshake request is the second private key corresponding to the encryption certificate; and construct the request message based on the data to be processed.

[0189] In one feasible implementation, the processing module 72 is further configured to determine the domain name; and to determine the target private key server from the candidate set by querying the configuration file according to the domain name, wherein the configuration file stores the correspondence between the domain name and the private key server;

[0190] The sending module 73 is used to send a request message carrying data to be processed to the target private key server.

[0191] In one feasible implementation, the processing module 72 is further configured to select a target long connection from multiple long connections contained in the connection pool, wherein the long connections in the connection pool are connections pre-established between the node server and the private key server;

[0192] The sending module 73 is used to send a request message carrying data to be processed to the private key server through the target long connection.

[0193] In one feasible implementation, the processing module 72 is further configured to deploy the private key locally on the node server; when the private key server is abnormal, the local private key is used to process the data to be processed to obtain the target data.

[0194] The processing device for the national cryptographic handshake request provided in this application embodiment can execute the actions of the node server in the above embodiment. Its implementation principle and technical effect are similar, and will not be described again here.

[0195] When the 700 processing unit for the national cryptographic handshake request is integrated into the private key server, the functions of each module are as follows:

[0196] The receiving module 71 is used to receive a request message from the node server carrying data to be processed. The request message is sent by the node server after suspending the handshake process when it needs to use a private key to perform the handshake process in response to the national cryptographic handshake request.

[0197] Processing module 72 is used to process the data to be processed using a private key to obtain target data;

[0198] The sending module 73 is used to send a response message carrying the target data to the node server.

[0199] In one feasible implementation, the processing module 72 is used to sign the data to be processed using a first private key to obtain signed data, wherein the first private key is the private key corresponding to the signing certificate, and the signed data is the target data.

[0200] In one feasible implementation, the processing module 72 is used to decrypt the data to be processed using a second private key to obtain the pre-master key, wherein the target data is the pre-master key.

[0201] The processing device for the national cryptographic handshake request provided in this application embodiment can execute the actions of the private key server in the above embodiment. Its implementation principle and technical effect are similar, and will not be described again here.

[0202] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 8 As shown, the electronic device 800 is, for example, the node server or private key server described above, and the electronic device 800 includes:

[0203] Processor 81 and memory 82;

[0204] The memory 82 stores computer instructions;

[0205] The processor 81 executes the computer instructions stored in the memory 82, causing the processor 81 to perform the national cryptographic handshake request processing method implemented by the above-mentioned node server; or, causing the processor 81 to perform the national cryptographic handshake request processing method implemented by the above-mentioned private key server.

[0206] The specific implementation process of processor 81 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0207] Optionally, the electronic device 800 also includes a communication component 83. The processor 81, memory 82, and communication component 83 can be connected via a bus 84.

[0208] This application also provides a computer-readable storage medium storing computer instructions, which, when executed by a processor, are used to implement a method for processing a national cryptographic handshake request implemented by a node server or private key server.

[0209] This application also provides a computer program product, which includes a computer program that, when executed by a processor, implements a method for processing national cryptographic handshake requests implemented by a node server or private key server.

[0210] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0211] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A processing method of a national secret handshake request, characterized in that, The method applied to a node server comprises: receiving a national secret handshake request from a terminal device; suspending a handshake process when a private key needs to be used for executing the handshake process for the national secret handshake request, the private key comprising a first private key corresponding to a signature certificate and a second private key corresponding to an encryption certificate in a double-certificate system of a national secret protocol, the first private key being used for data signature, and the second private key being used for pre-master key decryption, the number of times of needing to use the private key being twice, the number of times of suspending the handshake process being twice, and the handshake process being recovered twice; sending a request message carrying to-be-processed data to a private key server, so that the private key server processes the to-be-processed data by using the private key and obtains target data; receiving a response message carrying the target data from the private key server; resuming the handshake process according to the target data.

2. The method of claim 1, wherein, Before the step of suspending the handshake process, the method further comprises: when the private key needed for executing the handshake process for the national secret handshake request is the first private key corresponding to the signature certificate, determining a parameter of a key exchange algorithm; performing a hash operation on the parameter to obtain the to-be-processed data; constructing the request message according to the to-be-processed data.

3. The method of claim 1, wherein, Before the step of suspending the handshake process, the method further comprises: when the private key needed for executing the handshake process for the national secret handshake request is the second private key corresponding to the encryption certificate, determining to-be-processed data according to a pre-master key encrypted by the terminal device; constructing the request message according to the to-be-processed data.

4. The method according to any one of claims 1 to 3, characterized in that, The step of sending the request message carrying the to-be-processed data to the private key server comprises: determining a domain name; querying a configuration file according to the domain name to determine a target private key server from a candidate set, the configuration file storing a correspondence between domain names and private key servers; sending the request message carrying the to-be-processed data to the target private key server.

5. The method according to any one of claims 1 to 3, characterized in that, The step of sending the request message carrying the to-be-processed data to the private key server comprises: selecting a target long connection from a plurality of long connections included in a connection pool, the long connections in the connection pool being connections pre-established by the node server and the private key server; sending the request message carrying the to-be-processed data to the private key server through the target long connection.

6. The method according to any one of claims 1 to 3, characterized in that, The method further comprises: locally deploying the private key on the node server; when the private key server is abnormal, processing the to-be-processed data by using the local private key to obtain the target data.

7. A processing method of a national secret handshake request, characterized in that, The method applied to a private key server comprises: receiving a request message carrying to-be-processed data from a node server, the request message being sent by the node server after suspending a handshake process when a private key needs to be used for executing the handshake process for a national secret handshake request, the private key comprising a first private key corresponding to a signature certificate and a second private key corresponding to an encryption certificate in a double-certificate system of a national secret protocol, the first private key being used for data signature, and the second private key being used for pre-master key decryption, the number of times of needing to use the private key being twice, the number of times of suspending the handshake process being twice, and the handshake process being recovered twice; processing the to-be-processed data by using the private key to obtain target data; sending a response message carrying the target data to the node server.

8. The method of claim 7, wherein, The processing the to-be-processed data by using a private key to obtain target data comprises: signing the to-be-processed data by using a first private key to obtain signature data, the first private key being a private key corresponding to a signature certificate, and the signature data being the target data.

9. The method of claim 7, wherein, The processing the to-be-processed data by using a private key to obtain target data comprises: decrypting the to-be-processed data by using a second private key to obtain a pre-master key, and the target data being the pre-master key.

10. An electronic device comprising a processor, a memory, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the computer program to enable the electronic device to implement the method of any one of claims 1 to 9.

11. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the method of any one of claims 1 to 9.

Images