Secure communication method and apparatus

Abstract

The one or more embodiments of the specification provide a secure communication method and device, which generates a second key pair corresponding to a second key agreement algorithm by itself when it is determined that the first key agreement algorithm indicated by the client is not used on the server side, and sends the identification of the second key agreement algorithm and the second public key to the client in a retry request message, so that the client can directly execute a key encapsulation algorithm using the second public key to obtain a session key, and directly carries the service data encrypted using the session key in a subsequent second handshake message.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of secure communication technology, and in particular to a secure communication method and apparatus. Background Technology

[0002] As the standardization of post-quantum cryptography (PQC) continues to advance, various countries and standardization organizations have successively formulated various PQC standards. Compared with traditional cryptographic algorithms such as RSA and ECDSA, existing PQC algorithms suffer from high communication overhead and fragmented standard systems. Due to these characteristics of PQC algorithms, different organizations may prefer to use the PQC algorithm standard they have developed. This requires the communicating parties to complete additional rounds of interaction to negotiate the PQC algorithm, making the TLS handshake process cumbersome, increasing communication latency, and reducing application data processing efficiency.

[0003] Therefore, how to reduce the extra communication rounds brought about by the PQC algorithm negotiation in the TLS protocol and improve data processing efficiency is a technical problem that urgently needs to be solved. Summary of the Invention

[0004] In view of the above, this specification provides a secure communication method and apparatus through one or more embodiments.

[0005] To achieve the above objectives, one or more embodiments of this specification provide the following technical solutions: According to a first aspect of one or more embodiments of this specification, a secure communication method is proposed, applied to a server. The method includes: receiving a first handshake message sent by a client, the first handshake message indicating a first key negotiation algorithm supported by the client; generating a second key pair corresponding to a second key negotiation algorithm when it is determined that the first key negotiation algorithm will not be used for key negotiation, the second key pair including a second public key and a second private key; and sending a retry request message to the client, the retry request message including an identifier of the second key negotiation algorithm and the second public key. The system receives a second handshake message sent by the client in response to the retry request message. The second handshake message contains ciphertext data and service data encrypted using a session key. The session key and the ciphertext data are obtained by the client calling the key encapsulation algorithm corresponding to the second key negotiation algorithm using the second public key as input. The system decapsulates the ciphertext data based on the second private key to obtain the session key, and decrypts the service data based on the session key.

[0006] According to a second aspect of one or more embodiments of this specification, a secure communication method is proposed, applied to a client. The method includes: sending a first handshake message to a server, the first handshake message indicating a first key negotiation algorithm supported by the client; receiving a retry request message sent by the server, the retry request message containing an identifier of a second key negotiation algorithm and a second public key corresponding to the second key negotiation algorithm, wherein the second public key is generated by the server when it determines that the first key negotiation algorithm will not be used; invoking a key encapsulation algorithm corresponding to the second key negotiation algorithm using the second public key as input to obtain ciphertext data and a session key; constructing a second handshake message containing the ciphertext data and business data encrypted using the session key, and sending the second handshake message to the server.

[0007] According to a third aspect of one or more embodiments of this specification, an electronic device is provided, comprising: processor; Memory used to store processor-executable instructions; The processor implements the method as described in the first aspect by running the executable instructions.

[0008] According to a fourth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the method as described in the first aspect.

[0009] According to a fifth aspect of one or more embodiments of this specification, a computer program product is provided, comprising: a computer program / instructions that, when executed by a processor, implement the method as described in the first aspect.

[0010] As can be seen from the above embodiments, the secure communication method and apparatus provided in one or more embodiments of this specification, when the server determines that it will not use the first key negotiation algorithm indicated by the client, actively generates a second key pair corresponding to the second key negotiation algorithm, and sends the identifier of the second key negotiation algorithm and the second public key to the client in a retry request message. This allows the client to directly execute the key encapsulation algorithm using the second public key to obtain the session key, and directly carry the business data encrypted with the session key in the subsequent second handshake message. Through the above technical means, since the server has completed the key generation step in advance when issuing the retry request, and the client has simultaneously completed the key encapsulation and application data encryption when responding to the retry request, the key negotiation process that originally required an additional round of complete interaction is compressed, avoiding multiple round-trip communications caused by inconsistent algorithm negotiation. Therefore, the embodiments of this specification can significantly reduce the number of communication rounds in the handshake phase, reduce network latency, and improve the transmission efficiency of application data while ensuring communication security. Attached Figure Description

[0011] Figure 1 This is an exemplary embodiment of the architecture diagram of an application scenario for a secure communication method.

[0012] Figure 2 This is a flowchart illustrating a secure communication method applied to a server, provided as an exemplary embodiment.

[0013] Figure 3 This is a schematic diagram illustrating the interaction process between a server and a client, provided as an exemplary embodiment.

[0014] Figure 4 This is a schematic diagram illustrating another process of server-client interaction provided in an exemplary embodiment.

[0015] Figure 5 This is a flowchart illustrating a secure communication method applied to a client, provided as an exemplary embodiment.

[0016] Figure 6 This is a schematic diagram of the structure of a device provided in an exemplary embodiment.

[0017] Figure 7 This is a block diagram of a secure communication device applied to a server, provided as an exemplary embodiment.

[0018] Figure 8 This is a block diagram of a secure communication device applied to a client, provided as an exemplary embodiment. Detailed Implementation

[0019] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0020] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of related data shall comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals shall be provided for users to choose to authorize or refuse.

[0021] In the embodiments described in this specification, the key terms are defined as follows: TLS (Transport Layer Security) is a widely adopted security protocol designed to enhance the privacy and security of internet communications and data. Its primary use case is encrypting communication between web applications and servers (e.g., a web browser loading a website). TLS can also be used to encrypt other communications, such as email, messaging, and Voice over IP (VoIP). In this specification, the version of the TLS protocol that supports post-quantum cryptography negotiation extensions is specifically referred to.

[0022] PQC (Post-Quantum Cryptography) refers to cryptographic mechanisms that can resist attacks from quantum computers. Unlike traditional public-key cryptography algorithms (such as RSA and ECC), PQC algorithms are based on mathematical problems (such as lattice problems, coding problems, and multivariable polynomial problems), which are difficult to solve in polynomial time even on quantum computers.

[0023] KEM (Key-Encapsulation Mechanism): A public-key cryptographic mechanism used to negotiate session keys between two parties. A KEM typically comprises three algorithms: a key generation algorithm (KeyGen), a key encapsulation algorithm (Encaps), and a key decapsulation algorithm (Decaps). In this specification, the PQC algorithm is primarily presented in the form of a KEM.

[0024] RTT (Round-Trip Time): The time required for data to travel from the sender to the receiver and then back from the receiver to the sender. In this specification, it is used to measure the communication efficiency of the TLS handshake phase.

[0025] ClientHello: The first message sent by the client to the server during the TLS handshake phase, containing information such as the protocol versions supported by the client, a list of cipher suites, and a random number. In this specification, this message also includes an identifier of the first key negotiation algorithm supported by the client.

[0026] HelloRetryRequest: A special message defined in the TLS 1.3 protocol. When the server cannot accept the parameters provided by the client in ClientHello, it sends this message to the client, requesting the client to resend ClientHello. In this specification, this message is expanded to carry a second public key generated by the server.

[0027] As described in the background section, in the existing TLS handshake process, the client and server need to negotiate a key exchange algorithm that both support. Typically, the client indicates its supported first key exchange algorithm in the initial handshake message (ClientHello). If the server accepts this algorithm, it directly completes key exchange and establishes a secure channel based on it, allowing application data to begin transmission within one round-trip time (1-RTT). However, due to standard fragmentation and implementation differences in PQC algorithms, different organizations or devices may prefer different PQC algorithm standards. When the server does not use the first key exchange algorithm indicated by the client, existing mechanisms usually require the server to send a retry request message (such as HelloRetryRequest) to the client. Upon receiving this message, the client needs to regenerate a key pair for the second key exchange algorithm and resend the handshake message. Only after receiving the second handshake message can the server complete key exchange and decrypt the business data. In this scenario, application data requires at least two round-trip times (2-RTT) before transmission can begin.

[0028] The aforementioned existing technologies have significant technical shortcomings when dealing with scenarios where PQC algorithm negotiation fails. On the one hand, the additional rounds of interaction significantly increase the communication latency during the handshake phase, reducing the processing efficiency of application data. This cumulative latency effect is particularly pronounced in high-latency network environments. On the other hand, to mitigate the increased latency caused by negotiation failures, some existing technologies attempt to have the client carry public key parameters for multiple algorithms during the initial handshake. However, this leads to a dramatic increase in the size of the first handshake message data packet, increasing network bandwidth consumption and resolution burden. Alternatively, they rely on external systems (such as DNS) to pre-inform the server of preferences, which requires large-scale modifications to existing infrastructure, resulting in high deployment costs and poor compatibility.

[0029] Therefore, the secure communication method provided in this specification addresses the issue of additional interaction rounds caused by algorithm negotiation inconsistencies in existing technologies. This specification's embodiments change the traditional TLS handshake practice where the client leads key generation, instead employing a mechanism where the server actively generates a second key pair and issues a public key when it determines it will not use the first algorithm. This technique breaks the bidirectional serial dependency of the traditional process: "client generates and sends public key -> server confirms -> server generates and sends ciphertext data," eliminating the process where the client needs to regenerate the key pair and re-initiate the handshake request due to algorithm mismatch. By moving the server's key generation action to the retry request stage, the client only needs to perform a one-way key encapsulation operation when responding to a retry, eliminating the need for time-consuming key pair generation and uploading steps. Thus, the original two-stage public key exchange process requiring independent round-trip time (RTT) is compressed, reducing the communication rounds required for key negotiation from the traditional 2-RTT to 1.5-RTT, thereby reducing the number of interaction rounds in the TLS handshake.

[0030] Meanwhile, addressing the issue of low data processing efficiency in existing technologies, the embodiments in this specification allow the client to directly encrypt business data using the generated session key and send it along with the second handshake message. Since the server has already generated the second key pair before issuing a retry request, and can immediately decrypt the second handshake message to obtain the session key and decrypt the business data, this "parallel handshake and data transmission" mechanism eliminates the idle window of waiting for the handshake to completely finish before transmitting data. This not only significantly shortens the arrival time of the first packet but also significantly improves throughput in high-latency network environments, effectively enhancing data transmission efficiency.

[0031] For ease of understanding, the secure communication method provided in the embodiments of this specification will be described in detail below with reference to the accompanying drawings.

[0032] Figure 1 This is a schematic diagram illustrating an application scenario architecture of a secure communication system provided in an exemplary embodiment. For example... Figure 1 As shown, the system may include a client 101, a network 102, and a server 103.

[0033] Client 101 can be various electronic devices with data processing and network communication capabilities, including but not limited to smartphones, tablets, personal computers (PCs), laptops, Internet of Things (IoT) gateways, or embedded devices. An application runs on client 101, which needs to establish a secure connection with server 103 via the TLS protocol to transmit business data. In some embodiments, client 101 integrates a cryptographic library supporting multiple PQC algorithms. This library can select the preferred key negotiation algorithm according to configuration or policy and perform corresponding key generation, encapsulation, and decapsulation operations.

[0034] Network 102 can be a wired network, a wireless network, or a combination thereof. For example, network 102 may include a local area network (LAN), a wide area network (WAN), the Internet, mobile communication networks (such as 4G, 5G), etc. Network 102 is used to transmit data packets between client 101 and server 103.

[0035] Server 103 can be a standalone physical server, or a cluster of multiple servers, a cloud platform, or a virtualized environment. Server 103 is responsible for responding to connection requests from client 101, executing the TLS handshake protocol, and transmitting encrypted business data with client 101 after a successful handshake. In some embodiments, server 103 is deployed with a TLS termination proxy or a business gateway with TLS processing capabilities, and internally maintains a list of supported PQC algorithms, as well as an optional algorithm preference database or policy engine, for dynamically selecting the most suitable key negotiation algorithm during the handshake process.

[0036] In practical applications, client 101 and server 103 may be located in different geographical regions, or even across different countries or regions. Due to varying adoption rates of the PQC standard in different regions, or differences in cryptographic libraries implemented by different vendors, the algorithm preferred by client 101 may not be supported or preferentially adopted by server 103. In this case, the traditional TLS handshake process would result in additional communication rounds, increasing latency. The solutions provided in the embodiments of this specification aim to optimize this process.

[0037] refer to Figure 2 Here is a flowchart of a secure communication method provided in this specification, which includes the following steps: Step S201: Receive a first handshake message sent by the client, the first handshake message indicating the first key negotiation algorithm supported by the client.

[0038] During the TLS handshake initialization phase, the client sends a first handshake message to the server. In TLS 1.3 and later versions, this message is typically a ClientHello message. The first handshake message may contain information such as the protocol versions supported by the client, a list of cipher suites, and extended fields. In some embodiments, the first handshake message indicates the first key negotiation algorithm the client wishes to use through specific extended fields or cipher suite identifiers. This first key negotiation algorithm can be a specific PQC KEM algorithm, such as the lattice-based Kyber algorithm, the hash-based SPHINCS+ algorithm, or a combination of traditional algorithms and PQC algorithms. In some embodiments, in addition to the identifier indicating the first key negotiation algorithm supported by the client, the first handshake message may also include the first public key corresponding to that algorithm. In some embodiments, after receiving the first handshake message from the client, the server can parse the first handshake message and extract the algorithm identifier. If the first handshake message indicates multiple algorithms, the algorithm listed first is typically determined as the first key negotiation algorithm according to the priority order specified by the client.

[0039] refer to Figure 3This is a schematic diagram of a server-client interaction process provided in an embodiment of this specification. When the client and server establish secure communication, the client first determines a first key negotiation algorithm from among the multiple key negotiation algorithms it supports. Then, it generates a public-private key pair (pk-A, sk-A) through the key generation algorithm corresponding to the key negotiation algorithm. After that, it saves the private key sk-A and sends the public key pk-A and the algorithm identifier KEM-A of the first key negotiation algorithm together to the server through ClientHello1 (first handshake message). At this time, if the server accepts the first key negotiation algorithm, it can call its corresponding key encapsulation algorithm through the algorithm identifier KEM-A and use the public key pk-A as the input of the key encapsulation algorithm to obtain the ciphertext data ct-A and the session key ss. Subsequently, the server uses the session key ss to encrypt the business data to be sent to the client, obtaining the encrypted business data Enc(ss, app-data1). The server then sends the encrypted business data Enc(ss, app-data1) and the ciphertext data ct-A to the client. In some embodiments, the server can send the ciphertext data ct-A via ServerHello, which is typically used to confirm the protocol version and the ciphertext data. Upon receiving the encrypted business data Enc(ss, app-data1) and the ciphertext data ct-A from the server, the client can invoke the key decapsulation algorithm corresponding to the target key negotiation algorithm, using the ciphertext data ct-A and the private key sk-A as input to obtain the session key ss. Then, the encrypted business data Enc(ss, app-data1) can be decrypted using this session key ss, thus completing secure communication between the client and the server.

[0040] Step S202: If it is determined that the first key negotiation algorithm will not be used for key negotiation, a second key pair corresponding to the second key negotiation algorithm is generated. The second key pair includes a second public key and a second private key.

[0041] After receiving the first handshake message, the server needs to decide whether to adopt the first key negotiation algorithm indicated by the client, based on its own security policy, performance considerations, or compatibility requirements. In some embodiments, the reasons for not adopting the algorithm may include: the server does not support the algorithm, the security strength of the algorithm does not meet the server's requirements, or the server prefers to use another algorithm to optimize performance or meet compliance requirements.

[0042] When the server determines not to use the first key negotiation algorithm, it needs to select a second key negotiation algorithm from the set of algorithms supported by the server. In one embodiment, the server can randomly select a supported algorithm as the second key negotiation algorithm. In another embodiment, the server can select the highest-ranked available algorithm based on a preset priority list.

[0043] After selecting the second key negotiation algorithm, the server immediately executes the corresponding key generation algorithm to generate a second key pair. The second key pair includes a second public key and a second private key. The generated second public key will be used for subsequent key encapsulation, while the second private key will be temporarily stored in the server's memory for subsequent key decapsulation.

[0044] It is worth noting that, unlike the traditional process, where the server only sends an indicator after rejecting the client's algorithm and waits for the client to re-initiate the handshake before generating the key, in this embodiment of the invention, the server pre-generates the second key pair before sending the retry request and sends the second public key from the second key pair to the client through the retry request information. This allows the client to directly generate a session key using the second public key after receiving the retry request information, enabling it to send encrypted business data directly to the server using this session key.

[0045] To further improve the success rate of negotiation, in some embodiments of this specification, the secure communication method applied to the server also includes: The algorithm preference information corresponding to the client is determined based on the first handshake message; Based on the algorithm preference information, the second key negotiation algorithm is determined from at least one key negotiation algorithm supported by the server.

[0046] Considering that blindly selecting a second key negotiation algorithm might lead to client incompatibility with the algorithm, resulting in connection failure or retry, this embodiment of the invention allows the server to determine the client's algorithm preference information based on the first handshake message and select a second key negotiation algorithm based on that preference information. This algorithm preference information can be used to predict the probability that the client supports different key negotiation algorithms.

[0047] Various technical means can be used to obtain algorithm preference information. In some embodiments of this specification, determining the algorithm preference information corresponding to the client based on the first handshake message includes: Extract the source network features corresponding to the first handshake message; the source network features include the geographical region and / or network operator type to which the source IP address belongs; The algorithm preference information corresponding to the client is determined based on the source network characteristics and a predefined algorithm preference database; wherein, the algorithm preference database statistically analyzes the historical support rate distribution of various key negotiation algorithms for client groups under different source network characteristics; the algorithm preference information includes the historical support rate distribution of various key negotiation algorithms for the client.

[0048] In practice, the server can maintain an algorithm preference database beforehand. This database stores statistical data on PQC algorithm support rates for different geographical regions (such as Asia, Europe, and North America) and different network operators (such as China Mobile, China Telecom, China Unicom, Comcast, etc.). In some embodiments, this data can be obtained through analysis of historical handshake logs, for example, by statistically analyzing the proportion of clients from a certain IP segment who supported algorithms such as Kyber and Dilithium in past connections. In some embodiments, the key negotiation algorithms supported by customer groups with different source network characteristics can also be obtained from publicly available historical data, and statistical analysis can be performed on this publicly available historical data to obtain the historical support rate distribution of various key negotiation algorithms for customer groups with different source network characteristics.

[0049] When the server receives the first handshake message from the client, it extracts the source IP address. The IP address determines the source network characteristics, specifically the client's geographical region and carrier type. For example, it might determine that the client is located in "China-Beijing" and uses "China Unicom". Then, the server searches its algorithm preference database for the algorithm support rate distribution corresponding to "China-Beijing-China Unicom". Assuming the data shows that the group has 90% support for the "SM2-PQC hybrid algorithm" and 85% support for "Kyber-768", if the server supports both algorithms and the algorithm indicated in the first handshake message is not used, the server can choose the "SM2-PQC hybrid algorithm" with the highest support rate as the second key negotiation algorithm. This approach leverages the statistical patterns of group behavior, enabling a high-probability correct choice even in the absence of specific client information.

[0050] In some embodiments of this specification, determining the algorithm preference information corresponding to the client based on the first handshake message includes: Obtain the parameter attribute features of the first key negotiation algorithm contained in the first handshake message, wherein the parameter attribute features include mathematical primitive type and security strength level; The algorithm preference information corresponding to the client is determined based on the parameter attribute features; wherein, the algorithm preference information includes algorithms with the same mathematical primitive type as the first key negotiation algorithm and whose security strength level is not greater than that of the first key negotiation algorithm.

[0051] Different PQC algorithms are generally generated based on different mathematical primitives, such as lattice, code, multivariate, and hash. When a client determines its algorithm preference information and selects a particular algorithm, it often implies that its underlying cryptographic library has good support for that mathematical primitive. In some embodiments, when the server determines the client's algorithm preference information, it can first parse the first handshake message to identify the parameter attributes of the first key negotiation algorithm. For example, the client's preferred algorithm is "Kyber-1024," whose mathematical primitive type is "lattice" and its security strength level is "Level 5" (the highest level). The server can infer that the client's cryptographic library likely supports other algorithms based on "lattice" and supports high-security operations. Therefore, when deciding not to use Kyber-1024 (e.g., for performance reasons, preferring a lower-overhead algorithm), the server can filter from its supported algorithm list to select algorithms that are also based on "lattice" primitives and have a security strength level no higher than Level 5, such as "Kyber-768" or "Kyber-512." Choosing algorithms with the same primitives can reduce compatibility issues caused by clients lacking the corresponding mathematical libraries. Furthermore, if the server wants to reduce computational load, it can choose algorithms with lower security strength, since clients that support high security strength are usually backward compatible with lower security strength.

[0052] In some embodiments of this specification, determining the algorithm preference information corresponding to the client based on the parameter attribute features includes: Extract the protocol structure features corresponding to the first handshake message; the protocol structure information includes at least one of the global permutation sequence of extended fields and the encoding features of the identifier of the first key negotiation algorithm; The cryptographic library corresponding to the client is determined based on the protocol structure characteristics; The algorithm preference information corresponding to the client is determined based on the cryptographic library corresponding to the client and the parameter attribute characteristics; the algorithm preference information includes having the same mathematical primitive type as the first key negotiation algorithm and having a security strength level no greater than the security strength level of the first key negotiation algorithm, and being supported by the cryptographic library corresponding to the client.

[0053] Different open-source or commercial cryptographic libraries (such as OpenSSL, BoringSSL, Libsodium, or specific hardware security modules (HSM) firmware) often possess unique fingerprint characteristics when constructing TLS handshake messages. These include, for example, the order of extended fields, the encoded length of specific OIDs (Object Identifiers), and the usage habits of padding bytes. To further improve the accuracy of identifying the client's corresponding algorithm preference information, the server can pre-establish a cryptographic library fingerprint database, recording the characteristics of common libraries. When the server receives the first handshake message, it extracts its protocol structure characteristics (fingerprint features) and matches them against the fingerprint database. For example, it identifies that client 101 uses the "OpenSSL 3.0" library. It is known that the OpenSSL 3.0 library fully supports the NIST-standardized PQC algorithm, but its support for some experimental algorithms is poor. Combining the parameter attributes of the first algorithm, the server can more accurately predict the list of other algorithms supported by the client, that is, it can filter out key negotiation algorithms that simultaneously meet the following conditions: having the same mathematical primitive type as the first key negotiation algorithm, a security strength level no greater than the first key negotiation algorithm, and being supported by the client's corresponding cryptographic library. For example, if a lightweight library is identified as belonging to a specific IoT device, it may only support a few optimized algorithms. Based on this, the second key negotiation algorithm selected by the server will be one that this specific library necessarily supports, thereby greatly improving the handshake success rate.

[0054] To provide the server with more methods for confirming algorithm preference information, in some embodiments of this specification, determining the algorithm preference information corresponding to the client based on the parameter attribute features may include: extracting the protocol structure features corresponding to the first handshake message; the protocol structure information includes at least one of a globally permuted sequence of extended fields and an encoded feature of the identifier of the first key negotiation algorithm; determining the cryptographic library corresponding to the client based on the protocol structure features; and determining the algorithm preference information corresponding to the client based on the cryptographic library corresponding to the client. That is, in some embodiments, the algorithm preference information corresponding to the client can be determined solely by the cryptographic library corresponding to the client. In this case, the algorithm preference information can directly be the cryptographic library corresponding to the client, and the server can consider as many key negotiation algorithms as possible supported by the cryptographic library corresponding to the client when determining the second key negotiation algorithm.

[0055] Through the above-mentioned multi-dimensional preference analysis and algorithm selection, the embodiments in this specification not only reduce the number of communication rounds in terms of mechanism, but also improve the success rate of single retry in terms of strategy, thereby improving the efficiency and robustness of secure communication as a whole.

[0056] Step S203: Send a retry request message to the client. The retry request message contains the identifier of the second key negotiation algorithm and the second public key.

[0057] After constructing a retry request message containing the identifier of the second key negotiation algorithm and the second public key, the server sends the retry request information to the client. This retry request message includes not only an identifier (e.g., algorithm ID or cipher suite code) instructing the client to use the second key negotiation algorithm, but also the second public key generated in step S202. In some embodiments, this message can be a HelloRetryRequest message. To ensure the retry request message includes the identifier of the second key negotiation algorithm and the second public key, the standard HelloRetryRequest message format can be extended, for example, by adding a subfield to the existing extended fields, or by using a reserved extended type to carry the second public key data. The data structure of the second public key should conform to the standard specification of the second key negotiation algorithm to ensure that the client can parse it correctly. In some embodiments, when constructing the HelloRetryRequest message, a named group identifier instructing the client to use the second key negotiation algorithm can be filled into its key_share extended field, and the second public key generated based on the second key negotiation algorithm can be embedded in the message payload (e.g., by defining a new extended type or reusing an existing extended structure).

[0058] It should be noted that in the embodiments described in this specification, the server sends a retry request message to the client. Since the retry request message already contains the second public key, the client does not need to perform a separate key exchange to obtain the public key after receiving the message, thus saving communication rounds.

[0059] Step S204: Receive a second handshake message sent by the client in response to the retry request message. The second handshake message contains ciphertext data and service data encrypted using a session key. The session key and the ciphertext data are obtained by the client calling the key encapsulation algorithm corresponding to the second key negotiation algorithm using the second public key as input.

[0060] Upon receiving the retry request message, the client parses out the identifier of the second key negotiation algorithm and the second public key. The client then invokes the key encapsulation algorithm corresponding to the second key negotiation algorithm, using the second public key as input, to generate ciphertext data and a session key. It should be noted that the key encapsulation algorithm is a probabilistic algorithm; each execution generates different ciphertext and session key, but only the party possessing the corresponding private key can decapsulate it to obtain the same session key.

[0061] Subsequently, the client constructs a second handshake message. In TLS, this is typically the second ClientHello message sent. Unlike the conventional process, the client not only includes ciphertext data in this message but also directly encrypts the application-layer business data using the generated session key, and encapsulates the encrypted business data in the second handshake message (e.g., carried via Early Data or specific extended fields, or sent along with the encrypted application data record, depending on the specific implementation and conventions of the protocol). In some embodiments of this specification, the second handshake message is designed to carry encrypted business data, or the first application data record immediately following the second handshake message is considered the first business data record after the handshake is completed, and its encryption key has been established by the aforementioned KEM process. After receiving the second handshake message sent by the client, the server can parse the ciphertext data and encrypted business data from it.

[0062] Step S205: Decapsulate the ciphertext data based on the second private key to obtain the session key, and decrypt the business data based on the session key.

[0063] The server uses the second private key generated and temporarily stored in step S202 to call the key decapsulation algorithm corresponding to the second key negotiation algorithm. Using the ciphertext data and the second private key as input, it recovers the session key. It should be noted that the decapsulation algorithm verifies the validity of the ciphertext. If the verification passes, it outputs a shared secret consistent with the session key. If the verification fails, it indicates that the data transmission may have been tampered with or the client used an incorrect public key; in this case, the server will terminate the connection.

[0064] After obtaining the session key, the server uses it to decrypt the encrypted business data carried in the second handshake message, thereby obtaining the original business data. At this point, the TLS handshake process and the application data transmission process achieve a high degree of overlap in time. Compared to the traditional 2-RTT mode, this solution reduces the initial transmission latency of application data to 1.5-RTT, saving at least one complete round-trip wait.

[0065] To further enhance the security of key management, in some embodiments of this specification, the secure communication method applied to the server also includes: If the second handshake message is not received within a preset time threshold starting from the time a retry request message is sent to the client, the second key pair is deleted. Alternatively, if the session key is obtained, the second key pair can be deleted.

[0066] Since the second key pair is temporarily generated under special circumstances where the handshake negotiation fails, its long-term residence in memory not only consumes valuable server resources but also increases the risk of private key leakage. Therefore, the embodiments in this specification introduce a strict key lifecycle management mechanism. In some embodiments, after the server executes step S203 and sends a retry request message containing the second public key to the client, the second private key enters the "pending decapsulation" state. At this time, the server can start a timer and set a preset duration threshold. The specific preset duration threshold can be set as needed and is not limited thereto. In some embodiments, the setting of this threshold can take into account the distribution characteristics of network round-trip time (RTT) and client processing time, and is usually set to 2-3 times the normal RTT, for example, 5 to 10 seconds in a public network environment.

[0067] If the server receives the second handshake message from the client and successfully parses the ciphertext data before the timer expires, it enters the "Decapsulation in Progress" state. The server uses the second private key to decapsulate the ciphertext data. Once decapsulation is successful and the session key is obtained, the server can immediately perform a destruction operation, clearing the second private key from memory and entering the "Destroyed" state. This "use and destroy" strategy minimizes the exposure time of the private key in memory, ensuring that even if the server subsequently suffers a memory dump attack, the attacker cannot obtain the private key used for decrypting this session.

[0068] On the other hand, if the timer expires—that is, if the time elapsed from the moment the retry request message was sent to the current moment exceeds a preset time threshold, and the server still has not received the second handshake message—then the handshake attempt is deemed to have failed or the client is offline. In this case, the server can directly enter the "timeout cleanup" state, forcibly deleting the second key pair (including the public and private keys) to release memory resources. This mechanism effectively prevents server memory exhaustion attacks caused by clients maliciously initiating a large number of handshake requests without completing subsequent steps.

[0069] Beyond one-way data reception, complete secure communication typically involves two-way data interaction. In existing technologies, after the server decrypts client data, additional steps are often required to establish an encrypted downlink channel. However, in the embodiments of this specification, since the session key is jointly established by both parties during the handshake phase, the security of the downlink is naturally extended. Therefore, in some embodiments of this specification, the secure communication method applied to the server further includes: Obtain the business response data corresponding to the decrypted business data; The service response data is encrypted based on the session key, and the encrypted service response data is sent to the client.

[0070] In step 205, after the server decrypts the original business data using the session key, the business logic layer processes the data to generate business response data. For example, if the business data is a request to query a user's balance, the business response data is a JSON structure containing balance information. The server calls a symmetric encryption algorithm (such as AES-GCM or ChaCha20-Poly1305), using the session key as the encryption key, to encrypt and protect the integrity of the business response data, generating encrypted business response data. Subsequently, the server encapsulates this encrypted data in the TLS record layer protocol and sends it to the client. Since the session key is negotiated through a secure KEM mechanism and is known only to the communicating parties, this downlink data transmission also possesses confidentiality and integrity.

[0071] Figure 4 This is a schematic diagram illustrating the interaction process between a server and a client, provided in an exemplary embodiment. To more intuitively demonstrate the advantages of this invention's embodiments compared to existing technologies, the following is combined with... Figure 4Here's an explanation. When a client and server establish secure communication, the client first selects a first key negotiation algorithm from among its supported key negotiation algorithms. Then, it generates a public-private key pair (pk-A, sk-A) using the key generation algorithm corresponding to this algorithm. The client then saves its private key sk-A and sends the public key pk-A and the algorithm identifier KEM-A of the first key negotiation algorithm to the server via ClientHello1 (the first handshake message). If the server does not accept the target key negotiation algorithm, it can select a second key negotiation algorithm from its supported algorithms and generate a public-private key pair (pk-B, sk-B) using the key generation algorithm corresponding to the second algorithm. The server then saves its private key sk-B and sends the public key pk-B and the algorithm identifier KEM-B of the second key negotiation algorithm to the client via HelloRetryRequest (a retry request message). After receiving the HelloRetryRequest, the client can invoke the corresponding key encapsulation algorithm using the algorithm identifier KEM-B, and input the public key pk-B to obtain the ciphertext data ct-B and the session key ss. Then, the client can encrypt the business data sent to the server using the session key ss, obtaining the encrypted business data Enc(ss, app-data2), and send it along with the ciphertext data ct-B to the server. In some embodiments, the client can send the algorithm identifier KEM-B and the ciphertext data ct-B via ClientHello2 (the second handshake message). ClientHello2 is generally used to confirm the protocol version and the ciphertext data. After receiving the encrypted business data Enc(ss, app-data2) and the ciphertext data ct-B from the client, the server can invoke the key decapsulation algorithm corresponding to the second key negotiation algorithm, and input the ciphertext data ct-B and the private key sk-B to obtain the session key ss. Next, the encrypted business data Enc(ss, app-data2) can be decrypted using the session key ss, thus completing secure communication between the client and the server. This embodiment of the invention saves nearly a full RTT latency by pre-generating the server's key and parallelizing the client's key encapsulation and data encryption. This latency saving is particularly significant for improving user experience in cross-border or high-latency network environments.

[0072] refer to Figure 5 This is a flowchart illustrating a secure communication method applied to a client, as provided in an exemplary embodiment. This method can be executed by the client. Figure 5 As shown, the method includes the following steps: Step S301: Send a first handshake message to the server. The first handshake message indicates the first key negotiation algorithm supported by the client.

[0073] When initiating a secure connection, the client first constructs a first handshake message (ClientHello). Client 101 selects a preferred algorithm from the list of supported algorithms as the first key exchange algorithm based on its local configuration, security policy, or user preferences. For example, in a high-security financial app scenario, the client might prefer the lattice-based Kyber-1024 algorithm. After determining the first key exchange algorithm, the client can fill in the algorithm's identifier in an extended field of the first handshake message and send it to the server over the network. In some embodiments, the first handshake message may include, in addition to the identifier of the first key exchange algorithm, a first public key corresponding to that algorithm.

[0074] To assist the server in making algorithm selection more quickly, in some embodiments of this specification, the first handshake message also includes algorithm preference information corresponding to the client; the algorithm preference information includes relevant information about other key negotiation algorithms supported by the client besides the first key negotiation algorithm. This allows the client to proactively disclose more of its capabilities. It should be noted that the relevant information about other key negotiation algorithms included in the algorithm preference information may be the algorithm identifier of other key negotiation algorithms, or a list of other PQC algorithms supported by the client, or the overall type of key negotiation algorithms supported by the client, etc.

[0075] In some embodiments, the client can add a custom extended field to the first handshake message, listing other supported PQC algorithms and their priorities. For example, the client could send a list containing {Kyber-768, Dilithium-3, SPHINCS+-small}. This way, even if the server does not use the first key negotiation algorithm, it can directly select an algorithm supported by both parties and preferred by the server from this list, without relying on the server's guessing or database lookup, further improving the accuracy and efficiency of the negotiation.

[0076] Step S302: Receive a retry request message sent by the server. The retry request message contains an identifier of the second key negotiation algorithm and a second public key corresponding to the second key negotiation algorithm. The second public key is generated by the server when it determines that the first key negotiation algorithm will not be used.

[0077] After sending the first handshake message to the server, the client waits for and receives a response from the server. If the server decides not to use the first key exchange algorithm, it will send a retry request message. Upon receiving the retry request message from the server, the client parses the message and extracts the identifier of the second key exchange algorithm and the second public key. In some embodiments, the client can verify whether the format of the second public key conforms to the specifications of the second key exchange algorithm; if the format is incorrect, the connection is terminated to prevent potential attacks.

[0078] It should be noted that, in some embodiments, the second key negotiation algorithm may be determined by the server from at least one key negotiation algorithm supported by the server based on the algorithm preference information corresponding to the client, and the algorithm preference information is determined based on the first handshake message.

[0079] In some embodiments of this specification, the step of the server determining the algorithm preference information corresponding to the client based on the first handshake message includes: extracting the source network features corresponding to the first handshake message; the source network features include the geographical region and / or network operator type to which the source IP address belongs; determining the algorithm preference information corresponding to the client based on the source network features and a predefined algorithm preference database; wherein, the algorithm preference database statistically analyzes the historical support rate distribution of various key negotiation algorithms for customer groups under different source network features; the algorithm preference information includes the historical support rate distribution of various key negotiation algorithms for the client.

[0080] In some embodiments of this specification, the step of the server determining the algorithm preference information corresponding to the client based on the first handshake message includes: determining the algorithm preference information corresponding to the client based on the first handshake message, including: Obtain the parameter attribute features of the first key negotiation algorithm contained in the first handshake message, the parameter attribute features including mathematical primitive type and security strength level; determine the algorithm preference information corresponding to the client based on the parameter attribute features; wherein, the algorithm preference information includes algorithms with the same mathematical primitive type as the first key negotiation algorithm and with a security strength level not greater than the security strength level of the first key negotiation algorithm.

[0081] In some embodiments of this specification, the step of the server determining the algorithm preference information corresponding to the client based on the parameter attribute features includes: extracting the protocol structure features corresponding to the first handshake message; the protocol structure information includes at least one of a global permutation sequence of extended fields and an encoding feature of the identifier of the first key negotiation algorithm; determining the cryptographic library corresponding to the client based on the protocol structure features; determining the algorithm preference information corresponding to the client based on the cryptographic library corresponding to the client and the parameter attribute features; the algorithm preference information includes having the same mathematical primitive type as the first key negotiation algorithm and a security strength level not greater than the security strength level of the first key negotiation algorithm, and being supported by the cryptographic library corresponding to the client.

[0082] Step S303: Using the second public key as input, call the key encapsulation algorithm corresponding to the second key negotiation algorithm to obtain ciphertext data and session key.

[0083] After receiving a retry request message from the server, if the client decides to use the second key negotiation algorithm and second public key contained in the retry request message, the client calls the key encapsulation algorithm of that algorithm, taking the received second public key as input parameter to obtain ciphertext data and a session key. In some embodiments, the key encapsulation algorithm internally performs operations such as random number generation and matrix-vector operations, outputting two results: ciphertext data and the session key. The ciphertext data is sent to the server for the server to recover the session key; the session key is stored in the client's local secure storage area for subsequent data encryption and decryption. In some embodiments, the session key can be a high-entropy shared secret, which typically needs to be expanded into key material and initialization vector (IV) for actual symmetric encryption through a key derivation function (KDF).

[0084] Step S304: Construct a second handshake message containing the encrypted data and the business data encrypted using the session key, and send the second handshake message to the server.

[0085] Unlike the traditional ClientHello which only contains key exchange parameters, the second handshake message in this embodiment includes not only ciphertext data but also business data encrypted using the session key. In some embodiments, the client can use an Early Data Key derived from the session key to encrypt application layer data and append the encrypted data block to a specific extended field in the second handshake message, or send the business data encrypted using the session key simultaneously with the ciphertext data.

[0086] It should be noted that in the embodiments described in this specification, the client sends a valid business request simultaneously with sending the second handshake message. For example, in an HTTPS scenario, the client can directly send an HTTP GET request during the second handshake. This avoids the serial waiting process of "handshake completion -> sending request -> waiting for response" in the traditional process, and achieves parallelization of handshake and business transmission.

[0087] In some embodiments of this specification, the secure communication method applied to the client further includes: Receive encrypted business response data sent by the server in response to the business data; The encrypted business response data is decrypted based on the session key.

[0088] After the client sends a second handshake message containing encrypted business data to the server, the client can receive a data packet returned by the server. This data packet contains encrypted business response data. Upon receiving the encrypted business response data from the server, the client can use its locally stored session key (or its derived key) to decrypt and verify the data's integrity. If the verification passes, the client obtains the plaintext business response data and delivers it to the upper-layer application for processing. Thus, the entire secure communication process completes bidirectional secure data exchange within approximately 1.5 RTT.

[0089] The secure communication method provided in this specification changes the traditional TLS handshake convention where the client leads key generation. Instead, it adopts a mechanism where the server actively generates a second key pair and sends the public key when it determines that it will not use the first algorithm. This technique breaks the bidirectional serial dependency of the traditional process of "client generates and sends public key -> server confirms -> server generates and sends ciphertext data," eliminating the process where the client needs to regenerate the key pair and re-initiate the handshake request due to algorithm mismatch. By moving the server's key generation action to the retry request stage, the client only needs to perform a one-way key encapsulation operation when responding to a retry, without having to perform the time-consuming key pair generation and uploading steps. As a result, the original two-stage public key exchange process, which required independent round-trip time (RTT), is compressed, reducing the number of communication rounds required for key negotiation from the traditional 2-RTT to 1.5-RTT, thus reducing the number of interaction rounds in the TLS handshake.

[0090] Meanwhile, the embodiments in this specification allow the client to directly encrypt business data using the generated session key and send it along with the second handshake message. Since the server has already generated the second key pair before issuing a retry request, and can immediately decrypt the second handshake message to obtain the session key and decrypt the business data, this "parallel handshake and data transmission" mechanism eliminates the idle window of waiting for the handshake to completely finish before transmitting data. This not only significantly shortens the arrival time of the first packet but also significantly improves throughput in high-latency network environments, effectively enhancing data transmission efficiency.

[0091] Figure 6 This is a schematic structural diagram of a device provided in an exemplary embodiment. For example... Figure 6 As shown, device 600 mainly consists of a communication interface 602, a user interface 604, a processor 606, and a data storage 608. These components are interconnected and communicate with each other via a system bus, network, or other connection mechanism 610. The communication interface 602 enables device 600 to communicate with other devices, access networks, and transmission networks via analog or digital modulation. For example, the communication interface 602 may include a chipset and antenna for wireless communication with a radio access network or access point. Furthermore, the communication interface 602 can be a wired interface such as Ethernet, Token Ring, or a USB port, or a wireless interface such as Wi-Fi, Bluetooth, Global Positioning System (GPS), or a wide-area wireless interface (e.g., WiMAX or LTE). Of course, the communication interface 602 can also support other forms of physical layer interfaces and standard or proprietary communication protocols. The communication interface 602 may also include multiple physical communication interfaces, such as Wi-Fi, Bluetooth, and wide-area wireless interfaces.

[0092] User interface 604 includes receiving user input and providing output to the user. Therefore, user interface 604 may include input components such as a keypad, keyboard, touch-sensitive or presence-sensitive panel, computer mouse, trackball, joystick, microphone, still camera, and video camera, and output components such as a display screen (which may be combined with a touch-sensitive panel), CRT, LCD, LED, display using DLP technology, printer, and other similar devices known or developed in the future. User interface 604 may also generate auditory output via speakers, speaker jacks, audio output ports, audio output devices, headphones, and other similar devices known or developed in the future. In some embodiments, user interface 604 may include software, circuitry, or other forms of logic capable of transmitting and receiving data from external user input / output devices. Additionally or alternatively, device 600 may support remote access from other devices via communication interface 602 or another physical interface (not shown). User interface 604 may be configured to receive user input, the position and movement of which may be indicated by indicators or cursors described herein. User interface 604 may also be configured as a display device for rendering or displaying text fragments.

[0093] Processor 606 may contain one or more general-purpose processors and / or special-purpose processors.

[0094] Data storage 608 may include one or more volatile and / or non-volatile storage components and may be integrated wholly or partially with processor 606. Data storage 608 may include removable and non-removable components.

[0095] Processor 606 is capable of executing program instructions 618 (e.g., compiled or uncompiled program logic and / or machine code) stored in data storage 608 to perform the various functions described herein. Data storage 608 may contain a non-transitory computer-readable medium on which program instructions are stored, which, when executed by device 600, enable device 600 to perform any methods, processes, or functions disclosed in this specification and / or the accompanying drawings. Execution of program instructions 618 by processor 606 may result in processor 606 using data 612.

[0096] For example, program instructions 618 may include an operating system 622 (e.g., an operating system kernel, device drivers, and / or other modules) installed on device 600 and one or more applications 620 (e.g., a browser, social application, or game application). Similarly, data 612 may include operating system data 616 and application data 614. Operating system data 616 is primarily accessible to the operating system 622, while application data 614 is primarily accessible to one or more applications 620. Application data 614 may reside in a file system visible or hidden from the user of device 600.

[0097] Application 620 can communicate with operating system 622 through one or more application programming interfaces (APIs). These APIs help application 620 read and / or write application data 614, transmit or receive information via communication interface 602, receive or display information on user interface 604, etc.

[0098] In some terminology, application 620 may be simply referred to as "app". Furthermore, application 620 can be downloaded to device 600 through one or more online app stores or app markets. However, applications can also be installed on device 600 in other ways, such as through a web browser or a physical interface on device 600 (e.g., a USB port).

[0099] Please refer to Figure 7 In some embodiments, the secure communication device applied to the server can be applied to, for example... Figure 6 The device shown implements the technical solution described in this specification. This secure communication device applied to the server may include: The server-side first receiving module 702 receives a first handshake message sent by the client, the first handshake message indicating the first key negotiation algorithm supported by the client; The server-side generation module 704, when it is determined that the first key negotiation algorithm will not be used for key negotiation, generates a second key pair corresponding to the second key negotiation algorithm. The second key pair includes a second public key and a second private key. The sending module 706 sends a retry request message to the client, the retry request message containing the identifier of the second key negotiation algorithm and the second public key; The server-side second receiving module 708 receives a second handshake message sent by the client in response to the retry request message. The second handshake message contains ciphertext data and business data encrypted using a session key. The session key and the ciphertext data are obtained by the client calling the key encapsulation algorithm corresponding to the second key negotiation algorithm with the second public key as input. The decryption module 710 decapsulates the ciphertext data based on the second private key to obtain the session key, and decrypts the business data based on the session key.

[0100] Please refer to Figure 8 In some embodiments, the secure communication device applied to the client can be applied to, for example... Figure 6 The device shown implements the technical solution described in this specification. This secure communication device applied to a client may include: The client's first sending module 802 sends a first handshake message to the server, the first handshake message indicating the first key negotiation algorithm supported by the client; The client receiving module 804 receives a retry request message sent by the server. The retry request message contains an identifier of the second key negotiation algorithm and a second public key corresponding to the second key negotiation algorithm. The second public key is generated by the server when it determines that the first key negotiation algorithm will not be used. The client generation module 806 takes the second public key as input and calls the key encapsulation algorithm corresponding to the second key negotiation algorithm to obtain ciphertext data and session key. The client's second sending module 808 constructs a second handshake message containing the encrypted data and the business data encrypted using the session key, and sends the second handshake message to the server.

[0101] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more of these specifications, the functions of each module or unit can be implemented in the same or different software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0102] Based on the same concept as the methods described above, this specification also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor implements the steps of the secure communication method as described in any of the above embodiments by executing the executable instructions.

[0103] Based on the same concept as the methods described above, this specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the secure communication method as described in any of the above embodiments.

[0104] Based on the same concept as the methods described above, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the secure communication method as described in any of the above embodiments.

[0105] What those skilled in the art will understand is: In this specification, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, product, or apparatus that includes said elements is not excluded.

[0106] In this specification, “a,” “an,” and “the” do not specifically refer to the singular, but may also include the plural.

[0107] In this specification, ordinal numbers such as "first," "second," etc., do not necessarily indicate order; they are often used to distinguish between objects. For example, "first server" and "second server" usually refer to two servers. To differentiate between these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0108] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0109] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0110] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0111] Although one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is only one of many possible execution orders and does not represent the only execution order. Therefore, when the claims involve method steps, any changes or adjustments to the order of such steps, or the parallelism between steps, are also within the scope of protection of the claims.

Claims

1. A secure communication method, applied to a server, the method comprising: Receive a first handshake message sent by the client, the first handshake message indicating a first key negotiation algorithm supported by the client; If it is determined that the first key negotiation algorithm will not be used for key negotiation, a second key pair corresponding to the second key negotiation algorithm is generated, and the second key pair includes a second public key and a second private key. A retry request message is sent to the client, the retry request message containing the identifier of the second key negotiation algorithm and the second public key; The client receives a second handshake message in response to the retry request message. The second handshake message contains ciphertext data and business data encrypted using a session key. The session key and the ciphertext data are obtained by the client calling the key encapsulation algorithm corresponding to the second key negotiation algorithm with the second public key as input. The encrypted data is decapsulated based on the second private key to obtain the session key, and the business data is decrypted based on the session key.

2. The method according to claim 1, further comprising: The algorithm preference information corresponding to the client is determined based on the first handshake message; Based on the algorithm preference information, the second key negotiation algorithm is determined from at least one key negotiation algorithm supported by the server.

3. The method according to claim 2, wherein determining the algorithm preference information corresponding to the client based on the first handshake message includes: Extract the source network features corresponding to the first handshake message; the source network features include the geographical region and / or network operator type to which the source IP address belongs; The algorithm preference information corresponding to the client is determined based on the source network characteristics and a predefined algorithm preference database; wherein, the algorithm preference database statistically analyzes the historical support rate distribution of various key negotiation algorithms for client groups under different source network characteristics; the algorithm preference information includes the historical support rate distribution of various key negotiation algorithms for the client.

4. The method according to claim 2, wherein determining the algorithm preference information corresponding to the client based on the first handshake message includes: Obtain the parameter attribute features of the first key negotiation algorithm contained in the first handshake message, wherein the parameter attribute features include mathematical primitive type and security strength level; The algorithm preference information corresponding to the client is determined based on the parameter attribute features; wherein, the algorithm preference information includes algorithms with the same mathematical primitive type as the first key negotiation algorithm and whose security strength level is not greater than that of the first key negotiation algorithm.

5. The method according to claim 4, wherein determining the algorithm preference information corresponding to the client based on the parameter attribute features includes: Extract the protocol structure features corresponding to the first handshake message; The protocol structure information includes at least one of the following: a global permutation sequence of extended fields and an encoded feature of the identifier of the first key negotiation algorithm; The cryptographic library corresponding to the client is determined based on the protocol structure characteristics; The algorithm preference information corresponding to the client is determined based on the cryptographic library corresponding to the client and the parameter attribute features; The algorithm preference information includes having the same mathematical primitive type as the first key negotiation algorithm and having a security strength level no greater than that of the first key negotiation algorithm, and being supported by the cryptographic library corresponding to the client.

6. The method according to claim 1, further comprising: If the second handshake message is not received within a preset time threshold starting from the time a retry request message is sent to the client, the second key pair is deleted. Alternatively, if the session key is obtained, the second key pair can be deleted.

7. The method according to claim 1, further comprising: Obtain the business response data corresponding to the decrypted business data; The service response data is encrypted based on the session key, and the encrypted service response data is sent to the client.

8. A secure communication method applied to a client, the method comprising: Send a first handshake message to the server, the first handshake message indicating the first key negotiation algorithm supported by the client; The server receives a retry request message, which includes an identifier of a second key negotiation algorithm and a second public key corresponding to the second key negotiation algorithm. The second public key is generated by the server when it determines that the first key negotiation algorithm will not be used. Using the second public key as input, the key encapsulation algorithm corresponding to the second key negotiation algorithm is invoked to obtain ciphertext data and session key; Construct a second handshake message containing the encrypted data and the business data encrypted using the session key, and send the second handshake message to the server.

9. The method according to claim 8, wherein the first handshake message further includes algorithm preference information corresponding to the client; the algorithm preference information includes relevant information on other key negotiation algorithms supported by the client besides the first key negotiation algorithm.

10. The method according to claim 8, further comprising: Receive encrypted business response data sent by the server in response to the business data; The encrypted business response data is decrypted based on the session key.

11. An electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor executes the executable instructions to implement the method as described in any one of claims 1-10.

12. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-10.

13. A computer program product comprising: A computer program / instruction that, when executed by a processor, implements the method as described in any one of claims 1-10.

Images